When setting up IPsec connections, connecting parties sometimes require tunnel to use a Public IP address as the encryption domain.
This request is typical when connecting to a telecommunication partner.  Using public IPs for the encryption domains ensures that there will be no address overlaps between other 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 allow ANY private IPs in their tunnel definitions.  Can VNS3 solve this problem?

Solution

Yes, this is something we do all the time, and it is fairly straightforward to set up.


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 at 33.33.33.33


Let's pretend your VNS3 Overlay Network is:
172.16.0.0/22
And your VNS3 instance gets an EIP of 55.55.55.55


The problem is they won't talk directly to your 172.16.0.0/22 Overlay Network (for example).


What you do is: in another VPC (preferably a separate AWS account), allocate a new EIP but DO NOT associate it to anything. Leave it there, and alone "forever". Let's pretend you received 74.64.74.64.


You would create the IPsec endpoint to 33.33.33.33 as normal, then use that new EIP to define the tunnel to the partner's IPsec device.


So instead of trying to create tunnel/cryptomap/policy like this: 172.16.0.17/32 - 10.10.0.0/16, you will do: 74.64.74.64/32 - 10.10.0.0/16


Then in a simple operation in the VNS3 Firewall, we need to "netmap" the inbound traffic for 74.64.74.64 to 172.16.0.17/32 and back again on the way out:

PREROUTING_CUST -s 10.10.0.0/16 -d 74.64.74.64/32 -j NETMAP --to 172.16.0.17/32
POSTROUTING_CUST -s 172.16.0.17/32 -d 10.10.0.0/16 -j NETMAP --to 74.64.74.64/32


Alternatively, you can use an SNAT rule to let you entire 172.16.0.0/22 overlay reach across:

POSTROUTING_CUST -s 172.16.0.0/22 -d 10.10.0.0/16 -j SNAT --to 74.64.74.64


In the second case, your peer would not be able to initiate connections to your overlay hosts due to the NAT.

In the first case, only the .17 host is able to use the tunnel, but connections can be made in either direction.


NOTE: in the event you are using the unencrypted underlay VLAN for your cloud network as an alternative to the unencrypted Overlay Network, simply include these additional rules in the VNS3 firewall to allow the traffic between your VPC and customer network.  (When you put in a vpn local/remote subnet pair - we "auto acl" those to allow traffic..so the 74.64.74.64/32 - 10.10.0.0/16 path is allowed, but the path to the "real" address is not, you have to add it.)


FORWARD_CUST -d 172.16.0.17/32 -s 10.10.0.0/16  -j ACCEPT

FORWARD_CUST -d 10.0.0.0/16 -s 172.16.0.17/32 -j ACCEPT