cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1793
Views
0
Helpful
6
Replies

ASA 8.4 static NAT VPN not working getting caught by dynamic NAT in section 3 instead

Skjalg Eggen
Level 1
Level 1

Weird issue.

I have configured a S2S VPN and the tunnel is UP, but no traffic is going over the tunnel.

I check the logs and see that the traffic is getting dynamically translatet to the outside interface istead of being not translatet.

I'm think, Ahhh NAT. But when I check NAT config, it is as it should be.

show nat detail gives us this:

Manual NAT Policies (Section 1)

1 (inside) to (outside) source static NETWORK_OBJ_10.200.91.0_24 NETWORK_OBJ_10.200.91.0_24   destination static DM_INLINE_NETWORK_48 DM_INLINE_NETWORK_48 no-proxy-arp route-lookup

    translate_hits = 0, untranslate_hits = 0

    Source - Origin: 10.200.91.0/24, Translated: 10.200.91.0/24

    Destination - Origin: 172.23.0.0/16, 172.25.0.0/16, Translated: 172.23.0.0/16, 172.25.0.0/16

this should make sure that traffic coming from inside 10.200.91.0/24 network gets translatet to itselfe on the outside interface before traversing the VPN tunnel in order to reach 172.23.0.0/16 and 172.25.0.0/16

But what happens instead is it gets cautgh by:

Manual NAT Policies (Section 3)

1 (inside) to (outside) source dynamic any interface 

    translate_hits = 7704657, untranslate_hits = 1441572

    Source - Origin: 0.0.0.0/0, Translated: <outside IP>/24

Packet tracer confirms it as well. NAT is being performed nat (inside,outside) after-auto source dynamic any interface

Any ideas as to why this could be happening?

1 Accepted Solution

Accepted Solutions

Hi,

I don't see a reason why it shouldnt match the other configured rule rather than the Dynamic PAT.

I might consider rebooting the device when the situation permits.

Though if I am not mistaken you have a Failover pair running so I wonder if switching the Active device would help.

Considering the configurations and output you have provided I dont see a configuration issue here.

- Jouni

View solution in original post

6 Replies 6

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

The Section 1 Manual NAT should get matched before the Section 3 one.

So if that is not happening it would sound like a bug.

I would suggest configuring new "object-group network " for the local and remote networks and trying using those in the configuration.

Can you share the complete "packet-tracer" output of the traffic matching wrong NAT rule

- Jouni

This is the complete trace:

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xaf6ac0b0, priority=1, domain=permit, deny=false

        hits=3711489995, user_data=0x0, cs_id=0x0, l3_type=0x8

        src mac=0000.0000.0000, mask=0000.0000.0000

        dst mac=0000.0000.0000, mask=0100.0000.0000

        input_ifc=inside, output_ifc=any

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   0.0.0.0         0.0.0.0         outside

Phase: 3

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group inside_access_in in interface inside

access-list inside_access_in extended permit ip 10.200.0.0 255.255.                                                                                                                                                              0.0 object-group DM_INLINE_NETWORK_49

object-group network DM_INLINE_NETWORK_49

network-object 172.23.0.0 255.255.0.0

network-object 172.25.0.0 255.255.0.0

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xb0f653e0, priority=13, domain=permit, deny=false

        hits=881, user_data=0xaa828e00, cs_id=0x0, use_real_addr, flags=0x0, pro                                                                                                                                                              tocol=0

        src ip/id=10.200.0.0, mask=255.255.0.0, port=0

        dst ip/id=172.23.0.0, mask=255.255.0.0, port=0, dscp=0x0

        input_ifc=inside, output_ifc=any

Phase: 4

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xaf6afdb8, priority=0, domain=inspect-ip-options, deny=true

        hits=49504221, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0

        src ip/id=0.0.0.0, mask=0.0.0.0, port=0

        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

        input_ifc=inside, output_ifc=any

Phase: 5

Type: FOVER

Subtype: standby-update

Result: ALLOW

Config:

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xaf724f98, priority=20, domain=lu, deny=false

        hits=8251860, user_data=0x0, cs_id=0x0, flags=0x0, protocol=6

        src ip/id=0.0.0.0, mask=0.0.0.0, port=0

        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

        input_ifc=inside, output_ifc=any

Phase: 6

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (inside,outside) after-auto source dynamic any interface

Additional Information:

Dynamic translate 10.200.91.2/80 to /511

Forward Flow based lookup yields rule:

in  id=0xadd43648, priority=6, domain=nat, deny=false

        hits=20326950, user_data=0xae1c1380, cs_id=0x0, use_real_addr, flags=0x0                                                                                                                                                              , protocol=0

        src ip/id=0.0.0.0, mask=0.0.0.0, port=0

        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

        input_ifc=inside, output_ifc=outside

Phase: 7

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Reverse Flow based lookup yields rule:

in  id=0xae062c98, priority=0, domain=inspect-ip-options, deny=true

        hits=67577691, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0

        src ip/id=0.0.0.0, mask=0.0.0.0, port=0

        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

        input_ifc=outside, output_ifc=any

Phase: 8

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 93854460, packet dispatched to next module

Module information for forward flow ...

snp_fp_tracer_drop

snp_fp_inspect_ip_options

snp_fp_tcp_normalizer

snp_fp_translate

snp_fp_adjacency

snp_fp_fragment

snp_ifc_stat

Module information for reverse flow ...

snp_fp_tracer_drop

snp_fp_inspect_ip_options

snp_fp_translate

snp_fp_tcp_normalizer

snp_fp_adjacency

snp_fp_fragment

snp_ifc_stat

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: outside

output-status: up

output-line-status: up

Action: allow

Tried creating new objects and use those, but no change in behaviour.

The weirdness is that I have several other VPNs configured the exact same way on the same firewall, but different subnets. And they work as expected.

Hi,

I don't see a reason why it shouldnt match the other configured rule rather than the Dynamic PAT.

I might consider rebooting the device when the situation permits.

Though if I am not mistaken you have a Failover pair running so I wonder if switching the Active device would help.

Considering the configurations and output you have provided I dont see a configuration issue here.

- Jouni

Thank you for your input, I believe you are correct. I might be a victim of the following bug: http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtq47028&from=summary

I will try a failover to the standby node first.

Then i will perform an upgrade to the latest bugfree version.

I will credit you with correct answer

Also,

When you issue the "packet-tracer" command towards the remote network you should see a UN-NAT phase at the very start since you have defined the "destination static" in the command. In other words the ASA should first perform UN-NAT for the destination IP address.

So even considering that it seems strange that it doesnt match the NAT rule.

- Jouni

Review Cisco Networking products for a $25 gift card