Faking an ASA as a DNS Forwarder

I came across a good tip the other day that was very helpful during a small site firewall migration. Here’s the back story:

I was migrating a small single-site customer that had, up to this point, been using a FIOS-provided consumer-type router/firewall/access point to some Cisco gear including an ASA firewall for better firewall/VPN capabilities. This is fairly common with small businesses that start out with essentially consumer-style connectivity and finally begin to grow to a point of needing business-grade capabilities. My preparation went fine, and when the time came I swapped the ASA firewall in place of the FIOS-provided one. Then everything broke.

I had meticulously prepared the ASA to take over immediately from the old FIOS router, even going so far as to spoof the FIOS router’s MAC address on the ASA’s inside interface for now so as not to disrupt the 60-or-so clients that were all on the single attached internal subnet while their ARP caches timed out since we were doing the install and cut-over during working hours. I had set up a DHCP scope on the ASA as well, which instructed clients to use some public DNS resolvers as this small business has, so far, neither needed nor installed an internal DNS resolver. I should point out that this was an all-Macintosh shop, and so they’d been getting by with a single flat subnet and Bonjour magic. That in itself causes problems that will have to be addressed later, but that’s why they didn’t need any internal DNS server even for a business with 60+ client devices and several file servers.

Anyway, after determining that most users couldn’t get to the Internet following the cutover, I took a quick look at the ASA’s logs and spotted this:

%ASA-7-710005: UDP request discarded from to inside:
%ASA-7-710005: UDP request discarded from to inside:
%ASA-7-710005: UDP request discarded from to inside:
%ASA-7-710005: UDP request discarded from to inside:
%ASA-7-710005: UDP request discarded from to inside:

Doh! I quickly looked back at my notes from the FIOS router’s configuration and confirmed that the DHCP scope on the FIOS router had been handing its own IP out as the DNS server and then forwarding DNS requests. The clients that had not yet refreshed their DHCP lease still thought they could use the default gateway as their DNS server! Any clients that had refreshed DHCP would correctly send requests directly to the public DNS servers, but the vast majority of clients would not renew DHCP for hours and I had already set the expectation with the customer that this was going to be a very minimally-disruptive cutover.

I knew in the past that the ASA has not been able to act as a DNS forwarder, but wasn’t sure if that had possibly changed in very recent 9.x code, so I hit Ye Olde Google and found this link. Essentially, the idea was simply to do a static PAT from a public DNS server to the ASA’s inside interface IP on UDP 53 to catch those DNS requests and redirect them to the external DNS server. Made sense (and I must say I’m not sure I would have thought that one up myself in short order), so I gave it a try:

object network Google-DNS-
 description Temp PAT to inside interface to deal with DHCP leases
nat (outside,inside) static interface service udp domain domain

So again, the highlighted NAT command above is kind of a “reverse” NAT. Remember, the ASA NAT syntax goes “nat (real_interface,natted_interface)”, so we’re NAT’ing the public server to answer on the inside interface IP of the ASA on UDP 53. It’s “backwards” from a normal NAT. Lo and behold, it worked! The logs just after adding that NAT showed the following:

%ASA-6-302015: Built outbound UDP connection 5959 for outside: ( to inside: (
%ASA-6-302015: Built outbound UDP connection 5960 for outside: ( to inside: (
%ASA-6-302015: Built outbound UDP connection 5961 for outside: ( to inside: (
%ASA-6-302016: Teardown UDP connection 5960 for outside: to inside: duration 0:00:00 bytes 103
%ASA-6-302016: Teardown UDP connection 5959 for outside: to inside: duration 0:00:00 bytes 177
%ASA-6-302016: Teardown UDP connection 5961 for outside: to inside: duration 0:00:00 bytes 119
This is kind of a kludgey solution, so I wouldn’t want to use it for the long term due to its tricky nature. But this was really a hold-over until all the DHCP leases got renewed and clients learned to go directly to the assigned public DNS servers. Within a couple days, this little trick can be removed as all the clients refresh DHCP. In that context, this hack worked very well to smooth out the cutover/migration process.
Note that if this was an IOS device, this sort of trick wouldn’t be necessary as you can configure an IOS device as a DNS caching forwarder.
Tagged , , ,

One thought on “Faking an ASA as a DNS Forwarder

  1. deltafly3r says:

    Good read, Ty

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


Virtualization, Storage, and other techy stuff

The Stupid Engineer

I ask those questions you're too clever to.

Sunay Tripathi's Blog

Pluribus Networks Founder's Blog on OS, Networking, Virtualization, Cloud Computing, Solaris Architecture, etc

Ed Koehler's Blog

Just another WordPress.com weblog


Data networking, stray thoughts, nerdy fun...

Network Heresy

Tales of the network reformation

The Borg Queen

Jottings on the intersection of tech and humanness

Networking From The Trenches

Ramblings about my thoughts, experiences, and ideas.

Networking 40,000

Attaining my CCIE with the help of Warhammer 40k

Network Shenanigans

Making Packets Do Silly Things

It must be the network...

Ramblings of JD (@subnetwork)

Not Another Network Blog

Musings from yet another IT nerd

rsts11 - Robert Novak on system administration

Resource sharing, time sharing, (20)11 and beyond. A retired sysadmin's blog.

%d bloggers like this: