Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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..

share|improve this question
    
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 '11 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 '11 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 '11 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 '11 at 4:06
    
Added information about the packet-tracer and the NAT rules that got hit.. –  Azz Oct 27 '11 at 0:08

2 Answers 2

up vote 1 down vote accepted

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.

share|improve this answer
    
Feel free to explain why this was causing the problem if my guess isn't correct. –  Azz Oct 28 '11 at 11:10

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.

share|improve this answer
    
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 '11 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 '11 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 '11 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 '11 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 '11 at 9:15

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.