Skip to content
Mac assigns gateway to wrong network device.
Got a problem with Viscosity or need help? Ask here!
I am running Viscosity 1.4.9 on a OSX 10.9.3 system.
I have a remote OpenVPN server with tap interface running on 192.168.7.1 that pushes out two routes:
push "route 192.168.7.0 255.255.255.0 192.168.7.1";
push "route 192.168.8.0 255.255.255.0 192.168.7.1";
The 192.168.7.0/24 network (office) is the remote network and the 192.18.8.0/24 (office2) is a remote network one hop removed from 192.168.7.0/24. The "8" network is reachable from "7" network when I in the office.
When I use OpenVPN/tap I can access 192.168.7.0/24 network as expected. The problem is that I cannot reach the 192.168.8.0 network with using OpenVPN/tap.
The reason may be the routing. Note on the Mac:
] route -n get 192.168.7.1
route to: 192.168.7.1
destination: 192.168.7.1
interface: tap0
flags: <UP,HOST,DONE,LLINFO,WASCLONED,IFSCOPE,IFREF>
so the '7' network gets routed to the tap interface as expected. However, the '8' network:
] route -n get 192.168.8.1
route to: 192.168.8.1
destination: 192.168.8.0
mask: 255.255.255.0
gateway: 192.168.7.1
interface: en0
flags: <UP,GATEWAY,DONE,STATIC,PRCLONING>
and that appears to be the wrong interface and I cannot reach the '8' network when I use OpenVPN/tap. Is this a OpenVPN/Viscosity issue? How can I tell Viscosity to assign the route to the correct interface?
Note, all this works well when use a OpenVPU/tun interface, but for technical reasons I need this to work with a 'tap' interface.
Regards,
- Henrik
I have a remote OpenVPN server with tap interface running on 192.168.7.1 that pushes out two routes:
push "route 192.168.7.0 255.255.255.0 192.168.7.1";
push "route 192.168.8.0 255.255.255.0 192.168.7.1";
The 192.168.7.0/24 network (office) is the remote network and the 192.18.8.0/24 (office2) is a remote network one hop removed from 192.168.7.0/24. The "8" network is reachable from "7" network when I in the office.
When I use OpenVPN/tap I can access 192.168.7.0/24 network as expected. The problem is that I cannot reach the 192.168.8.0 network with using OpenVPN/tap.
The reason may be the routing. Note on the Mac:
] route -n get 192.168.7.1
route to: 192.168.7.1
destination: 192.168.7.1
interface: tap0
flags: <UP,HOST,DONE,LLINFO,WASCLONED,IFSCOPE,IFREF>
so the '7' network gets routed to the tap interface as expected. However, the '8' network:
] route -n get 192.168.8.1
route to: 192.168.8.1
destination: 192.168.8.0
mask: 255.255.255.0
gateway: 192.168.7.1
interface: en0
flags: <UP,GATEWAY,DONE,STATIC,PRCLONING>
and that appears to be the wrong interface and I cannot reach the '8' network when I use OpenVPN/tap. Is this a OpenVPN/Viscosity issue? How can I tell Viscosity to assign the route to the correct interface?
Note, all this works well when use a OpenVPU/tun interface, but for technical reasons I need this to work with a 'tap' interface.
Regards,
- Henrik
An additional piece of information. The OpenVPN/tap server in combination with Viscosity 1.4.9 on a Windows 7 system works as it is currently configured. Once OpenVPN/tap connected to the office (e.g. 7) network I can reach the office2 (e.g. '8') network without problems.
- Henrik
- Henrik
One more piece of information. When I connect to OpenVPN/tap and then on the Mac terminal:
] sudo route -n delete 192.168.8.0/24
] sudo route -n add 192.168.8.0/24 192.168.7.1
] route -n get 192.168.8.1 | grep interface
interface: tap0
] ping -c1 192.168.8.1
...
64 bytes from 192.168.8.1: icmp_seq=0 ttl=63 time=65.967 ms
it works. I realize I could probably create a "Connected Script" to address this issue, but should this not work (so to speak) "out of the box"?
] sudo route -n delete 192.168.8.0/24
] sudo route -n add 192.168.8.0/24 192.168.7.1
] route -n get 192.168.8.1 | grep interface
interface: tap0
] ping -c1 192.168.8.1
...
64 bytes from 192.168.8.1: icmp_seq=0 ttl=63 time=65.967 ms
it works. I realize I could probably create a "Connected Script" to address this issue, but should this not work (so to speak) "out of the box"?
Hi Henrik,
OpenVPN is most likely adding the routes before the VPN interface is ready, which can be solved by using a route delay:
1. Open the Preferences window and Edit your connection
2. Click on the Advanced tab
3. On a new line in the commands box enter "route-delay 20" (without the quotes)
4. Click Save and try reconnecting
Cheers,
James
OpenVPN is most likely adding the routes before the VPN interface is ready, which can be solved by using a route delay:
1. Open the Preferences window and Edit your connection
2. Click on the Advanced tab
3. On a new line in the commands box enter "route-delay 20" (without the quotes)
4. Click Save and try reconnecting
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
5 posts
Page 1 of 1