asked on

Asymmetric NAT Rule Issue on Cisco ASA 5520

Hi, I just recently implemented a DMZ on an ASA 5520 running 8.4(1). Once I put the DMZ in place, I started getting these types of messages in the logs:

5 Apr 27 2011 09:46:17 10.1.1.10 137 Asymmetric NAT rules matched for forward and reverse flows; Connection for udp src Outside:192.168.2.4/137 dst Inside:10.1.1.10/137 denied due to NAT reverse path failure

I have AnyConnect SSL VPN set up and my guess is that this 192.168.2.4 is someone's home network coming into the outside interface via the VPN (note that incoming VPN clients get an IP of 10.1.254.x/24). I have never seen a private IP address coming into the outside network like that before. 10.1.1.10 is one of our domain controllers and should be accessible by VPN clients.

When I set up the DMZ I made quite a few changes to the NAT, so I guess something I did caused this, but I'm not sure what. As far as I can tell, VPN is functioning normally...I tested and couldn't find any issues with connecting to 10.1.1.10 or anything else for that matter. Would love some advice as to how to fix this. Here are the relevant parts of my NAT config, more than willing to sanitize and post the rest of it if requested:

object network obj-10.1.0.0
subnet 10.1.0.0 255.255.0.0
object network obj-10.1.254.0
subnet 10.1.254.0 255.255.255.0
object network obj-10.254.0.0
subnet 10.254.0.0 255.255.0.0
object network obj-10.10.0.0
subnet 10.10.0.0 255.255.0.0
object network obj-10.1.1.4
host 10.1.1.4
object network obj-10.1.3.2
host 10.1.3.2
object network obj-10.1.11.34
host 10.1.11.34
object network obj-10.1.11.20
host 10.1.11.20
object network obj-10.1.1.200
host 10.1.1.200
object network obj-10.1.11.99
host 10.1.11.99
object network obj-10.1.11.41
host 10.1.11.41
object network obj-10.1.12.16
host 10.1.12.16
object network obj-10.1.11.85
host 10.1.11.85
object network obj-10.1.12.8
host 10.1.12.8
description DMZ Test Web Server
object network obj_any
subnet 0.0.0.0 0.0.0.0
object network obj_any-01
subnet 0.0.0.0 0.0.0.0
object network obj-0.0.0.0
host 0.0.0.0
object network obj_any-02
subnet 0.0.0.0 0.0.0.0
object network obj-10.1.11.32
host 10.1.11.32
description Whos On
object network KensMain
subnet 10.1.0.0 255.255.240.0
object network TulsaConn
subnet 10.10.0.0 255.255.0.0
object network obj-10.1.0.0-20
subnet 10.1.0.0 255.255.240.0
object network obj_any-03
subnet 0.0.0.0 0.0.0.0
object network obj-any-04
subnet 0.0.0.0 0.0.0.0
object network TCMain
subnet 10.10.0.0 255.255.0.0
object network obj-10.10.0.0-16
subnet 10.10.0.0 255.255.0.0

nat (Inside,any) source static obj-10.1.0.0 obj-10.1.0.0 destination static obj-10.1.254.0 obj-10.1.254.0
nat (Inside,any) source static obj-10.254.0.0 obj-10.254.0.0 destination static obj-10.1.254.0 obj-10.1.254.0
nat (Inside,any) source static obj-10.10.0.0 obj-10.10.0.0 destination static obj-10.1.254.0 obj-10.1.254.0
!
object network obj-10.1.1.4
nat (Inside,Outside) static <external IP scrubbed>
object network obj-10.1.3.2
nat (Inside,Outside) static <external IP scrubbed>
object network obj-10.1.11.34
nat (Inside,Outside) static <external IP scrubbed>
object network obj-10.1.11.20
nat (Inside,Outside) static <external IP scrubbed>
object network obj-10.1.1.200
nat (Inside,Outside) static <external IP scrubbed>
object network obj-10.1.11.99
nat (Inside,Outside) static <external IP scrubbed>
object network obj-10.1.11.41
nat (Inside,Outside) static <external IP scrubbed>
object network obj-10.1.12.16
nat (Inside,Outside) static <external IP scrubbed>
object network obj-10.1.11.85
nat (Inside,Outside) static <external IP scrubbed>
object network obj-10.1.12.8
nat (Inside,Outside) static <external IP scrubbed>
object network obj_any
nat (Inside,Outside) dynamic interface
object network obj_any-01
nat (Inside,Outside) dynamic obj-0.0.0.0
object network obj_any-02
nat (management,Outside) dynamic obj-0.0.0.0
object network obj-10.1.11.32
nat (any,any) static <external IP scrubbed>
object network obj-10.1.0.0-20
nat (Inside,DMZ) static KensMain
object network obj_any-03
nat (Inside,DMZ) dynamic obj-0.0.0.0
object network obj-any-04
nat (DMZ,Outside) dynamic interface
object network obj-10.10.0.0-16
nat (Inside,DMZ) static TCMain

