09-19-2013 08:53 AM - edited 03-11-2019 07:41 PM
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?
Solved! Go to Solution.
09-20-2013 02:39 AM
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
09-19-2013 09:02 AM
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
Can you share the complete "packet-tracer" output of the traffic matching wrong NAT rule
- Jouni
09-20-2013 02:28 AM
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
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
09-20-2013 02:34 AM
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.
09-20-2013 02:39 AM
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
09-20-2013 02:49 AM
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
09-20-2013 02:50 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide