Unable to Connect Multiple VPN Clients via Linksys Router

We are an organization of 3 people who need to connect to our head office's VPN using Cisco VPN Client 4.0.5(Rel) client software over the Internet. We have installed the Linksys WRT54G (version 5, with Firmware Version: v1.01.0) wireless router with a Static IP address, and are using its DHCP server. We all have access to the Internet, however only one person can be logged into our VPN via the Cisco client at a time. If a 2nd or 3rd user attempts to log in, the other connected user is bumped out of the VPN and loses that connection. How can we overcome this issue?

We are using the VPN client with IPSec/UDP and have enabled Transparent Tunneling. All 3 of us do use the same Group Authentication name and password, but we each have different accounts when attempting to log into our VPN (each person has a unique Username and Password).

Any thoughts on how we can overcome this? I have tried switching to TCP, but that would now allow us to connect - so I think we need to use UDP. Would Port Forwarding work? If so, how would I set that up for both the laptops we use, the VPN clients, and the router?

Any help is much appreciated.

Thanks in advance, Morgan

Reply to
Loading thread data ...

Some low end consumer grade Internet routers have the "interesting" behavior that when doing NAT on low UDP ports such as UDP port 500, they will not NAT the source port.

So the client side is UDP source port 500, UDP destination port 500. And the internet side is UDP source port 500, UDP destination port 500.

This is desireable behavior when the first user connects.

When the second user connects, the NATed traffic is still UDP source port 500 and UDP destination port 500 on the Internet side And when the replies from the server come in, the two sessions are indistinguishable. The return traffic is routed to the second user and the first user is left out in the cold.

This is highly undesireable behavior. Cisco VPN concentrators will work just fine when the UDP source port is NATed. They don't need it to be 500.

You can get around this in several ways.

  1. Use NAT-T. Only the first packet out and back uses UDP port 500. The rest of the VPN session uses UDP port 4500. This may require upgrading your client. I don't think 4.05 supports NAT-T. If supported by both client and concentrator, NAT-T is the default.

  1. If the hub end concentrator is a Cisco then you can use TCP as your transport. The whole VPN session (IKE and all) goes over TCP port 10000 or whatever TCP port you choose to use.

  2. Use a halfway decent firewall/router.

TCP works fine if the firewall rules let the outbound traffic pass and if the concentrator is configured for it and if you know what port it's configured on.

Test by telnetting to the concentrator on TCP port 10000. If it works, you're gold. If the connection fails, something's not right.

If you can set up 3 different virtual addresses for the concentrator using NAT on the concentrator-side firewall then all 3 clients can connect, one to each alias address. The Cisco concentrator does not directly support multiple public IP addresses, however. You would need to fake that with NAT rules at the hub site. I know that works, having used that technique myself.

Reply to

Thanks a lot - I'll have to take this up with our technical team to see if this can resolve our issue. Thanks again!

Reply to

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.