02-06-2014 12:09 AM
I'm trying to route a (customers) network from my datacenter firewall back to the office.
The office local address to which everything is nated to is 10.0.0.1
The customers remote network is 10.31.1.0/24
internal net 10.31.1.0/24 - [customer fw / 10.10.10.10 ] -> (ipsec vpn) -> [dc fw / 20.20.20.20] -> (ipsec vpn) -> [office fw / 30.30.30.30] -> internal net 10.0.0.0/24
Simulating with packet-tracer on dc fw interface outside FROM 10.0.0.1 to 10.31.1.0, it fails (first packet-tracer). But doing the same but on an internal interface of the dc fw it works, and consequently the ipsec phase 1 and phase 2 to the customer comes up.
I do have 'same-security-traffic permit intra-interface' configured.
Why is the same src and dst hosts/subnets failing when hairpinning. With debugging on ikev1 I can determine that the dc asa is not even trying to form tunnel with customer firewall.
mob-cn-asa# packet-tracer input outside tcp 10.0.0.1 1025 10.31.1.10 22 details
<snip>
Phase: 4
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (outside,outside) source static customer-nat-ip customer-nat-ip destination static customer customer
Additional Information:
NAT divert to egress interface outside
Untranslate 10.31.1.10/22 to 10.31.1.10/22
Phase: 5
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside_access_in in interface outside
access-list outside_access_in extended permit ip object-group SOMEGROUP any
object-group network SOMEGROUP
network-object object someobject
Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xabd78108, priority=0, domain=inspect-ip-options, deny=true
hits=11253143, 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: 7
Type: VPN
Subtype: ipsec-tunnel-flow
Result: DROP
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xa82a1728, priority=70, domain=ipsec-tunnel-flow, deny=false
hits=16, user_data=0x1d7583c, cs_id=0xac8fdd08, reverse, flags=0x0, protocol=0
src ip/id=10.0.0.0, mask=255.255.255.0, port=0
dst ip/id=10.31.1.0, mask=255.255.255.0, port=0, dscp=0x0
input_ifc=outside, output_ifc=any
Here on the internal interface, everything works and the tunnel comes up.
mob-cn-asa# packet-tracer input management tcp 10.0.0.1 1025 10.31.1.10 22 de
Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (management,outside) source static customer-nat-ip customer-nat-ip destination static customer customer
Additional Information:
NAT divert to egress interface outside
Untranslate 10.31.1.10/22 to 10.31.1.10/22
Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group management_access_in in interface management
access-list management_access_in extended permit ip object customer-nat-ip object-group customer
object-group network customer
network-object object customer_qa
network-object object customer_preprod
network-object object customer_preprod_virtual
network-object object customer_api
network-object object customer_new_api
Additional Information:
Forward Flow based lookup yields rule:
in id=0xacc47580, priority=13, domain=permit, deny=false
hits=3, user_data=0xa9608200, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip/id=10.0.0.1, mask=255.255.255.0, port=0
dst ip/id=10.31.1.0, mask=255.255.255.0, port=0, dscp=0x0
input_ifc=management, output_ifc=any
Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xabd0ac10, priority=0, domain=inspect-ip-options, deny=true
hits=10972287, 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=management, output_ifc=any
Phase: 5
Type: FLOW-EXPORT
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xac562fa8, priority=18, domain=flow-export, deny=false
hits=368181, user_data=0xaca4d568, 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=management, output_ifc=any
Phase: 6
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (management,outside) source static customer-nat-ip customer-nat-ip destination static customer customer
Additional Information:
Static translate 10.0.0.1/1025 to 10.0.0.1/1025
Forward Flow based lookup yields rule:
in id=0xacc192c0, priority=6, domain=nat, deny=false
hits=4, user_data=0xacc5df78, cs_id=0x0, flags=0x0, protocol=0
src ip/id=10.0.0.1, mask=255.255.255.0, port=0
dst ip/id=10.31.1.0, mask=255.255.255.0, port=0, dscp=0x0
input_ifc=management, output_ifc=outside
Phase: 7
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
out id=0xaca3c6b0, priority=70, domain=encrypt, deny=false
hits=1, user_data=0x1d8391c, cs_id=0xacc32c60, reverse, flags=0x0, protocol=0
src ip/id=10.0.0.0, mask=255.255.255.0, port=0
dst ip/id=10.31.1.0, mask=255.255.255.0, port=0, dscp=0x0
input_ifc=any, output_ifc=outside
Phase: 8
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (management,outside) source static customer-nat-ip customer-nat-ip destination static customer customer
Additional Information:
Forward Flow based lookup yields rule:
out id=0xacc240b0, priority=6, domain=nat-reverse, deny=false
hits=3, user_data=0xacc32220, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip/id=10.0.0.1, mask=255.255.255.0, port=0
dst ip/id=10.31.1.0, mask=255.255.255.0, port=0, dscp=0x0
input_ifc=management, output_ifc=outside
Phase: 9
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
Reverse Flow based lookup yields rule:
in id=0xacc45f90, priority=70, domain=ipsec-tunnel-flow, deny=false
hits=3, user_data=0x1d78294, cs_id=0xacc32c60, reverse, flags=0x0, protocol=0
src ip/id=10.31.1.0, mask=255.255.255.0, port=0
dst ip/id=10.0.0.1, mask=255.255.255.0, port=0, dscp=0x0
input_ifc=outside, output_ifc=any
02-06-2014 01:54 AM
Hi,
I am not sure if the ASA is able to simulate the packet that is supposed to be coming from a VPN connection and going to a VPN connection.
Testing from an internal LAN interface towards the WAN interface that forms the L2L VPN connection is usually fine.
It might be easier to troubleshoot this by looking at the L2L VPN related configurations (ACL included) and the NAT configurations from the firewalls.
- Jouni
02-06-2014 10:41 AM
Jouni is correct in that the ASA can not simulate an encrypted VPN packet comming in on the outside interface. this packet will be dropped as it will be seen as a spoofed packet.
So if you are going to test a VPN connection through the ASA using packet tracer you need to source from the internal network. If the tunnel is not already up the first packet tracer will fail because it is building the tunnel, the second packet tracer will pass successfully since the tunnel is now up due to the first trace.
--
Please remember to rate and select a correct answer
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