Problem with VPN 3030 connecting remote devices that receive their public I

Unanswered Question
Nov 9th, 2008
User Badges:

I am trying to set up a VPN 3030 that will be accessed by remote devices(routers) that receive their public IP address via DHCP. The Cisco document "ID 46002" was followed when setting this up.This document may be found at.

The VPN 3030 is running the IOS version 4.1.7.G

The inital set up with one remote device with a Security Association (SA) to the VPN 3030 (base group) using pre shared keys was succesfull. The pre shared keys were then replaced with digital certificates which also was successful.

The issue came when trying to connect a second remote device to the VPN 3030 (base group). When the second device connected and established its SA, the VPN 3030 issues a disconnect packet to the first device (or established SA).

When looking at the VPN 3030 logs with all IKE and IPSEC debugging enabled, it showed the VPN 3030 processes to create and send the disconnect message to the remote device.

To try and get around this problem, I then created on the VPN 3030 separate groups (group1 & group2) for each remote device and setup a filter tying each remote device and its digital certificate to a particular group (i.e. remote device 1 will only connect to the VPN 3030 group1 and remote device 2 will only connect to the vpn 3030 group2). Unfortunately the same problem still occured (established SA disconnected when second SA is established) although the remote devices were connecting to different groups configured in the VPN 3030.

Thinking there may be a problem using Digital Certificates, I then configured the second group to use pre shared keys, but again the same problem still persisted.

I could not find any reference to any limitation on the number of remote devices that receive their IP addresses via DHCP that can connect to the VPN 3030, I just hope that it is more than one.

If anyone has any ideas or knowledge of this I would greatly appreciate their input.



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)

I'm pretty sure that your remote routers are behind a NAT gateway. Try to enable NAT-T:

Configuration / System / Tunneling Protocols /

IPSec / NAT Transparency

Then, if using L2L, enable NAT-T on the L2L configuration screen.

If it doesn't help you probably run into the NAT-T limitation of the VPN3k for L2L. Try to use EasyVPN Remote Mode on your remote routers in this case.


wingingit Wed, 11/19/2008 - 19:33
User Badges:


Yes the remote routers are behind a NAT gateway. Am unable to use EasyVPN as the remote routers are other vendors kit.

I have enabled NAT-T etc but to no avail. It looks like the problem could be caused by the NAT-T limitiation of the vpn3000 as you mentioned.

Earlier release note (e.g. 3.6.8) state "Because NAT-T depends on UDP port 4500 being available, if a previous IPSec/UDP configuration is already using that port, you must reconfigure that earlier IPSec/UDP configuration to use a different UDP port".

Not sure how to do this yet.

From the doc:

The VPN Concentrator implementation of NAT-T supports IPSec peers behind a single NAT/PAT device as follows:

•One Microsoft L2TP/IPSec client.

•One LAN-to-LAN connection.

•Either a LAN-to-LAN connection or multiple remote access clients, but not a mixture of both.

Not sure where this limitation is coming from...


This Discussion