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.
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
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
Forward Flow based lookup yields rule:
out id=0xb55c22d8, priority=70, domain=encrypt, deny=false
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
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...
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...