ipsec lan2lan over natT

Unanswered Question
Jun 13th, 2008
User Badges:

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?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
michael.leblanc Fri, 06/13/2008 - 09:01
User Badges:
  • Silver, 250 points or more

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.

gdspa Mon, 06/16/2008 - 00:00
User Badges:

Thank you for your answer michael.

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?

michael.leblanc Mon, 06/16/2008 - 07:11
User Badges:
  • Silver, 250 points or more

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.

Farrukh Haroon Mon, 06/16/2008 - 08:54
User Badges:
  • Red, 2250 points or more

It could also be a performance issue. Maybe you have other tunnels on the box?. The more secure the DH group is, the more processing it will require.



gdspa Tue, 06/17/2008 - 04:47
User Badges:

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?

michael.leblanc Tue, 06/17/2008 - 07:30
User Badges:
  • Silver, 250 points or more

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.

a.alekseev Wed, 06/18/2008 - 07:33
User Badges:
  • Gold, 750 points or more

try to enable "isakmp keepalive" on both sides


This Discussion