Route pushed from OpenVPN server appears on wrong interface

Got a problem with Viscosity or need help? Ask here!

chinahand

Posts: 1
Joined: Fri Dec 14, 2018 2:58 am

Post by chinahand » Fri Dec 14, 2018 3:09 am
Hi there

I am using Viscosity for Mac with great success - however I have recently encountered an odd problem. I have an OpenVPN 2.4 server (running on a pfSense device). Part of the configuration for this is to push a route over the VPN that isn't part of the default subnet.

The VPN comes up just fine, and I can connect to the default subnet, and indeed the routing table looks perfectly valid for this:
Code: Select all
# netstat -rn
...
192.168.12/22      link#14            UCS             4        0   vtap1      !
192.168.12.1/32    link#14            UCS             1        0   vtap1      !
...
This works just fine - however the additional route I have pushed using the configuration directive on the server:
Code: Select all
push route 192.168.10.0 255.255.255.0 192.168.12.1
Appears as follows:
Code: Select all
# netstat -rn
...
192.168.10         192.168.12.1       UGSc            0        0     en0
...
The fact that it is bound to my Mac's WiFi interface (en0) means the packets never reach any devices on this subnet. However if I manually delete and recreate this from the shell, everything is fine:
Code: Select all
# sudo route delete 192.168.10.0/24 192.168.12.1
delete net 192.168.10.0: gateway 192.168.12.1
# sudo route add 192.168.10.0/24 192.168.12.1
add net 192.168.10.0: gateway 192.168.12.1
# netstat -rn
...
192.168.10         192.168.12.1       UGSc            0        0   vtap1
...
Any ideas how to debug this? Is it possible my configuration is somehow forcing this errant adapter assignment? Other VPN configurations are working perfectly, including additional routing pushed from OpenVPN on an identical version of pfSense using the "push route ..." directive.

Thanks in advance for your help,

James

James

User avatar
Posts: 2313
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Mon Dec 17, 2018 6:24 am
Hi James,

This usually means that OpenVPN is adding the route before the VPN network interface has been assigned an IP address. Try adding the command "route-delay auto" (without the quotes) to the advanced commands area for your connection:
https://www.sparklabs.com/support/kb/ar ... n-commands

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
2 posts Page 1 of 1