EndPoint VPN NAT limitations

[Dale_Lobb]

We are looking to possibly replace a Microsoft AlwaysOn deployment which supports roughly 750 users/devices with the CheckPoint EndPoint suite.

It appears that the CheckPoint EndPoint IPSEC VPN is what would be required to replicate the "always on VPN" capability.  Specifically, we want the user's corporate issued laptops to automatically instantiate the tunnel back to corporate any time they are powered on and network connected, without user intervention or involvement.  This enables smooth login with AD credentials and allows the laptop to be centrally managed by our corporate infrastructure.

Does anyone know what the CheckPoint central firewall will use as identifiers for the IPSEC tunnels back from the EndPoint clients?  Normal IPSEC VPN metadata is identified and indexed by the IP address from which the connection originates.  Thus one cannot, for instance, have multiple SMB appliances sharing the same routable NAT address.  Are the EndPoint IPSEC VPNs also identified in the same way?  I would hope not, because sharing NAT addresses has to be fairly common for remote devices, which is why we see the workarounds for it built into SSL VPN clients.

We've had lots of issues with AlwaysOn, which is also an IPSEC VPN, mostly with the client being unable to form a tunnel back to the VPN concentrator.  I'm worried as we test the CheckPoint replacement, that we may see the same issues; perhaps the issues with AlwaysOn exist because we live in a small city with only a few ISPs, and thus a lot of our user base may be sharing routable NAT IPs under the carrier grade NAT scheme.

So, does anyone know: Will we see any issues with EndPoint IPSEC clients sharing routable IP addresses?

[PhoneBoy]

Unless you’re using SecuRemote, each client is assigned an Office Mode IP that is unique.
Not sure what it looks like at the IPSec level but I’ve also never seen/heard of any issues related many users being behind the same NAT using our Remote Access VPN either.

[Timothy_Hall]

Having multiple VPN clients behind a single Hide NAT shouldn't be a problem.  Individual IKE negotiations are identified by cookies, and individual IPSec tunnels are identified by unique SPI (Security Parameter Index) values.  Because intervening NAT is present, NAT Traversal will be in use on UDP/4500.

Of course should the VPN client use SSL/TLS for the VPN transport instead, port numbers will be in use and modified/tracked by the NAT device.