s2s vpn pings get through but packet tracer shows drop

[Geminorum_cco]

Hi guys,

thanks for a great forum!

I've got a working vpn tunnel set up between 2 ASAs, i use the tunnel daily for management purposes. When i simulate traffic comming in on the tunnel in one end packet tracer shows a drop...

The flow is from gcoutside to the inside interface shared_vpn_inside.

packet-tracer input gcoutside tcp 192.168.77.109 10000 192.168.70.10 80 detail

It gives the following:

Phase: 8

Type: VPN

Subtype: ipsec-tunnel-flow

Result: DROP

Config:

Additional Information:

Forward Flow based lookup yields rule:

in  id=0x744b44f0, priority=69, domain=ipsec-tunnel-flow, deny=false

hits=32062, user_data=0xb2f965c, cs_id=0x0, reverse, flags=0x0, protocol=0

src ip/id=192.168.77.0, mask=255.255.255.0, port=0, tag=0

dst ip/id=192.168.70.0, mask=255.255.255.0, port=0, tag=0 dscp=0x0

input_ifc=gcoutside, output_ifc=any

And just to emphasize, everything across the tunnel works... I cant find any errors anywhere... Not in logs, nowhere.

Why is this when everything seems to be working?

Cheers

[Jouni Forss]

Hi,

Generally you wont be able to simulate a packet incoming from the external interface which builds the L2L VPN connection also.

When the L2L VPN connection is Active/UP you should be able to issue this command succesfully provided that no other configuration on the ASA blocks this packet (since its not a packet of an existing connection)

Using "packet-tracer" to test the direction from you internal network to the external remote network should be fine though. If the L2L VPN isnt up before testing this you should issue the "packet-tracer" command twice as the first one will only initiate the negotiation while the second time your insert the command the L2L VPN will be up (provided there is no problem on the L2L VPN)

Is your L2L VPN connection up while you issue this command OR is there a SA already for these networks you mention?

- Jouni

[Geminorum_cco]

Hey Jouni,

sry about the wait! Makes sence what you'r saying, but yes, the tunnel is up when i test it. I'm actually accessing the ASA across the tunnel... And the test i'm running is for traffic that works through the tunnel! Also, just now, i tried with adresses that i know havent established the connection i'm testing. So it definitely isnt colliding with existing connections.

/Kim

[Jouni Forss · Accepted solution]

Hi,

I guess I also might have remembered wrong. I don't tend to use the "packet-tracer" to test VPN connections direction from Remote to Local. I tend to use it to initiate the VPN negotiation when I dont have access to devices that can use the L2L VPN connection.

So it might well be that you just simply can't test connectivity regarding connection that are supposedly coming through a VPN Connection. Even if that VPN connection is currently up.

I actually tested this with just now with a couple of different ASA units and it didnt work for the connection that were up and negotiated SAs.

- Jouni

[Geminorum_cco]

Hi Jouni,

thanks yes, good tip with the tunnel initiation. Hadn't thought of that. But I was thinking the same thing when testing the inbound. Maybe someone like Keith Barker can explain exactly why this is, I'm sure there is a logical explanation there somewhere.

Thanks again!

[Jouni Forss]

Hi,

I would have to bet that its related to the fact that the ASA is expecting a encrypted/encapsulated packet if it were to match the VPN connection.

I do remember getting varying results with the "packet-tracer" when testing what you are attempting to do which is a bit confusing. Then again I dont use it. I rely on logs and packet captures when there is problems with traffic through a VPN connection.

- Jouni

[Geminorum_cco]

Hi

Yeah, could be that. Would make sense in its own twisted way... Anyways, you said it. Plenty of ways to test.

Thanks for your input!

Cheers