06-17-2014 08:41 AM - edited 02-21-2020 07:41 PM
Hello,
Here is my current scenario:
I have multiple sites connected via ASA site-to-site VPNs. I have a remote access VPN for end users that provides access to all subnets over the site-to-site VPNs (via hairpinning). The remote access VPN is a full tunnel -- I am not using a split-tunnel.
Remote access clients are able to access the subnets directly connected to the ASA as well as the remote subnets across the site-to-site VPNs. They are also able to reach the Internet as well so everything is working except for one strange issue: pinging an Internet site does not work. I can access HTTP on Internet boxes via the RA VPN just fine but cannot ping the same machine.
Packet-tracer output simulating the returning echo-reply shows an rpf-check DROP:
packet-tracer input outside icmp 8.8.8.8 0 0 192.168.201.1 detailed
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xad9f6308, priority=13, domain=capture, deny=false
hits=201181261, user_data=0xada495a0, cs_id=0x0, l3_type=0x0
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0000.0000.0000
input_ifc=outside, output_ifc=any
Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0xaccdc300, priority=1, domain=permit, deny=false
hits=877365051, 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=outside, output_ifc=any
Phase: 3
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 outside
Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside_access_in in interface outside
access-list outside_access_in extended permit icmp any4 any4 echo-reply
Additional Information:
Forward Flow based lookup yields rule:
in id=0xaccb7490, priority=13, domain=permit, deny=false
hits=254, user_data=0xaa3ce980, cs_id=0x0, use_real_addr, flags=0x0, protocol=1
src ip/id=0.0.0.0, mask=0.0.0.0, icmp-type=0, tag=0
dst ip/id=0.0.0.0, mask=0.0.0.0, icmp-code=0, tag=0 dscp=0x0
input_ifc=outside, output_ifc=any
Phase: 5
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xac67cf88, priority=0, domain=nat-per-session, deny=true
hits=1692980, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0 dscp=0x0
input_ifc=any, output_ifc=any
Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xacce1d90, priority=0, domain=inspect-ip-options, deny=true
hits=3204188, 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, tag=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0 dscp=0x0
input_ifc=outside, output_ifc=any
Phase: 7
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xacce1890, priority=66, domain=inspect-icmp-error, deny=false
hits=239361, user_data=0xacce0ea0, cs_id=0x0, use_real_addr, flags=0x0, protocol=1
src ip/id=0.0.0.0, mask=0.0.0.0, icmp-type=0, tag=0
dst ip/id=0.0.0.0, mask=0.0.0.0, icmp-code=0, tag=0 dscp=0x0
input_ifc=outside, output_ifc=any
Phase: 8
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xad649f40, priority=13, domain=ipsec-tunnel-flow, deny=true
hits=137286, user_data=0x0, cs_id=0x0, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0 dscp=0x0
input_ifc=outside, output_ifc=any
Phase: 9
Type: DEBUG-ICMP
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xadcb5780, priority=13, domain=debug-icmp-trace, deny=false
hits=1881, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=1
src ip/id=0.0.0.0, mask=0.0.0.0, icmp-type=0, tag=0
dst ip/id=0.0.0.0, mask=0.0.0.0, icmp-code=0, tag=0 dscp=0x0
input_ifc=outside, output_ifc=any
Phase: 10
Type: L2TP-PPP
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
out id=0xad699ff0, priority=70, domain=l2tp-ppp, deny=false
hits=1559, 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, tag=0
dst ip/id=192.168.201.1, mask=255.255.255.255, port=0, tag=0 dscp=0x0
input_ifc=any, output_ifc=outside
Phase: 11
Type: PPP
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
out id=0xadcd3500, priority=70, domain=ppp, deny=false
hits=1559, user_data=0xa889b460, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
dst ip/id=192.168.201.1, mask=255.255.255.255, port=0, tag=0 dscp=0x0
input_ifc=any, output_ifc=outside
Phase: 12
Type: NAT
Subtype: rpf-check
Result: DROP
Config:
object network OBJ_192.168.201.0
nat (outside,outside) dynamic interface
Additional Information:
Forward Flow based lookup yields rule:
out id=0xadad6f68, priority=6, domain=nat-reverse, deny=false
hits=10, user_data=0xacd87130, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
dst ip/id=192.168.201.0, mask=255.255.255.0, port=0, tag=0 dscp=0x0
input_ifc=outside, output_ifc=outside
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
The only nat configurations I have are as follows where
OBJ_INTERNAL = subnet off inside interface of ASA
OTHER_NETWORKS = object group containing subnets reachable over site-to-site VPNs
OBJ_192.168.201.0 = VPN client IP pool
nat (outside,outside) source static OBJ_192.168.201.0 OBJ_192.168.201.0 destination static OTHER_NETWORKS OTHER_NETWORKS no-proxy-arp route-lookup
nat (inside,any) source static OBJ_INTERNAL OBJ_INTERNAL destination static OTHER_NETWORKS OTHER_NETWORKS no-proxy-arp route-lookup
nat (inside,any) source static OBJ_INTERNAL OBJ_INTERNAL destination static OBJ_192.168.201.0 OBJ_192.168.201.0 no-proxy-arp route-lookup
!
object network OBJ_192.168.201.0
nat (outside,outside) dynamic interface
If I run an ICMP debug trace, it looks correct but my RA VPN client doesn't get the reply:
ICMP echo request from outside:192.168.201.2 to outside:8.8.8.8 ID=55608 seq=0 len=56
ICMP echo request translating outside:192.168.201.2 to outside:<outside_ip>
ICMP echo reply from outside:8.8.8.8 to outside:<outside_ip> ID=55608 seq=0 len=56
ICMP echo reply untranslating outside:<outside_ip> to outside:192.168.201.2
ICMP echo request from outside:192.168.201.2 to outside:8.8.8.8 ID=55608 seq=1 len=56
ICMP echo request translating outside:192.168.201.2 to outside:<outside_ip>
ICMP echo reply from outside:8.8.8.8 to outside:<outside_ip> ID=55608 seq=1 len=56
ICMP echo reply untranslating outside:<outside_ip> to outside:192.168.201.2
The only route I have defined is to my default gateway from the ISP.
I can't see why other traffic can hairpin from the RA VPN client -> ASA outside -> Internet but ICMP traffic cannot.
Any help would be much appreciated!
Solved! Go to Solution.
06-17-2014 10:21 AM
Hi,
do you have the inspect configured for icmp???
Also your packet tracer conf looks quite confusing you have mentioned 8.8.8.8 as the source which gives the different look for the rpf cause. Because your VPN pool will get translated to outside interface ip and then go out to hit 8.8.8.8 and then return to the interface ip and get untranslated to private ip back.
HTH
Regards
Karthik
06-17-2014 10:21 AM
Hi,
do you have the inspect configured for icmp???
Also your packet tracer conf looks quite confusing you have mentioned 8.8.8.8 as the source which gives the different look for the rpf cause. Because your VPN pool will get translated to outside interface ip and then go out to hit 8.8.8.8 and then return to the interface ip and get untranslated to private ip back.
HTH
Regards
Karthik
06-17-2014 10:21 AM
You hit the nail on the head -- thank you sir! The following commands fixed the issue:
# policy-map global_policy
# class inspection_default
# inspect icmp
06-17-2014 11:01 AM
Cool. Happy to see your issue got fixed.
Actually i was editing my post for asking few more doubts on this issue... ;)
Regards
Karthik
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