ASA - NAT issue with DNS traffic

[petenixon]

Hi all,

I'm having problems with a domain controller (dc2) responding to DNS replication data from a remote dc (dc1). ASA is connected through a l2l VPN, inside subnet of 192.168.1.0 is nat'ed to the outside interface public address.

I can see that inbound tcp streams are being built from dc1, but there is no outbound response in the logs from dc2. The configuration is pretty sparse on the ASA and both respond to pings from either subnet, so i'm thinking layer 4 problem? I can't tracert from the ASA as it complains of a DNS error on the outside interface but I can't see how this is related. Packet tracer shows a drop of this traffic as IPSEC spoof, but I believe that this is only because the packet tracer data did not originate from the tunnel?

I think that NAT is the source of the problem, does NAT modify DNS packets, or perhaps the NAT timers are too short and the UDP packets timeout?

Thanks.

[petenixon]

Looking through the router logs has shed some light on this. I think that assymetric routing is the cause of the issue, the UDP DNS packets are being routed through the default route (to the gateway router), whereas any TCP traffic would automatically route back through the tunnel.

I'm not sure how to resolve this though. If I add a route outside to my remote subnet and use the endpoint peer address as the next hop i'm sure that the source IP address would change and this will cause problems. I'm running 8.2 on the ASA and it doesn't look like I can route using the exit interface, so how can I resolve this routing issue?

[Jouni Forss]

Hi,

I am not quite sure I understood the whole setup.

Naturally if you can share some configurations could look through them.

Also in addition if you could clarify what connections are taken through this L2L VPN (souce/destination IP addresses and TCP/UDP prots and which directions is the traffic initiated in)

- Jouni

[petenixon]

Thanks for the reply JouniForss,

I'll substitute the real IP's if that's ok.

Remote subnet 10.10.10.1/24

DC1 = 10.10.10.2

Local subnet 192.168.1.0/24

DC2 = 192.168.1.2

ASA

inside 192.168.1.1

outside 212.219.10.1

Juniper SRX (remote peer)

outside 212.219.10.2

3900 Router (default gateway) = 212.219.10.3

route outside 0.0.0.0 0.0.0.0 212.219.10.3

route outside 212.219.10.2 255.255.255.0 212.219.10.3 1

DNS replication data is sent from the remote subnet (source 10.10.10.2, destination 192.168.1.2, source port 4444, destination port 53, protocol UDP). Both subnets are NAT exempt. Traffic flows from the remote subnet through the firewall but not on the return. Now I think this is because of the connectionless nature of UDP. The local domain controller will receive the UDP packet, create a reply and send this to its defaut gateway (the ASA inside interface), the ASA will then forward it out to the default gateway (the 3900 using its default route) and that's where connectivity dies (the router is not under my control and I do not have the ability to exam its config). What I believe should happen, is that the ASA should have a route that points back to the remote subnet using the tunnel interface as the next hop. However, I think that using the remote address of the Juniper will change the source address of the UDP packet to the outside interface IP?

VPN tunnel is for bidirectional traffic flows between the two subnets above, initiated from hosts in both subnets.

The config on the ASA is pretty much above, save for the crypto config for the VPN tunnel and a few other non critical configurations (ASDM, ssh access, etc).

Please let me know if you need any further information.

Thank you.

[Jouni Forss · Accepted solution]

Hi,

Basically if we consider this traffic as any other TCP or UDP trafic between 2 sites through a L2L VPN then I dont see why TCP traffic would get tunneled and UDP would not be.

Since you mention that the encryption domain is set to match these 2 LAN networks and NAT0 has also been configured that probably is identical to the encryption domain on each site. This should already mean that any TCP or UDP traffic between these networks should always match the VPN configuration after the NAT rules and get forwarded through the L2L VPN.

Only thing I can think of regarding this is that if we are talking about UDP/53 traffic that the DNS inspection would be doing something to the traffic. Though usually it might just rather drop the traffic and nothing like you are describing.

One problem I once had with 8.2(x) software level regarding L2L VPN was that while our customer side had 2 internal subnets, one of them stopped working with regards to the L2L VPN connection. Rather than encapsulating/encrypting the traffic the ASA actually just forwarded this traffic to the Internet.

As the customer had a Failover environment we did so that outside working hours we failed the Primary ASA. In other words manually change the Secondary to be Active ASA. This immediately corrected the problem. The wierd thing was also that this L2L VPN connection had worked for months.

We were also ready to reboot the firewall and actually did boot both firewalls to the latest software in that software range if we were running into some bug.

Dont know if this is the case in your situation but thought I'd mention as what you are telling sounds a bit similiar.

But I dont see any normal condition where the ASA would forward some traffic to the L2L VPN and some to the Internet. The traffic should simply arrive on the ASA and get matched to the proper NAT configuration and then matched to the L2L VPN configuration and forwarded to the remote site wether it is UDP or TCP. I guess there is always chance that a NAT configuration might cause problems but I doubt it in this case if the configurations is simple.

Personally I would monitor logs when attempting the connections. Possibly configure traffic captures to see what traffic is reaching the ASA. Could also use the "packet-tracer" to simulate the traffic that is supposed to come to the ASA from its LAN and head to the Remote LAN. This should show if it matches the correct NAT rules and the VPN configurations.

- Jouni

[petenixon]

Thanks for the reply again Jouni. Your description does sound similar  to mine to be honest, especially relating to the ASA version and the forwarding of the traffic incorrectly. I'm going to schedule an upgrade to 8.4 and see if that helps.

Your assistance has been much appreciated, thank you.

[Jouni Forss]

Hi,

Do notice that 8.4 is a completely different software than 8.2. Very much so!

The NAT configuration format is completely different and it changed in the 8.2 -> 8.3 software update.

So if you dont have any expirience with the new software I would advice against doing this update right away. I would suggest reading up on the new software NAT changes and preparing well since you have to learn the new NAT format. Though if its a simple configuration it will be easy to convert (even though ASA will do this automatically but isnt 100% reliable)

You might want to start with a reboot of the ASA at some point if your dont have a Failover pair in which case you could just change the Active device.

I will also have to note that the problem I mention above I have only run into once and we have had some other devices in the 8.2(x) software which are used for L2L VPN purposes.

Naturally if an software upgrade is in plans either way then its ok but would suggest you get familiar with the new configurations formats

- Jouni

[petenixon]

I'm actually more familiar with 8.4 than 8.2, but sage advice nontheless!

Just so I don't continue to pull my hair out, I am going to schedule a reboot first (it does resolve a multitude of problems!) and see what happens.

Again, thank you!