I have done more investigation and have now found the following.
While from the client devices point of view it looks like DNS lookups fail this was merely a symptom rather than the cause of failing to be able to access addresses.
It turns out the problem is that when the client device is accessing the remote internal network (which works fine) this is correctly going through the VPN servers second LAN interface which is connected to the internal LAN at the office. When the client device is accessing a public address and when the VPN is set to route all traffic via the VPN server the traffic is exiting via the VPN servers first LAN interface which is connected to the DMZ port of a firewall. This behaviour in of itself is correct but the firewall is seeing the packets as coming from an unexpected IP address, rather than looking like they are coming from the VPN server itself, they look like they are coming from a spoofed address which is actually the remote clients public IP address.
As a result the the firewall is blocking all the traffic in this case including DNS lookups.
I would at least partially consider this to be the fault of the VPN server not producing packets with correct IP addresses. I plan to try the following as possible solutions.
- Build a test Lion or Mountain Lion VPN server and see if it works any better.
- Replace the old firewall with a new one which supports OS X and iOS standard VPN client software, the current one only supports the manufacturers client, they do have a version for OS X and iOS but I want to use the standard Apple client.
- I could move the first LAN port of the VPN server from the DMZ to the WAN side of the firewall, the firewall then obviously would not be able to block the traffic.
Note: I am aware I could have just a single LAN connection on the VPN server on the internal LAN and setup port-forwarding in the firewall, I prefer not to do this.