VPN Client Question

[jimmydharia]

As far as I know the VPN clients(anyconnect or ipsec) or the firewall doesn't have a restriction that every client that connects and establishes a VPN session should have a unique public ip address. Let me elaborate, if we have 10 people(contractors) working out of a remote office behind a firewall, sharing a single public IP address and we don't want to create a site-site vpn connection then those 10 people can still use anyconnect to vpn into the Corporate office. 

They will all be sharing the same, single Public IP address when they VPN into HQ. 

[Boris Uskov · Accepted solution]

Hello, 

Yes, all people in remote location will be able to connect to Central Office with AnyConnect client, even if they have the single public IP address.
That is so, because different sessions from different AnyConnect clients will have different source TCP ports.

What about IPsec and old Cisco VPN Clients? The situation should be the same, because Cisco VPN Clients are behind NAT. So, they will have to use NAT-traversal and use UDP 4500 to encapsulate ESP session. And in UDP there will also be used different source port numbers.

[jimmydharia]

Than you that is what my understanding was too unless they have configured the following setting within the ASA 

Implementing NAT-Assigned IP to Public IP Connection

In rare situations, you might want to use a VPN peer’s real IP address on the inside network instead of an assigned local IP address. Normally with VPN, the peer is given an assigned local IP address to access the inside network. However, you might want to translate the local IP address back to the peer-s real public address if, for example, your inside servers and network security is based on the peer’s real IP address.

Cisco ASA 55xx introduced a way to translate the VPN client’s assigned IP address on the internal/protected network to its public (source) IP address. This feature supports the scenario where the target servers/services on the internal network and network security policy require communication with the VPN client’s public/source IP instead of the assigned IP on the internal corporate network.

You can enable this feature on one interface per tunnel group. Object NAT rules are dynamically added and deleted when the VPN session is established or disconnected.

Limitations

Because of routing issues, we do not recommend using this feature unless you know you need it.

· Only supports legacy Cisco VPN client (IKEv1) and AnyConnect clients.

·  Return traffic to the public IP addresses must be routed back to the ASA so the NAT policy and VPN policy can be applied.

· Only supports IPv4 assigned and public addresses.

· Multiple peers behind a NAT/PAT device are not supported.

· Does not support load balancing (because of routing issue).

·  Does not support roaming.

[Boris Uskov]

Cool :)

I have not used this feature before!

Of cource, with this feature enabled, multiple peers behind NAT/PAT can not be used.

Why they have enabled this feature? From my point of view it is much easier to create a special pool of IP-addresses (not from local subnet), and assign those IP-addresses to VPN Clients. In this way everything should work fine...

[jimmydharia]

:) No idea why they are using this feature but I do agree with you that a separate VPN pool of IP addresses is the way to go to. 

Thank you for your quick response.