Route pushed from OpenVPN server appears on wrong interface
Posted: 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:
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