[vpn-help] A note on DNS and VPN

[Lars Vik]

Hi List,

Just a note to those who experience problems with browsing the internet 
after connecting through Shrew VPN.

Keep in mind that a correctly configured DNS-server wont allow recursive 
look ups for other than predefined  IP-ranges, i.e.private IP-ranges 
and/or IP-ranges assigned to the entity. But a correctly configured 
DNS-server should at least answer echo-requests, so if you can't ping 
the DNS, most likely it is a routing problem.

When you set up Shrew VPN or any other VPN-system it is crucial what 
IP-range you assign to the VPN-clients. For example, your company's 
DNS-server accept recursive look ups from 10.50.0.0/16 and if you have 
an IP-address outside the range, the DNS wont answer even though the 
router/firewall/VPN-gateway are able to route the request. For the user 
it will appear as if internet is unavailable, nothing will work. (Unless 
you use IP-addresses directly that is). A simple ping will tell you: 
ping www.google.com, if the DNS answers, all is OK of course, if not 
ping 74.125.77.99. If you get a response general routing is OK, but the 
DNS doesn't answer, either because it is not reachable (Routing, can you 
ping it?) or because it wont answer (recursive) the IP the DNS-request 
is coming from.

If the latter is the problem you must either set Shrew VPN to use an IP 
inside the allowed recursive look up range, or change the DNS-server to 
accept recursive lookups from the IP-range you assign to your VPN-clients.

You can also use split DNS in Shrew VPN adding a domain, i.e. 
mycompany.local or mycompany.lan, etc. This way Shrew only do lookups 
over IPsec on the domains you have assigned. All other lookups are done 
via the ISP's DNS-server. Meaning recursive look ups are done via the 
ISP's DNS, while listed domains the DNS-server are authoratitive for are 
routet through IPsec. Best practice is to not allow any IP outside the 
company to read these "private" domains, *.local *.lan, etc, since this 
reveals the internal topography of your company's LAN and hosts. In 
general, it is paramount that you disable public look ups and zone 
transfers for those domains on your DNS.

Regarding WINS. Just the other day I helped a company setting up VPN, 
and the local WINS-server (NetBIOS) was set to only answer requests from 
within the broadcast domain, 192.168.90.0/24, making it impossible to 
browse the Windows Network by hostname via VPN. After allowing the 
assigned VPN IP-range to do WINS-look ups it worked perfectly. So same 
goes for WINS as DNS.

Also, my five cents is that it is best to always use a "Virtual Adapter 
and assigned IP" in Shrew VPN, either assigned from the VPN-gateway or 
manually static entry, since you never know what IP-address the client 
have assigned on the host NIC. Most mobile broadband users for instance 
are assigned public IP-addresses, hence you immediately have a problem 
with DNS/WINS.

It should be safe to allow recursive lookups from 10.0.0.0/8, 
172.16.0.0/12 and 192.168.0.0/16 since these ranges are private and 
non-routable. However, best practice is to narrow it down to only allow 
the IP-ranges in use, including the VPN IP-range. If the DNS-servers are 
outside the LAN, you will probably need to use a DNS-proxy. Many 
firewalls/routers have an in-built DNS-proxy (set DNS-server to the 
firewalls LAN IP in Shrew), if not you will need to set up a DNS-proxy 
in your LAN. Servers like SAMBA can, in additions to be a WINS-server 
(Windows/NetBIOS), also operate as a DNS-proxy. I am pretty sure (but 
not certain) the same goes for Windows DC/DNS/WINS servers as well.

How you design your network and what network equipment (vendors) you use 
will of course set precedence on how you solve these challenges. You 
should also be careful when acquiring firewalls/VPN-gateways. Many 
VPN-functions are regarded by vendors as "Enterprise class", so even 
though many SOHO firewalls comes with VPN-support, it is somehow 
crippled since you can't customize it very much or it doesn't support, 
in my oppinion, basic functions, like, DNS-proxy, XAUTH, RADIUS, DHCP 
over VPN, config pull/push, or similar, etc. Lack of these so called 
"Enterprise class" functions will in turn lead to micro management, and 
worse, a less secure VPN-solution.

My appologies for any errors in this mail, but I still hope this info 
can be useful to some.

Lars