opening VPN connection causing loss of visibility to local networks

[wallacethefmh]

Hey networking gurus, I'm not really sure how to phrase this question, which may be why I can't find anything on google.

I am connecting to a vpn via openconnect on centos. When I connect to the VPN, I can no longer see certain networks that I usually can see. In this case, I am losing connectivity to the 10.0.x.x network.

When I am not connected to the vpn, the tracert to the device in question looks like this:

[root@7 ~]# tracert 10.0.9.38
traceroute to 10.0.9.38 (10.0.9.38), 30 hops max, 40 byte packets
1 (192.168.42.20) 1.159 ms * *
2 (10.0.9.38) 1.236 ms * *

Let me know if I should provide any additional info.

Thank you!

 

[kornphlake]

I'm no networking guru, but when I connect to my employer's VPN from my home network, I'm only able to see private IPs on the remote network, not on my home network. I believe this is for security reasons, perhaps one of the less amateur gurus will be able to explain further.

 

[cpals]

They need to allow split-tunneling... meaning you can access the corporate (vpn) network as well as your local. Normally this is not done due to security reasons as the previous poster stated.

 

[Nothinman]

OpenConnect is nice in that it won't enforce a lot of the superfluous faux-security crap like that, you probably just need to fix your routing table after connecting. I have a small shell script I always run after connecting to one of our clients to work around those myself because otherwise it's practically impossible to work on their network without disconnecting/reconnecting several times during a session.

Next time you connect type 'route -n' and see what it looks like. Then you can use the route command to delete the current default gateway, re-set it to your real, local one and then re-add any routes you may need via the VPN with something like 'route add -net 172.16.x.x netmask 255.255.0.0 dev tun0' or whatever pseudodevice was selected for the tunnel.

 

[Mushkins]

They need to allow split-tunneling... meaning you can access the corporate (vpn) network as well as your local. Normally this is not done due to security reasons as the previous poster stated.

This. Whoever is in charge of configuring the VPN accounts needs to allow split-tunneling, otherwise all traffic is being routed through the VPN tunnel, and the other end has no way of knowing or seeing whats on your home network.

No split-tunneling is more secure, but it's a pain in the ass for work-at-home users if they want to print to a local printer physically sitting next to them.

 

[gsaldivar]

Consider running Windows in a virtual machine, and connect to your employer's VPN from within the virtual environment. The same split tunneling restriction will apply, however, you will find that it doesn't affect the host computer. This means you can continue using your LAN, and remain connected to your employer's VPN from within the virtual environment.

 

[RadiclDreamer]

Split tunneling needs to be enabled

 

[thecoolnessrune]

As others said, split tunneling is the problem. I love split tunneling, its what I run at home, and I completely understand why businesses *don't* do it. That being said, them not doing it, is exactly why I connect to my Work and School VPNs through a virtual machine, then have my VM connected to my shared printers and storage locations from my host machine. As said above, it is a royal pain when work asks me to step in, and then has a policy in place that won't even let me print a document from home. I can save it as a PDF, and then print it, but its an intermediate step I avoid just by running the session in a VM.

It also lets me stream Pandora or watch a video / etc. while I work while not using work's bandwith down and back.

 

[wallacethefmh]

Hmmm, everybody is saying this is split tunneling, but according to some other sources, openconnect does not enforce split tunneling rules.

I am not sure if the following proves that split tunneling is ignored, but I can definitely still see the hop point to the 10.0.x.x network while connected to the VPN.

Evidence:

Before Connecting to the VPN:

[root@7 ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
64.47.204.185   192.168.32.1    255.255.255.255 UGH   0      0        0 eth0
192.168.32.0    0.0.0.0         255.255.252.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
0.0.0.0         192.168.32.1    0.0.0.0         UG    0      0        0 eth0

[root@7 ~]# tracert 10.0.9.38
traceroute to 10.0.9.38 (10.0.9.38), 30 hops max, 40 byte packets
1 (192.168.42.20) 1.159 ms * *
2 (10.0.9.38) 1.236 ms * *

After Connecting to the VPN:

[root@7 ~]# route -n | grep eth0
64.47.204.185   192.168.32.1    255.255.255.255 UGH   0      0        0 eth0
192.168.32.0    0.0.0.0         255.255.252.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
0.0.0.0         192.168.32.1    0.0.0.0         UG    0      0        0 eth0

[root@7 ~]# ping 192.168.42.20
PING 192.168.42.20 (192.168.42.20) 56(84) bytes of data.
64 bytes from 192.168.42.20: icmp_seq=1 ttl=64 time=0.756 ms
64 bytes from 192.168.42.20: icmp_seq=2 ttl=64 time=3.76 ms
64 bytes from 192.168.42.20: icmp_seq=3 ttl=64 time=5.26 ms

PING 10.0.9.38 (10.0.9.38) 56(84) bytes of data.

--- 10.0.9.38 ping statistics ---
102 packets transmitted, 0 received, 100% packet loss, time 101069ms

Unfortunately our network admin quit so I am without help, we have a replacement but they are not up to speed.
Also, this VPN is provided by one of our customers and I would not be able to ask them to allow split tunneling on the VPN if that is indeed what is required.

Thank you for the help!

 

[kornphlake]

If I had to guess, and I'm only guessing, it's probably a coincidence that you're pinging 192.168.42.20 on both your local network and the VPN, I doubt that it's the same device on both networks.

 

[Nothinman]

If you try adding a route manually for the 10.0.9.x range does that help?