Using packet-tracer to bring up tunnel?

[slug420]

Can anyone confirm for me that using packet-tracer to generate interesting traffic will still bring up a site to site VPN tunnel in 8.4 ASA code (and beyond)?

Having some trouble with a tunnel, have been using packet-tracer for testing to try to bring it up but its not working.....wanted to make sure i have a problem with my tunnel and im not just hitting a wall because cisco changed this functionality in newer code.

[Jouni Forss]

Hi,

Yes, you should still be able to use the "packet-tracer" command to initiate the VPN negotiation. I use it constantly on the ASA we have VPN connections on (some only for VPN purposes).

Its a great way to test the VPN negotiation especially on some older softwares where you dont have any other tools or perhaps access to internal hosts to generate traffic.

If the "packet-tracer" results in a VPN Phase DROP even on the second time you issue the same command then it means that the VPN negotiation doesnt go through. The first time you enter the "packet-tracer" command it will initiate the negotiation and it will result in a DROP always. The second time you enter the same command if the VPN negotiation has gone through will go through all the way.

In the newer softwares you also have the option to use

ping tcp

to generate TCP traffic to the actual tunnel.

- Jouni

[Pawel Cecot]

Yes, the packet-tracer will bring up an IPSec vpn tunnel.

Pawel

[slug420]

thanks...

Do you have any recommended ipsec/ike/etc debugs to use in 8.4 to see the attempted tunnel negotiation when you run the packet-tracer?  For some reason I havent been able to generate any useful insight as to why my tunnel isnt coming up on this firewall....my first time with 8.4...all prior experience has been with 8.2 and earlier

Phase: 5

Type: VPN

Subtype: encrypt

Result: DROP

Config:

Additional Information:

Forward Flow based lookup yields rule:

out id=0xb55c22d8, priority=70, domain=encrypt, deny=false

        hits=21, user_data=0x0, cs_id=0xb14da958, reverse, flags=0x0, protocol=0

        src ip/id=10.1.1.0, mask=255.255.255.0, port=0

        dst ip/id=10.2.2.128, mask=255.255.255.128, port=0, dscp=0x0

        input_ifc=any, output_ifc=Quahog

Thats what I am seeing...definitely expecting to see some failed ipsec/ike negotiations...

[Jouni Forss]

Hi,

The actual "packet-tracer" output wont tell you anything specific about the VPN negotiations.

I am not sure how many IPsec VPN connections you have configured on your ASA firewall but I would suggest doing the following

• Issue the "packet-tracer" command that matches the L2L VPN configurations twice
• Issue "show crypto isakmp sa" or "show crypto ikev1 sa" command and find the section related to the public remote peer IP address of the VPN connection you are generating the negoation for. If that Phase1 negotiation is going through then I would go through the Phase2 configuration with the remote end

- Jouni

[slug420]

I know packet tracer itself wont give me information, but in the past I have run debugs while runnign packet tracer and if there is an error with the negotiation between VPN peers or if one peer is unreachable it I usually get clues in the debug information which compliment the packet tracer results nicely....for some reason this ASA isnt showing me anything useful in the way of detailed log messages or debugs when the tunnel fails to come up...

[Jouni Forss]

Hi,

So what does the "show crypto isakmp sa" or "show crypto ikev1 sa" show when you have issued the "packet-tracer" command?

I personally rarely run debugs right at the start of troubleshooting as the problem can usually be found with going through the output of some other commands like the ones I mentioned above.

Ofcourse the starting point should be that all the parameters of the L2L VPN have been agreed upon before hand for example with a filled document.

You say you dont see anything in the debug? Is the same for all the other VPN connections on this same device? Or is this the only VPN on this device?

- Jouni