Hi, I have some vpn lan2lan on an ASA5510. I noticed that only one of them uses ipseclan2lanovernatT as protocol. All other vpns use ipseclan2lan even if nat-t traversal is enabled. Why is there this difference?
Vpn that uses ipseclan2lanovernatT, goes down every 24 hours. Lifetime is the default one (86400 seconds). Is it normal?
This would suggest that there is NAT occurring between the IPSec tunnel endpoints for one of your LAN-to-LAN tunnels, or perhaps one of the other endpoints differs in terms of its NAT discovery capabilities.
If there is activity on the tunnel, new IPSec SAs would normally be established prior to expiration of the pre-existing SAs lifetime.
If there is no activity on the tunnel, the IPSec SAs would expire.
Some choose to use NTP (Network Time Protocol) or some other protocol to maintain periodic activity on the tunnel to keep it in an UP state.
I have another question. I configured a vpn StS between a pix 501 6.3(5) and an Asa 5510 7.2(1) with pfs DH group5. This morning vpn was up but there were some problems: ping didn't work even if last week it was working. Ping stopped to work yesterday, when vpn was recreated. Could it be a problem caused by pfs group 5 on pix 501?
When you say the VPN was "UP" this morning, I assume you are saying that you have verified the presence of IPSec SAs, and that the packet encapsulation counter is incrementing (traffic is traversing the tunnel).
When you say the VPN was "recreated", I'm assuming that you brought the tunnel down, made changes to crypto policy (PFS DH group 5), initiated the negotiation of "new" IPSec SAs, and verified that new IPSec SAs were successfully negotiated.
If the IPSec endpoints successfully negotiated new IPSec SAs (based on new policy), I would not expect PFS DH group 5 to have any impact on the transported traffic (ping or otherwise).
If the tunnel is currently up, and some traffic is successfully transiting the tunnel, I would consider whether there were other configuration changes that were introduced.
You didn't indicate whether the failed ping was directed at the external PIX/ASA interface or a host on the inside network, or whether an intermediate device between the two endpoints might be blocking the ping query/response. A packet sniffer might help you identify the cause.
Only transmitted packets encapsulation counter of Asa was incrementing, while received packets were not incrementing. I wrote vpn was recreated because time counter on Asa indicated that vpn was up since the day before. It means vpn stopped and restarted automatically, doesn't it? I control both firewalls and I didn't change anything in configurations. My doubt is: could it be possible that if I configure pfs group5 to create vpn, firewalls sometimes negotiate bad and, even if on both sides vpn seems to be ok, traffic don't go correctly into the tunnel?
I would not rely on a "time counter" presented in the GUI.
I would be verifying presence of IPSec SAs with identical inbound/outbound SPIs on each side of the tunnel, and examining all crypto related counters on both sides (to extract whatever info I could).
Then I'd probably clear all SAs (ISAKMP and IPSec) from the database, initiate a new tunnel negotiation while monitoring IPSec debug output, attempt to push some traffic through the tunnel, and repeat the steps in the preceding paragraph.
If you are confident that "PFS Group5" was the "only" configuration change performed on "both" devices, perhaps you should restore the original setting (no PFS, different PFS Group) on both endpoints, and retest to "prove" that no pre-existing issues existed.
If you prove that no pre-existing issues existed, then if you wish to re-introduce "PFS Group5", do so while monitoring the negotiation, then retest.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...