2

Forgive me, as I'm not very experienced with ASAs, but I believe what I have configured should be working.

I have an ASA 5510 running version 8.3(2), which is connected to internal, external, and dmz networks, as well as an RA VPN. Both the Internal and DMZ networks have dynamic NAT configured when going from internal/dmz to the internet. These dynamic NATs both work as expected.

The problem occurs when trying to access the DMZ network from over the VPN.

The error message I get on the ASA states:

%ASA-5-305013: Asymmetric NAT rules matched for forward and reverse flows; Connection for icmp src outside:x.x.x.x dst dmz: y.y.y.y (type 8, code 0) denied due to NAT reverse path failure

I figured that the reason this is occurring is because the traffic returning from the DMZ would match the dynamic NAT rule, and be nat'd to the outside interface.

So I put in a static no NAT rule for the DMZ subnet to the VPN:

nat (dmz,outside) source static DMZ_VLAN DMZ_VLAN destination static VPN VPN

But... I'm still receiving the error.

Now, here's where I get even more confused. After adding that static NAT, my sh nat looks like this:

1 (inside) to (outside) source static any any destination static VPN VPN description VPN No NAT
    translate_hits = 3, untranslate_hits = 1198

2 (dmz) to (outside) source static DMZ_VLAN DMZ_VLAN destination static VPN VPN
    translate_hits = 0, untranslate_hits = 0

If I move the DMZ to Outside rule above the inside to outside rule, I can access the DMZ, but I can not access the inside from the VPN.

I'm not sure why the order of these rules would make a difference, because if the top rule doesn't match, it should keep flowing down the list..

Any help would be appreciated, although my senses are telling me that I'm just making a stupid mistake somewhere obvious.

EDIT: More info.

Interface security levels:

inside: 100
dmz: 50
outside: 0

NAT rules from show run nat :

nat (inside,outside) source static any any destination static VPN VPN description VPN No NAT
nat (dmz,outside) source static DMZ_VLAN DMZ_VLAN destination static VPN VPN

object network DMZ_VLAN
 nat (dmz,outside) dynamic interface

object network In_VLAN
 nat (inside,outside) dynamic interface

Access lists should not apply, as I have sysopt connection permit-vpn on, and unless I misunderstand this command, it should enable traffic from the VPN regardless of ACLs.

Also, ICMP traffic is being inspected, so the return traffic should get back without being effected by the access-list (again, unless I misunderstand traffic inspection)

Networks:

Inside: 10.1.4.0/24
DMZ: 10.1.254.0/24
VPN: 10.1.10.0/24

Packet-tracer from DMZ to VPN

Type: NAT
Subtype: 
Result: ALLOW
Config:
nat (dmz,outside) source static DMZ_VLAN DMZ_VLAN destination static VPN VPN
Additional Information:
Static translate 10.1.254.1/0 to 10.1.254.1/0

The packet-tracer gets all the way to the end with "Allow's" all the way..

Improve this question
5
  • Wall of text; please provide the secrity levels of all interfaces involved, the networks of all interfaces involved, the NAT rules of all interfaces involved, and any relevant ACLs on the interfaces involved.
    – adaptr
    Oct 21, 2011 at 6:46
  • I'm sorry, I couldn't find a way to insert line breaks into comments, updated with information on ACLs and security levels
    – Azz
    Oct 21, 2011 at 7:00
  • Your identity NAT should do the trick.. what NAT hits do you get from a packet-tracer simulating a packet sent from the DMZ network (with the DMZ as the input interface) out to the VPN network?
    – Shane Madden
    Oct 21, 2011 at 21:21
  • I'll do a packet-tracer and let you know when I find out what NAT gets hit, as I won't have access to the network until this Thursday
    – Azz
    Oct 22, 2011 at 4:06
  • Added information about the packet-tracer and the NAT rules that got hit..
    – Azz
    Oct 27, 2011 at 0:08

3 Answers 3

Reset to default
2

Fixed!

I'm not entirely sure what was going on to cause the problem, but this is what seemed to be happening.

Let's revisit the NAT rules again..

nat (inside,outside) source static any any destination static VPN VPN
nat (dmz,outside) source static DMZ_VLAN DMZ_VLAN destination static VPN VPN

Notice the difference between the two rules which (are supposed to) do the same thing for different interfaces.

The reason the top NAT is wide open like that (any any) is because there are actually multiple networks that can come from the inside of our network, so we thought leaving it open would be easier than defining every network that could appear.