Once again, please let me know if you need more config or more info. Thanks!

ArneLovius

just to quickly check you config, have you tried doing "sh run | inc 192.168.2.4" ?

hachemp

ASKER

Thanks for the reply Arne. I ran that and it came back with nothing. Just to be safe, i ran a 'sh run | inc 192.168' and all it came back with was the following:

KENSASA# show run | inc 192.168
ip address 192.168.1.1 255.255.255.0 standby 192.168.1.2
failover interface ip LANlink 192.168.100.1 255.255.255.0 standby 192.168.100.2
http 192.168.1.0 255.255.255.0 management
dhcpd address 192.168.1.10-192.168.1.254 management

The first line being the management inferface IP address, the second refers to the failover link between the two 5520s we have, the third is allowing http access from the management network and the fourth is dhcp for the management int.

Unfortunately, no mention of 192.168.2.4.

ArneLovius

It won't be an anyconnect client address.

What gets me is seeing a private IP address on the outside of your ASA, which if your router is configured correctly (or ISP if you have a metro type connection) should be blocking.

Have you used 192.168.2 previously on your network ? Could your DC be trying to connect to 192.168.2.4 ?

hachemp

ASKER

That's exactly what kills me too....that address isn't publicly routable, so how is it getting there? There is no edge router; our ISP connection terminates directly to the outside interface of the ASA.

-

Actually, now that I think about this, it doesn't terminate directly to the ASA...it goes to a Dell PowerConnect switch that is also connected to the outside interface of the passive ASA for failover. If I remember correctly that switch's default network is 192.168.2.0/24. I thought I had left it in unmanaged mode, but it's not looking like it.

Thanks for this...you got me thinking in the right direction and I think this is the answer. I will confirm this tomorrow and give you full points for your assistance.

ArneLovius

a switch, even a managed one, shouldn't be initiating traffic to port 137...

hachemp

ASKER

I do see your point but I don't see how it could be anything else...I'm thinking that maybe at one time I had pointed it to 10.1.1.10 for DNS/NetBIOS when it was being used on the 10 network. Not sure why it would be looking anything up, but at any rate, I will check this tomororw and confirm.

ASKER CERTIFIED SOLUTION

ArneLovius

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

hachemp

ASKER

I set up the packet capture (I haven't used this tool before but I can tell you I will be in the future, thanks for the link) and unbelievably, about an hour before I started it, that message stopped appearing in the logs and hasn't appeared since. I'm going to leave the capture going overnight and will let you know how it goes tomorrow. Thanks.

ArneLovius

Like going to the dentist :-)

hachemp

ASKER

Yeah, or the mechanic :)

OK, so I left it running, got that message a few times in the logs, but nothing in the packet capture buffer. I tried setting it up both ways - with 192.168.2.4 as the src on the outside, and 10.1.1.0 as the dst on the inside, and vice versa, with 10.1.1.10 as the source on the inside and 192.168.2.4 as the destination on the outside (though I'm not sure how the latter would work, as I don't have anything set up internally to route the 192.168.2.4 network to the ASA or anywhere else for that matter).

Guess I'm not doing something right, but not sure how else to set it up. I used the link you sent me as a guide and just can't get anything to show up in the buffer, while still getting the message in the syslogs. To make it even stranger, I checked and that Dell PC 2716 switch it is running in unmanaged mode...which according to everything I can tell from the documentation means it doesn't have an IP address at all! I also confirmed that the default IP for those switches is 192.168.2.1/24. While I do think it's too much of a coincidence that the packets in question are coming from that same network, the IP addresses still do not match.

I was going to put in back into managed mode to look at the settings, but doing that would reboot the switch, and this is on a production network, so can't reallly do that...besides, putting the switch in managed mode essentially resets all of the settings to default, so not sure what I would gain from that.

The only things plugged in to this switch are the two outside interfaces from the active and passive ASAs, and the ISP connection. Both ASAs' outside interfaces are addressed to publicly routable IP addresses.

Sorry to post a novel here. What I may do is come up here late one night this weekend, put the Dell switch into managed mode, and mirror the port going to the active ASA to another port that I can run a wireshark capture on. Unless you have any other suggestions, that is. :)

hachemp

ASKER

"(though I'm not sure how the latter would work, as I don't have anything set up internally to route the 192.168.2.4 network to the ASA or anywhere else for that matter)"

....I take the above back...the default route will send any traffic that doesn't have a route to the ASA...

hachemp

ASKER

Whoops, was sick this week and almost forgot about this...turns out it was the switch. Thanks again for your help.