My colleagues and I recently moved to a new office location. However, many of the network elements that we need to reach on the open internet can only be accessed from the public WAN IP on our NV4430 at our old office location, by virtue of management ACLs. This being the case, we will be leaving our internet connection and NV4430 firewall up at the old office indefinitely (the building is still ours), and we just connect to it via IPSec VPN when we need to, and tunnel all of our internet traffic through it.
This works fine. However, in the process of this move, we discovered that only one user at a time from our new office (i.e. behind our new office firewall NAT) can connect to the VPN at the old office. I found that as soon as a second user (coming from the same public IP) tries to connect and completes Phase 1 IKE negotiation, the first user is kicked off. As soon as the new user completes IKE authentication and spins up a new IPSec session to the NV4430 on port 4500, the first user's traffic is terminated. This is true even if the second user is using a different source port for
I have tried numerous things to get around this, including messing with NAT traversal settings (on client configurations as well as on the NV4430 configs); having users try to use unique ports for IKE negotiation (normally port 500), and even having users connect to different public IPs on the NV4430 (we have a range of public IPs on it). Nothing seems to work.
So to ask the question simply: Is there a way to allow multiple users sourcing from the same public address to connect to an Adtran IPSec VPN at the same time? Or am I running into a limitation of AOS?
Below are some printouts of the IP policy sessions on the NV4430 at various stages of what I am describing. "x.x.x.x" is the source IP that the VPN users are coming from. "y.y.y.y" is the public IP of the NV4430. If needed, I can provide my entire configuration, but would take some more time to scrub it down. Figured I would just ask the general question and see if this is just a known limitation of AOS.
My NV4430 is running R11.4.0.E.
Thanks!
router#sh ip policy-sessions | i x.x.x.x <--- First user has just connected, and is working
x.x.x.x 500 y.y.y.y 500
x.x.x.x 4500 y.y.y.y 4500
!
router#sh ip policy-sessions | i x.x.x.x <--- First user continues to work happily (the port 500 sessions has timed out since IKE is complete)
x.x.x.x 4500 y.y.y.y 4500
!
router#sh ip policy-sessions | i x.x.x.x <--- Second user has now connected. IKE negotiation has taken place, and a new IPSec traffic sessions is open, sourcing new port 42360
x.x.x.x 500 y.y.y.y 500
x.x.x.x 4500 y.y.y.y 4500
x.x.x.x 42360 y.y.y.y 4500
!
router#sh ip policy-sessions | i x.x.x.x <--- The first user has now been disconnected. His session (4500 -> 4500) is terminated, and will time out in a few seconds.
x.x.x.x 4500 y.y.y.y 4500
x.x.x.x 42360 y.y.y.y 4500
!
router#sh ip policy-sessions | i x.x.x.x <--- Second user happily working. First user is now sad.
x.x.x.x 42360 y.y.y.y 4500
Are the clients all sending the same local ID to the 4430?
In order for this to work, you will have to have each individual client send a unique local ID to the 4430. The same remote ID (from the 4430's perspective) can be used by multiple users, but there can only be one IKE SA per remote ID for a given IP address.
Try configuring additional remote ID's on the 4430 (or add a remote ID of "any") and configure the clients with unique local ID's. That should get this to work.
You could also try building a site-to-site VPN tunnel to the 4430 from your new site (if you have a unit at the new site that is capable of that) rather than relying on individual clients to connect.
Are the clients all sending the same local ID to the 4430?
In order for this to work, you will have to have each individual client send a unique local ID to the 4430. The same remote ID (from the 4430's perspective) can be used by multiple users, but there can only be one IKE SA per remote ID for a given IP address.
Try configuring additional remote ID's on the 4430 (or add a remote ID of "any") and configure the clients with unique local ID's. That should get this to work.
You could also try building a site-to-site VPN tunnel to the 4430 from your new site (if you have a unit at the new site that is capable of that) rather than relying on individual clients to connect.
Using unique local IDs on the client side fixed the problem. Thanks so much!