The problem that seems to have been happening, was that when traffic comes in from the VPN, the ASA would look through it's NATs seemingly before it decides what path it will take through the firewall. So it'll check the traffic against the top NAT, and it matches because it's definitely going from VPN to any.. Whereas the return traffic would be from DMZ_VLAN to VPN, and therefore, wouldn't match the top rule.

I'm not sure if matching that first NAT causes the ASA to direct the traffic inside, or if it just realises that the outbound traffic will match a different NAT.

Once I modified the top NAT rule to be more specific:

nat (inside,outside) source static IN_VLANS IN_VLANS destination static VPN VPN

Everything works perfectly!

Weird issue.. but it seems the moral of the story is to be specific with everything, even when you don't think it will cause any issues.. because it can.

Improve this answer
1
  • Feel free to explain why this was causing the problem if my guess isn't correct.
    – Azz
    Oct 28, 2011 at 11:10
0

Okay, slightly less of a mess. Still - I am not seeing any network definitions; what makes you think using nonat is useful at all here ? The networks involved could solve this mystery, but we don't know at this point.

It is not usual for a DMZ (which mostly has public IPs) to connect directly to a VPN (which mostly does not).

The following caught my eye:

So I put in a static no NAT rule for the DMZ subnet to the VPN:

nat (dmz,outside) source static DMZ_VLAN DMZ_VLAN destination static VPN VPN

However, that does the exact opposite: nat (X,Y) is a static nat from Y to X

It is also not a nonat rule.

A nonat to a VPN should originate on the other interface:

nat 0 (outside,dmz) DMZ VPN

This presents the DMZ IPs to the VPN interface without applying the outside interface's rules.

Of course, you can also do a normal nat from the outside to the DMZ, but this is usually discouraged because you're creating access from lower to higher security.

Improve this answer
5
  • Okay, I may have been unclear in a few places. I need to have access to BOTH the internal network AND the DMZ from the VPN. The DMZ has just been installed, so I am trying to create access from the VPN to the DMZ. The inside to outside rules already existed, and have been working perfectly. Also, as far as I understand, the ASA sees VPN connections as coming from the outside interface, which should have a lower security level than the DMZ. The only NAT rules that should be relevant have been shown, as all other rules have nothing to do with the DMZ.
    – Azz
    Oct 21, 2011 at 6:48
  • The VPN will appear to be coming from the interface where it is configured. This will usually be a lower security interface. What are the security levels, networks, NAT rules and ACLs ?
    – adaptr
    Oct 21, 2011 at 7:00
  • nat 0 doesn't seem to work in 8.3. Also, I can see what I forgot to tell you now. The DMZ is using entirely private addresses. I've updated the original post with info regarding the networks.
    – Azz
    Oct 21, 2011 at 7:23
  • Also, I was under the impression that nat (X,Y) means X is internal, and Y is external, not source and destination.
    – Azz
    Oct 21, 2011 at 7:32
  • Drat, I just looked up the release notes for 8.3. We run 8.0.4 or something, and they have made significant changes to the syntax and rule processing... Probably best to ignore me then :(
    – adaptr
    Oct 21, 2011 at 9:15
0

Azz,

Access DMZ from VPN Clients. Cisco ASA 9.x

Thanks for your info as it helped me get my problem resolved. My ASA code is 9.x which no longer uses nonats and actually uses static NATs instead. I found the same as you where on my firewall I had some any to any nats applied with destination VPN networks. Removing this and adding specifics resolved my issue an can confirm access to the Inside and DMZ from my VPN clients. I fixed my issue with the following lines below. Hope this helps others.

Removed Problem NATS, from Any to VPN Network IPs: 10.10.8.x

no nat (inside,any) source static any any destination static OBJ-10.10.8.0-24 OBJ-10.10.8.0-24 no-proxy-arp description NONAT
no nat (outside,any) source static any any destination static OBJ-10.10.8.0-24 OBJ-10.10.8.0-24 no-proxy-arp description NONAT

Added Specific NATs for Inside and DMZ access to VPN Networks below.

nat (inside,outside) source static NETWORK_OBJ_10.0.0.0_8 NETWORK_OBJ_10.0.0.0_8 destination static NETWORK_OBJ_10.10.8.0_24 NETWORK_OBJ_10.10.8.0_24 no-proxy-arp route-lookup
nat (dmz,outside) source static OBJ-10.10.7.0-24 OBJ-10.10.7.0-24 destination static NETWORK_OBJ_10.10.8.0_24 NETWORK_OBJ_10.10.8.0_24 no-proxy-arp route-lookup
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .