Skip to main content

Case-sensitive DNS? Believe it.

DNS is not case-sensitive, that's what you thought, right? Me too, but apparently somebody disagrees.


We have a client who uses a Cisco ASA 5510 to provide remote access to several road warriors and small satellite offices. We recently started putting Windows 7 64-bit machines in the network, which has traditionally only had 32-bit XP laptops. The Cisco VPN client we usually utilize doesn't work on Windows 7 64-bit (routes don't get created properly). I realize that there is a compatible beta version out and the latest SSL VPN works, but unfortunately due an unbelievable snafu between Tech Data and Cisco, we were left high dry without a SMARTnet agreement. So it came down to using an excellent open-source VPN from Shrew Soft, which is compliant.

I tested the Shrew Soft product and verified it worked great on my local  Windows 7 32-bit machine. I also tested it successfully on a 64-bit box, no problems.

Problem:
We use split-tunneling/split-dns to ensure that all traffic for "company.local" is routed over the VPN. Our configuration also specifies that unqualified names, like "server1", get appended with "company.local". So if I ping "server1", it should actually ping server1.company.local automatically and thus get sent across the VPN. Easy.

We went to deploy it to the client and quickly found out that name resolution was not working over the VPN. Attempting to ping "server1" just timed out while the packets shot out the local network instead of getting passed through the VPN. Since everything worked fine on my machines, I was baffled for a minute as to what the issue could be.

Cause:
The clients laptops were all connected to the domain "company.local". So they should be appending company.local to the end of every unqualified request to form a FQDN anyways, making this even more confusing. 

However, a little digging showed that they were actually appending a capitalized version of the FQDN like so: server1.COMPANY.LOCAL. No big deal, right? Wrong! Our Cisco config only specified a lower-case version of the FQDN in the split-dns configuration. For some reason, the Shrew Soft VPN client (or perhaps some component used in it) interprets company.local and COMPANY.LOCAL as different domain names.

Resolution:
Add the upper-case version of company.local (COMPANY.LOCAL) to the split-dns configuration like so:

split-dns value company.local COMPANY.LOCAL

Both values are passed to the client which then allows the proper DNS requests to be intercepted and sent over the VPN.

I'm pretty sure this is a Shrew Soft issue, and perhaps one that only exists in Windows 7 or 64-bit machines. This shouldn't happen (and didn't) with the Cisco VPN client. According to Cisco:

The client receives a comma-delimited list of split DNS names from the Concentrator via modeconfig. When the Software Client receives a DNS query packet, the domain name is compared and equentially checked against the split DNS names. Case-insensitive domain name comparison starts at the end of each domain name string and continues toward the beginning of each string, resulting in a match, or no match.

Other than this little quirk, Shrew Soft has produced a great and much-needed product, so I'm certainly not bashing them at all. Maybe something to throw in the next bug release though? Or maybe I'm completely off-base here; the inner-workings of VPN client architecture is not something I'm familiar with.



Comments

  1. Man I hate problems like this, where the solution is something you would never even think of. Props on actually managing to figure it out though! I'm not sure I would've ever considered the case of the values as the potential problem.

    Fred | https://webhostinggeeks.com/tools/

    ReplyDelete

Post a Comment

Popular posts from this blog

Outlook Credential Prompt When Opening Exchange 2013 Public Folder

After completing an Exchange 2007 > 2013 migration recently, I was left with one issue that was preventing us from stamping the project as a roaring success and moving on:

Outlook 2013 users were sometimes receiving a single pop-up prompt for credentials whenever they opened the Public Folder (we have only one). One. Single. Prompt.

Google was frustratingly unhelpful because searching for "outlook prompts for username and password when opening public folders" or something similar just resulted in a lot of folks who were always getting a pop-up that wouldn't go away. It was usually caused by an authentication failure of some sort.

However, we were in a different boat - Users got the prompt once when they first launchedOutlook and opened their public folders, but after entering it they could continue - authentication worked. Next time they logged in to their PC, it would happen again. Not a show stopper, but it definitely generated its share of support calls.

Repairing Mailbox Corruption in Exchange 2010

I recently got through recovering an SBS 2011 server after Active Directory face-planted in the middle of a workday. When I say recover, I mean I repeated the entire migration, using a cleaned up secondary DC - it was a fun weekend (expect another post about that experience). Although I thought we were in the clear, I got a call from the client about 24 hours after we had verified everything was working. He indicated that his iPhone had suddenly stopped receiving mail in the inbox (calendar, contacts, sent items were still fine) and throws up an error after spinning in circles for a few minutes that it "cannot connect to mail server".

SCEP Policy Update Troubleshooting

Because I'm a glutton for punishment, I recently started rolling out System Center Configuration Manager 2012 R2 SP1 and System Center Endpoint Protection across our VDI environment. There are always some considerations to be made in a pooled desktop / gold image type environment when loading software that uniquely identifies devices, but lucky for me SCCM/SCEP handled this just fine without any tweaking. However, there were some nuances to how SCEP policies are applied that caused some serious hair-pulling before I spotted the issues.