Connecting to local devices when on a VPN?
February 6, 2010 12:25 PM Subscribe
When I connect to my office via VPN, I cannot access my local network, which uses the same IP addressing scheme as the remote network. I'm tired of disconnecting and reconnecting to control my music player. Would setting up a DNS server locally solve this? Do I still have to change the IP addresses of my local devices?
I'm running Windows 7 and use Cisco AnyConnect. I assume if my local network was 192.168.5.* and there existed no remote network on the VPN of that address scheme, it would look locally for it?
I don't really want to change all my IP addresses, and would rather setup a DNS server and point music.internal to 192.168.1.*, when browsing to music.internal I would think that my local DNS server would be contacted. Would this work?
To be clear, remote network: 192.168.1.*, 192.168.2.* and a few others. AnyConnect reports my IP address as 10.10.10.* My local network, everything resides on 192.168.1.*
I'm running Windows 7 and use Cisco AnyConnect. I assume if my local network was 192.168.5.* and there existed no remote network on the VPN of that address scheme, it would look locally for it?
I don't really want to change all my IP addresses, and would rather setup a DNS server and point music.internal to 192.168.1.*, when browsing to music.internal I would think that my local DNS server would be contacted. Would this work?
To be clear, remote network: 192.168.1.*, 192.168.2.* and a few others. AnyConnect reports my IP address as 10.10.10.* My local network, everything resides on 192.168.1.*
I don't think there's any way around changing your devices' IP addresses. Welcome to the world of pain which non-global IP address assignment has been keeping in store for you.
posted by hattifattener at 1:04 PM on February 6, 2010
posted by hattifattener at 1:04 PM on February 6, 2010
Right, this is a routing problem, not a name resolution problem. Renumbering your local network is probably the most straightforward way to deal with it.
posted by scatter gather at 1:07 PM on February 6, 2010
posted by scatter gather at 1:07 PM on February 6, 2010
When I was connecting to my work remote network I ended up setting my home IP addresses to another IP block (192.255...) I think this resolved these sorts of problems.
posted by bitdamaged at 1:09 PM on February 6, 2010
posted by bitdamaged at 1:09 PM on February 6, 2010
Seconding what Nothlit said, you would need to change your local IPs. A local DNS server would not help.
The 10.10 address is how the work network sees your PC. It's the address of the virtual network adapter that the VPN client creates. That adapter gets all the traffic for the remote subnets and sends it through the VPN tunnel.
Also, even with a unique local subnet, the VPN configuration might not allow you to access you local network. This is to prevent someone from using your computer as a relay to access the work network while you are connected.
This is how a consultant setup my VPN device before I had him change it so remote users could access their local networked printers.
posted by tresbizzare at 1:12 PM on February 6, 2010
The 10.10 address is how the work network sees your PC. It's the address of the virtual network adapter that the VPN client creates. That adapter gets all the traffic for the remote subnets and sends it through the VPN tunnel.
Also, even with a unique local subnet, the VPN configuration might not allow you to access you local network. This is to prevent someone from using your computer as a relay to access the work network while you are connected.
This is how a consultant setup my VPN device before I had him change it so remote users could access their local networked printers.
posted by tresbizzare at 1:12 PM on February 6, 2010
im not entirely sure but maybe you can solve this by telling windows not to use the "predefined" gateway for this connection -- it is an option in the advanced tab of vpn connections tcpip properties (at least it is in xp, dont know about cisco anyconnect. is it pptp?)
posted by 3mendo at 1:12 PM on February 6, 2010
posted by 3mendo at 1:12 PM on February 6, 2010
Response by poster: How come if I have a running processes it seems to be able to communicate with both remote and local network and defaulting to local network if there's a conflict? For example, launch Chrome, connect to VPN and I'm able to access both networks. If I shut down Chrome and restart it, I only get remote access.
posted by geoff. at 1:13 PM on February 6, 2010
posted by geoff. at 1:13 PM on February 6, 2010
I think before you can decide on the best way around this, you need to figure out what the root of the problem is. You need to answer a few questions first:
- what routes are installed when you connect to the VPN ('route print' on windows)
- When you connect to your VPN, are your local DNS servers superceded or replaced by the DNS servers you learn via the tunnel DHCP? ('ipconfig -all', interfaces higher in the list take precedence)
- What security policies are put in place by the VPN concentrator? Specifically, does the admin deny access to the local LAN? If so you are screwed. (tracreroute to an IP on your local segment that you know does not exist on the corporate LAN)
To be SURE that what you want to do will work, re-number your local LAN to a range that is NOT covered by the routes sent to you by the VPN server/concentrator. Then write a local hosts file with the hostnames you want to avoid querying the corporate DNS server about.
P.S. The plan above will not work if your admin is a d**kbag and has denied all access to the local network while the tunnel is up. In the past with IPSEC VPNs you could get around this by using a third party VPN client like shrewsoft or vpnc on linux as they had the ability to ignore security policy. I am unaware if there are such clients that can handle SSL VPNs, but with the growing popularity and lower cost of SSL VPN devices I'm sure it's only a matter of time until someone writes one.
posted by datacenter refugee at 1:17 PM on February 6, 2010
- what routes are installed when you connect to the VPN ('route print' on windows)
- When you connect to your VPN, are your local DNS servers superceded or replaced by the DNS servers you learn via the tunnel DHCP? ('ipconfig -all', interfaces higher in the list take precedence)
- What security policies are put in place by the VPN concentrator? Specifically, does the admin deny access to the local LAN? If so you are screwed. (tracreroute to an IP on your local segment that you know does not exist on the corporate LAN)
To be SURE that what you want to do will work, re-number your local LAN to a range that is NOT covered by the routes sent to you by the VPN server/concentrator. Then write a local hosts file with the hostnames you want to avoid querying the corporate DNS server about.
P.S. The plan above will not work if your admin is a d**kbag and has denied all access to the local network while the tunnel is up. In the past with IPSEC VPNs you could get around this by using a third party VPN client like shrewsoft or vpnc on linux as they had the ability to ignore security policy. I am unaware if there are such clients that can handle SSL VPNs, but with the growing popularity and lower cost of SSL VPN devices I'm sure it's only a matter of time until someone writes one.
posted by datacenter refugee at 1:17 PM on February 6, 2010
Is this an at-home local network? Chances are your router assigns your local addresses by DHCP anyway. Changing them all is a simple matter of changing the network address you want used in the router setup. I had to do this here when the local cable company somehow put the DSL modem (their side) in the same address space I was using at home. (Troubleshooting that was a PITA, let me tell you.)
If you're using manually assigned addresses, it's a bit harder, of course.
posted by ctmf at 1:45 PM on February 6, 2010
If you're using manually assigned addresses, it's a bit harder, of course.
posted by ctmf at 1:45 PM on February 6, 2010
I have this same issue. Our previous VPN client allowed split tunneling, which allowed me to connect to my local network. Once we moved to the Cisco VPN the sysadmins specifically disallowed split tunneling for security reasons. As I understand it, there's nothing I can do about it.
posted by Lokheed at 1:50 PM on February 6, 2010
posted by Lokheed at 1:50 PM on February 6, 2010
This is not an addressing problem unless the plan is to put your LAN devices on the public internet in a way reachable from your work (putting the firewall aside entirely). A DNS approach will not help either.
The solution you are looking for is "split tunneling" where, instead of all packets received being processed by the VPN client (or dropped), only those for specific routes are shunted into the tunnel created by the VPN client.
Needless to say, no workplaces approve of this since you are effectively punching a giant gaping hole in the corporate firewall (since your PC may now act, with or without your knowledge, as a gateway into the corporate network).
The Cisco VPN client does allow this mode of operation as do most others, but there are security profiles to disallow it. It is almost certainly against your terms of use as an employee.
posted by rr at 2:39 PM on February 6, 2010
The solution you are looking for is "split tunneling" where, instead of all packets received being processed by the VPN client (or dropped), only those for specific routes are shunted into the tunnel created by the VPN client.
Needless to say, no workplaces approve of this since you are effectively punching a giant gaping hole in the corporate firewall (since your PC may now act, with or without your knowledge, as a gateway into the corporate network).
The Cisco VPN client does allow this mode of operation as do most others, but there are security profiles to disallow it. It is almost certainly against your terms of use as an employee.
posted by rr at 2:39 PM on February 6, 2010
I connect to my employer's VPN using a Virtual PC image on my machine, so not all of my internet traffic is routed through their network when I'm connected. If you did this, you'd still be able to control your music player from the host OS, and also access your office from the VPC.
posted by cosmic.osmo at 2:54 PM on February 6, 2010
posted by cosmic.osmo at 2:54 PM on February 6, 2010
One thing I forgot to add, which will make my above comment much clearer: the Cisco VPN software appears to route ALL network traffic through the VPN when you're connected. If you connect from a Virtual PC image, only the traffic from that image will be routed through the VPN, and the host OS will still access the network normally.
You can probably do this in other ways, by messing with the routing configuration, but setting up a VPC seemed like the path of least resistance to me.
posted by cosmic.osmo at 2:58 PM on February 6, 2010
You can probably do this in other ways, by messing with the routing configuration, but setting up a VPC seemed like the path of least resistance to me.
posted by cosmic.osmo at 2:58 PM on February 6, 2010
Response by poster: All my important local IP addresses are manually assigned, and I have a couple of things that interact with each other. So this is definitely going to be a chore. I was hoping that maybe there was a way to attach the SSL VPN to individual processes, which would be a slick way of doing it, but it appears that's not how Windows handles network connections.
But, now that I know split tunneling is definitely the route to go, I'm not wasting an afternoon on something that won't work. Thanks all!
posted by geoff. at 3:00 PM on February 6, 2010
But, now that I know split tunneling is definitely the route to go, I'm not wasting an afternoon on something that won't work. Thanks all!
posted by geoff. at 3:00 PM on February 6, 2010
How come if I have a running processes it seems to be able to communicate with both remote and local network and defaulting to local network if there's a conflict? For example, launch Chrome, connect to VPN and I'm able to access both networks. If I shut down Chrome and restart it, I only get remote access.
Well, I have no idea how it works on Windows, but I presume it's the same as it is on my Linux here: It doesn't do a route lookup on every IP packet, but rather cache the information with the socket (the TCP connection, so it should be tied to that and not the process). This makes sense since routing changes are very rare (well, compared to packet sends) and so you can do expensive cleanup when they happen.
posted by themel at 3:13 AM on February 7, 2010
Well, I have no idea how it works on Windows, but I presume it's the same as it is on my Linux here: It doesn't do a route lookup on every IP packet, but rather cache the information with the socket (the TCP connection, so it should be tied to that and not the process). This makes sense since routing changes are very rare (well, compared to packet sends) and so you can do expensive cleanup when they happen.
posted by themel at 3:13 AM on February 7, 2010
Also: I don't think split tunneling will really save you. If you have a proper addressing conflict (a host on the local network and a remote host with the exact same address), you will never be able to reach both.
Fiddling with individual host routes to say "but I want 192.168.1.93 to be local always" does work, but it involves a level of micro management that I wouldn't consider. Then, it'll break and cost you valuable time when someone at work decides to move that essential server to 192.168.1.93 and never tell anyone because the DNS makes it transparent to users anyway, right?
To summarize, I'd change the addresses.
posted by themel at 3:23 AM on February 7, 2010
Fiddling with individual host routes to say "but I want 192.168.1.93 to be local always" does work, but it involves a level of micro management that I wouldn't consider. Then, it'll break and cost you valuable time when someone at work decides to move that essential server to 192.168.1.93 and never tell anyone because the DNS makes it transparent to users anyway, right?
To summarize, I'd change the addresses.
posted by themel at 3:23 AM on February 7, 2010
Response by poster: It doesn't do a route lookup on every IP packet, but rather cache the information with the socket
Ah, this makes sense, I always wonder how that worked. I didn't consider there would be caching.
There are very few services I need access to on my local network. Some may talk to each other, but I talk to them so infrequently it doesn't really matter.
Since I approve all IP address changes, I've designated a range for home use that is off limits. If we ever run out of internal IP addresses (which I doubt, even with IPv4) ... that's good enough cause to move to IPv6.
I realize this isn't best practice from a security perspective, but as nothing on the network stores anything like credit card numbers, SSNs, etc. I'm not too worried.
posted by geoff. at 2:46 PM on February 7, 2010
Ah, this makes sense, I always wonder how that worked. I didn't consider there would be caching.
There are very few services I need access to on my local network. Some may talk to each other, but I talk to them so infrequently it doesn't really matter.
Since I approve all IP address changes, I've designated a range for home use that is off limits. If we ever run out of internal IP addresses (which I doubt, even with IPv4) ... that's good enough cause to move to IPv6.
I realize this isn't best practice from a security perspective, but as nothing on the network stores anything like credit card numbers, SSNs, etc. I'm not too worried.
posted by geoff. at 2:46 PM on February 7, 2010
This thread is closed to new comments.
posted by Nothlit at 12:49 PM on February 6, 2010