Packet Tracer Output Testing L2L VPN Traffic

[rfranzke]

I am setting up a new FTD 2130 HA pair for use in a production environment. This is my first deployment with FTD so trying to test as much as possible before deploying these devices to understand as best I can how they work. 

I set up a bunch of NAT and access rules and have been using packet tracer in the diagnostic CLI to test they work. One thing I have set up here is a configuration for a site-to-site IPSEC VPN tunnel which will be needed to connect to a remote office when these devices are deployed. I have tried testing the rules allowing this VPN traffic using packet tracer. I have no real way of testing the VPN itself before deploying these devices so when running the packet tracer tests the VPN is currently down. There is also an Anyconnect RA VPN setup configured on these devices. Traffic is haripinned from RA VPN over the IPSEC tunnel using static NAT rules to get access to resources in our remote office via the IPSEC L2L tunnel. So think of these devices as being a central hub site where users VPN into the network but then access a remote office via the L2L tunnel over their Anyconnect VPN connections. I have set up the static NAT entries to facilitate the traffic hairpinning (I think). But when I run the packet tracer tests to test that this traffic will be able to run over the tunnel (which again is not up at the moment), I get the following:

Phase: 9     

Type: VPN

Subtype: encrypt

Result: DROP

Config:

Additional Information:

Result:

input-interface: inside(vrfid:0)

input-status: up

input-line-status: up

output-interface: outside(vrfid:0)

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame 0x000000aaad81207c flow (NA)/NA

I am not sure what this is telling me. So trying to understand if PT would show the traffic as dropped if the L2L VPN is not up,  currently, or if it doesn't matter if the VPN is up or not and what I am seeing is an actual configuration problem. The PT output shows drop at the VPN encrypt stage, but then shows the result as a drop due to a configured rule. So not sure if the results are because of an ACL or NAT rule I have wrong or if this is simply due to the L2L VPN not currently being available. Interestingly, I do not get a failure if I test traffic from the RA VPN to networks behind the FW without any of the AnyConnect clients being connected while I test. The only thing that fails is testing the hairpin traffic which leads me to believe that I have something incorrect with the hairpinning configurations. The failure only occurs for traffic from the Anyconnect RA VPN to the remote office VPN (so outside to outside traffic). What should PT show for traffic traversing an L2L tunnel if the tunnel is not currently up. Thanks for any help here.

[Rob Ingram · Accepted solution]

@rfranzke what was the source network of this PT? If you were testing from a RAVPN user network then the output indicates the source interface is "inside", but for RAVPN users the source would be "outside". The rest of the PT output should provide an indication on whether the traffic matched the correct NAT rule.

When running PT to simulate RAVPN user traffic you always need to run the test using a free IP address (an IP address not assigned to a currently logged in user).

PT needs the tunnel up, you always run PT twice when testing VPN, the first brings up the tunnel and the second PT test would provide the real result.

[rfranzke]

Thanks very much for the reply here. So for some context here is what I have:

Nteblock behind FTD (Inside Interface) - 10.20.0.0/16

Netblock for remote office - 10.10.0.0/16

RA VPN Netblock - 10.20.90.0/25

We have basically two sites: A Colo site and an office site. Colo site is where the FTD will be. Users connect to the Colo site via AnyConnect VPN and are assigned an address out of the VPN block, which they use to connect to resources in the 10.20.0.0/16 block and the Office block via the L2L VPN using the hairpinning. The PT results I showed were for testing access from the Colo site to the office site and the Office site to the Colo Site.. Here are examples of the PT tests I am doing:

packet-tracer input outside tcp 10.10.20.100 2244 10.20.20.105 33 Not Working

packet-tracer input inside tcp 10.20.20.100 2244 10.10.20.105 33 Not Working

So testing traffic from office to colo over L2L and then from Colo to office. Neither works:

packet-tracer input outside tcp 10.10.20.100 2244 10.20.20.105 33

Phase: 7

Type: VPN

Subtype: ipsec-tunnel-flow

Result: DROP

Config:

Additional Information:

Result:

input-interface: outside(vrfid:0)

input-status: up

input-line-status: up

output-interface: inside(vrfid:0)

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame 0x000000aaad81207c flow (NA)/NA

packet-tracer input inside tcp 10.20.20.100 2244 10.10.20.105 33

Phase: 9     

Type: VPN

Subtype: encrypt

Result: DROP

Config:

Additional Information:

Result:

input-interface: inside(vrfid:0)

input-status: up

input-line-status: up

output-interface: outside(vrfid:0)

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame 0x000000aaad81207c flow (NA)/NA

Both seem to not work for different reasons but both don't work as they require the L2L VPN to be up.

Interestingly when I test the Anyconnect connections those work without any connections actually running and they list VPN/IPSEC when Anyconnect is SSL based:

packet-tracer input outside tcp 10.20.90.1 2244 10.20.10.100 33

Phase: 8

Type: VPN

Subtype: ipsec-tunnel-flow

Result: ALLOW

Config:

Additional Information:

Anyway, it seems that anything that requires the L2L tunnel fails. I cannot get the tunnel to come up during these tests as the VPN and IPs for it are used currently by the devices being replaced by the FTD. @Rob Ingram thanks for reminding me about the need to do the tests twice, one to initate the VPN and the second to have PT show you the correct output for it. I think I now recall reading that somewhere but had forgotten it. If you are saying the L2L VPN needs to be up for PT to show you the correct output then I'll just chalk these failures up to that being the case. I thought that was the issue but thanks for the confirmation.

[MHM Cisco World]

Packet tracer with detail keyword at end,

This give use some info why this packet drop