Why does using my Airport for DNS break all VPN access (even IP addresses)

[Makosuke]

After a bunch of troubleshooting on a VPN access issue for a small business office, I eventually figured out what was causing the problem, but it doesn't seem to make any sense why it is a problem, and I'm hoping someone here who understands the technology better than I do can help me understand what's going on.

The situation is basically this: I have computers on a home WiFi network using a current model Airport, and I'm trying to connect to a small office VPN to access a remote server.

If I configure DNS servers manually on the computer's WiFi connection (that is, say, 8.8.8.8 for the DNS, if I use Google), and then connect to the VPN, everything works exactly as expected.

If, however, I leave the WiFi DNS empty and let it get a DNS server from the Airport DHCP (in which case its DNS ends up being something like 10.0.0.1, while the Airport itself has 8.8.8.8 configured for the DNS), and connect the VPN, no VPN traffic goes anywhere.

When connected to a VPN while using the Airport as a DNS relay (or cache, not sure which it does), even if I try to ping something directly via IP address--say, 192.168.111.1--no traffic gets through. If I route all traffic through the VPN, nothing goes anywhere--no internet at all.

The local network is not on the same subnet as the remote network--the remote network uses 192.168.111.x while the local network is on 10.x.x.x (forget exactly what, but Apple's default)

I'd sort of get it if the cached Airport DNS was causing some problems with routing to external addresses, but an IP address isn't supposed to hit the DNS at all, so I am completely baffled as to how the DNS setting on the WiFi connection is having any effect on the VPN'd connection.

What am I misunderstanding here? What is OS X doing in terms of routing that's causing this?

 

[DJLC]

Very interesting.

The only thing I can think of: do you have it set to send ALL traffic over the VPN, or just traffic bound for that network? Try swapping it to sending all traffic and see what happens. Or vice versa if it's already like that.

I can't think logically of any reason for it to cause problems... as you said, IPs shouldn't hit DNS, and OS X should be able to recognize an IP as being member of the VPN vs. the LAN and route it out appropriately. The AirPort should see VPN packets and forward them on to its WAN interface without a problem since the IP ranges don't conflict.

 

[Makosuke]

do you have it set to send ALL traffic over the VPN

Had already tested that. If I don't have that set, external internet access works as expected (not routed through the VPN), but I have no access to any internal resources on the other side of the VPN, even when referred to with an IP address.

If I turn that on (that is, all traffic through the VPN), I get no useful network access at all--both external internet and internal VPN resources don't respond.

It's basically acting like there's a routing problem, but it makes no sense to me how a DNS setting should affect routing like that.

 

[DJLC]

Hum. Yeah. I think we're on the exact same page with no answers.

The only (bad) advice I have left is to dump the AirPort. IMO it's overpriced garbage anyway. Get an ASUS or something that can route traffic properly.

 

[Makosuke]

Hum. Yeah. I think we're on the exact same page with no answers.

The only (bad) advice I have left is to dump the AirPort. IMO it's overpriced garbage anyway. Get an ASUS or something that can route traffic properly.

Thing is, I'm not actually sure whether it's the airport or the MacOS itself that's causing the routing issue. My logic (which may be flawed) is that if you are routing all traffic through the VPN, by definition the OS should be encapsulating all requests through the VPN connection (which is establishing correctly, so that at least must work). Since that should essentially encrypt and encapsulate all traffic into a form that the Airport isn't seeing as far as routing--it should just see encrypted packets going to and from the external VPN IP address--the Airport can't be part of the problem. If I was unable to contact the remote network, period, then it could be the router's fault, but once the VPN is established the router should only see packets going to and from the remote site, not what's in them.

It could only be the Airport's fault if the Airport was allowing a connection to the remote VPN server but then somehow blocking traffic going there once the connection was up (and doing it in such a way that the MacOS didn't detect that block as a dropped VPN connection).

Maybe I'm wrong about how that works (or is supposed to)?

Anyway, since I have no idea what networks this computer will be used on in the future (and I think the owner has an Airport anyway), just replacing the router isn't a workable solution. Hardwired DNS should be a workaround, except then when the computer is physically inside the network it won't pull the internal DNS server address and so will have trouble accessing internal resources. I'm thinking hardwiring the internal DNS server followed by public ones may work, since it'll try the internal one first (and use it, if it's available), and otherwise will fall over to a public one. Question is whether it'll introduce an unpleasant delay into all requests while it waits for the first-choice server to timeout...