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 192.168.1.56/62364 to inside:192.168.1.1/53 %ASA-7-710005: UDP request discarded from 192.168.1.87/64785 to inside:192.168.1.1/53 %ASA-7-710005: UDP request discarded from 192.168.1.49/57574 to inside:192.168.1.1/53 %ASA-7-710005: UDP request discarded from 192.168.1.49/59060 to inside:192.168.1.1/53 %ASA-7-710005: UDP request discarded from 192.168.1.33/50580 to inside:192.168.1.1/53
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-8.8.4.4 description Temp PAT to inside interface to deal with DHCP leases host 8.8.4.4 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:8.8.4.4/53 (192.168.1.1/53) to inside:192.168.1.152/60730 (192.0.2.115/60730) %ASA-6-302015: Built outbound UDP connection 5960 for outside:8.8.4.4/53 (192.168.1.1/53) to inside:192.168.1.152/59840 (192.0.2.115/59840) %ASA-6-302015: Built outbound UDP connection 5961 for outside:8.8.4.4/53 (192.168.1.1/53) to inside:192.168.1.152/58728 (192.0.2.115/58728) %ASA-6-302016: Teardown UDP connection 5960 for outside:8.8.4.4/53 to inside:192.168.1.152/59840 duration 0:00:00 bytes 103 %ASA-6-302016: Teardown UDP connection 5959 for outside:8.8.4.4/53 to inside:192.168.1.152/60730 duration 0:00:00 bytes 177 %ASA-6-302016: Teardown UDP connection 5961 for outside:8.8.4.4/53 to inside:192.168.1.152/58728 duration 0:00:00 bytes 119
Herding Packets 
Good read, Ty