Skip to content
Route pushed from OpenVPN server appears on wrong interface
Got a problem with Viscosity or need help? Ask here!
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:
Thanks in advance for your help,
James
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
This works just fine - however the additional route I have pushed using the configuration directive on the server:# netstat -rn
...
192.168.12/22 link#14 UCS 4 0 vtap1 !
192.168.12.1/32 link#14 UCS 1 0 vtap1 !
...
Code: Select all
Appears as follows:push route 192.168.10.0 255.255.255.0 192.168.12.1
Code: Select all
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:# netstat -rn
...
192.168.10 192.168.12.1 UGSc 0 0 en0
...
Code: Select all
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.# 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
...
Thanks in advance for your help,
James
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
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
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
2 posts
Page 1 of 1