When making IPsec site-to-site VPN connections, connecting parties often require the encryption domain they connect to through VNS3 to use Public IPs as the encryption domain. This request is typical when connecting to a telecommunication partner. Using public IPs as the remote encryption domains ensures no address overlap between internal and other remote connections.Scenario The third party is requiring a unique public IP for the "Gateway IP", but then also another public IP for the "encryption domain". The connecting partner won't take ANY private IPs in their tunnel definitions. Can VNS3 solve this problem?Solution Yes, this is something we do all the time, and is fairly straightforward to set up. Depending on the complexity of your use-case our VNS3:vpn (Formerly VNS3 Free Edition) might do it for you, and at least will let you see how it works. Here is the gist: Let's pretend the network behind your customer's device is: 10.10.0.0/16 And their IPsec device is 220.127.116.11 Let's pretend your VNS3 Overlay Network is: 172.16.0.0/22 And your VNS3 instance gets an EIP of 18.104.22.168 You make the basic IPsec endpoint connection between your 22.214.171.124 - 126.96.36.199 The problem is they won't talk to your host at 172.16.0.17 on your 172.16.0.0/22 Overlay Network (for example). What you do is, in another VPC, preferably a separate AWS account, allocate an EIP but DO NOT associate it to anything. Leave it there, and alone "forever". Let's pretend you received 188.8.131.52. Now use that public IP in VNS3 to define the endpoint to the partner's IPsec device. So instead of trying to create tunnel/cryptomap/policy from 172.16.0.17/32 - 10.10.0.0/16 you will do: 184.108.40.206/32 - 10.10.0.0/16 Then in a simple operation in the VNS3 Firewall we "netmap" the inbound traffic for 220.127.116.11 to 172.16.0.17/32 and back again on the way out. Example below: PREROUTING_CUST -i eth0 -s 10.10.0.0/16 -d 18.104.22.168/32 -j NETMAP --to 172.16.0.17/32 POSTROUTING_CUST -o eth0 -s 172.16.0.17/32 -d 10.10.0.0/16 -j NETMAP --to 22.214.171.124/32 NOTE: in the event you are using the unencrypted underlay VLAN for your cloud network as an alternative to the unencrypted Overlay Network, simple include this additional rule in the VNS3 firewall: FORWARD_CUST -j ACCEPT Problem solved!