What's In a Name?

In the realm of Microsoft, it seems that "name resolution" is always the answer to the question, "why doesn't this !@#&*^ thing work?". Crossing over into a career in Network Security I have found that I will never escape this problem.

The past two days it seems that about sixty percent of my problems have been with customers who are expecting name resolution to "just work". Take for example one of my SonicWALL owners who has recently built a VPN tunnel between two offices. I am always quick to tell them that "if you cannot access a resource by name, try it by IP address". For some, accessing resources by IP address does not propose any problems. For others, this is quite an obstacle. It's getting to be that most of my calls revolve around name resolution problems of some sort. Therefore, today I would like to cover ...

Why Name Resolution Doesn't Work over my SonicWALL VPN Tunnel

Did you enable NetBIOS on the Security Association? - Remember that NetBIOS is a broadcast mechanism. It has no business being sent through a routed network. A VPN tunnel is a routed network. You should edit the VPN Policy, head into the "Advanced" tab and look for "NetBIOS Broadcasts". You need to check that option at *both* ends of the tunnel when possible.

Have you tried the IP Helper? - This is a goofy fix. At this point, I would question what you are trying to accomplish here. Remember that Microsoft has made several attempts over the years to banish "broadcast name resolution" from networks in favor of DNS. I don't want to get up on my soapbox and start yelling at you though. So you might try this - it fixes quite a bit.

Go into Network > IP Helper and first enable the helper, while selecting NetBIOS below it. You will need to "Apply" for that to be effective. Next, you will need to create TWO policies. One for each directional flow of traffic. That is, if you were doing this for a remote user VPN (WAN GroupVPN) make one that says "source: VPN DHCP Clients, dest: Firewalled Subnets", and then reverse it. Like this ...

Use Your Own DNS Server - If you have a DNS server at one end of this tunnel, consider using it for clients at the other end. What do I mean? Imagine "network A" has a DNS server which Active Directory uses. In fact, the Active Directory server is almost always also the DNS server for smaller businesses. That server should resolve the names of *ALL* your internal clients. It should also have "forwarders" configured so that when you ask it who http://www.google.com/ is, it will send that request to a DNS server on the Internet for an answer.

That being said, when users on the remote end of the VPN tunnel ("network B") are connecting, they should *also* use that DNS server. What you will find though, is that they are probably configured to use a public (Internet) DNS server when they connect. That's because you configured DNS on the SonicWALL for the WAN Interface. It then uses those DNS servers as the primary and secondary servers for it's DHCP scope. So, if this is a "site to site" tunnel, you will need to change the DHCP scope of that local SonicWALL having the name resolution issues. If you are using a remote user VPN (WAN GroupVPN) you need to change the DHCP scope of the SonicWALL that they are connecting to. You should *not* change the WAN Interfaces DNS server addresses. You don't need to!

You would do this: Click Network > DHCP Server. Then click the configure button next to the scope. Next click the DNS/WINS tab. You will notice that the SonicWALL defaults to "inherit DNS Settings". You will change it to "Specify Manually" and ensure that the first address is the DNS server on "network A" (the one with all the answers!). You might want to configure a second address of an Internet DNS server. One that will answer queries for Internet domains. That is more of a fail-safe in case the primary DNS server stops responding. It should *not* be used as an attempt to answer *all* Internet queries. Remember, your primary should be set up with DNS forwarders for that!

Use Your Domain Name - Quick, look at that illustration above. Is your domain name configured as part of your DHCP scope? It ought to be. Most folks think this is optional. But if you want your DNS server to complete your queries, this needs to be set to your name. That is, I might ask your DNS server who "SERVER1" is, and it doesn't know. But if I ask it who "SERVER1.mydomainname.com" is, I get an answer. Add your domain name to your scope, and you will fix a lot of complaints from users. If SonicWALL is not performing DHCP, and you cannot fix this on your own - consider fixing this problem on your local network adapter (or virtual VPN adapter). Basically, you drill down to IP Properties, then "Advanced", then DNS, then add a "domain name suffix" in that box near the bottom. Case closed.

Still Using WIN's? - You ought to be ashamed! But if you are using WIN's, you probably can solve your name resolution problems by adding WIN's servers to your DHCP scope. If SonicWALL is performing DHCP for you, refer to the previous illustration to see how that would be done. If you are not using WIN's, I congratulate you. WIN's was designed as a way to manage(?) NetBIOS name resolution. Most of us use DNS now (or Dynamic DNS) and we are much better for it.

If none of that worked, and you are still having name resolution problems on your SonicWALL VPN, you should send me a comment or an email. Yes, I will help you. I'm that kind of guy.

-Steve Ballantyne