OS X IPSec VPN Tunnel Configuration Issue AND Resolution

Podcast: Play in new window | Download ()

Subscribe: Apple Podcasts | Spotify | Amazon Music | RSS | More

Can you believe it?! Issue and resolution in a single post! What a day!

Like many businesses, my company is experiencing penetration of OSX-based machines in our environment. Personally, I love the products… Work-ally, they drive me up the wall. But, that is the topic for another post some time in the future.

A couple of the new machines are MacBook Pro devices. With the latest version of OSX, 10.6 — Snow Leopard, Apple has licensed the Cisco IPSec VPN client functionality and has included it baked into the OS. Pretty cool, huh?! We have seen the same functionality added with a recent version of iOS for iPhones and iPads. So, these devices can natively connect to an IPSec VPN tunnel without installing the Cisco VPN client.

Our environment hosts VPN connections through a nice ASA at the datacenter. There have been no issues terminating VPNs at the ASA using devices with Cisco VPN Client installed as well as proof of concept connections using iPhones and an iPad. Everything just works… as it should.

The song changes, though, when we tried to connect the new Snow Leopard laptops to the corporate network with the baked in VPN client. Configuration worked well. Group name, server name, PSK, username, and password. Everything was quick and easy. Both the ASA and the Mac was showing successful connections! However, we were missing something. It did not work quite right.

The issue was that the VPN client had no idea which traffic to send over the VPN and which traffic to send over the public Internet (gotta love split horizon configurations). Routes existed properly to route internal 192.168.0.0/16 traffic, which was excellent. I could ping everything I needed to over the VPN connection and reach resources via IP address. However, the issue appeared with proper DNS lookups.

Ideally, and as we have seen with the Cisco VPN Clients, iPhone, and iPad, when the client connects, the internal DNS servers are passed along to the client to handle the resolution. In this situation, though, this was not the case. Everything was resolving using external DNS. So, any internal services were not available to the client because DNS was not being queried properly.

As a work around, in the VPN configuration advanced settings, we could specify internal DNS servers and search domains… which worked. Upon completion of the VPN session, the changes would need to be reversed. For the average end user, this was a really ugly and unprofessional way to operate. Plus, this SHOULD NOT BE THE CASE… out of pure principle.

At this point, I was pulling my hair out. Seriously… what could be the problem? Everything works out perfectly for all of the other clients… including the iPhone and iPad. There had to be something missing! But, what could it be…

Well, after poking around on the ASA (and confirming online), it turns out that the OSX baked in client needs the addition of a single group policy attribute. Specifically:

group-policy PolicyName attributes

…

split-dns value internal.domain internal2.domain

…

This nifty little line of code tells the OSX client that for the listed domains, you should query the internal DNS for resolution. Otherwise, continue using the standard resolv.conf DNS servers for resolution.

Why in the world would we need to make this change when other Apple provided Cisco VPN Clients work perfectly without it? To this day, I still have no idea. But, it works, and I am going with it. Logically, the line makes perfect sense… just not the necessity of it.

So, if you are in a similar situation, I sincerely hope this little nugget of joy stops you from pulling your hair out and having embarrassing random bald spots as a result… maybe you can convince your company to expense an new hat until your hair grows back.