As confirmed by Peplink support, it is not currently possible to NAT IPsec traffic on VPN tunnels terminated on a Balance – sometimes also referred to as D-NAT or S-NAT. We must use another device to perform the NAT before routing to the Balance.
It would be a great benefit to add this NAT functionality to the Balance firmware – many site-to-site VPN tunnels interfacing with Juniper/Cisco equipment require all tunnel traffic to originate from a single IP address (aka. “proxy ID”).
Proxy ID is usually defined in the format of x.x.x.x/y which is actually a subnet and not a single IP address. Would you mind to share your Cisco config with us so we can have a check and see if we can help solving the problem?
For this tunnel, our counterparty is requiring us to use a Proxy ID of A.B.C.D/32 for all vpn traffic. This Proxy ID is different than the tunnel endpoint/peer IP.
Here is an equivalent Cisco config:
access-list tunnel_acl permit ip A.B.C.D 255.255.255.255 10.10.76.0 255.255.255.0
access-list tunnel_acl permit ip A.B.C.D 255.255.255.255 10.10.127.214 255.255.255.255
access-list tunnel_nat permit ip 10.0.0.0 255.255.255.0 10.10.76.0 255.255.255.0
access-list tunnel_nat permit ip 10.0.0.0 255.255.255.0 10.10.127.214 255.255.255.255
crypto map test 8 ipsec-isakmp
crypto map test 8 match address tunnel_acl
crypto map test 8 set peer W.X.Y.Z
And here is an equivalent LibreSwan/OpenSwan & IPtables config:
conn test
type=tunnel
pfs=no
ikelifetime=86400s
keylife=28800s
left=W.X.Y.Z
leftsubnets={10.10.76.0/24 10.10.127.214/32}
right=A.B.C.D
rightnexthop=A.B.C.1
rightsubnet=A.B.C.D/32
Thanks Aaron, it’s clear now, this definitely make sense.
The main idea of this feature is NAT before the packets go into the IPsec tunnel, it can be translated to a single /32 IP address just like your example above, and we are also considering another use case to do a 1-to-1 NAT mapping, just like the iptables NETMAP extensions do, to help our IPsec users to avoid any network conflict.
I have queued this up on our development roadmap, I can’t give you an exact date of release, but we’ll definitely look into this. Stay tuned.
A new section will then appear in Local Networks settings, in the upper part you can define the proposed networks (that the remote IPsec gateway will see, probably the virtual NAT network), and in the lower part you can define the NAT policy, Local Network is the real network that exist on the device (e.g. LAN, VLAN, or static routes), NAT Network is the translated virtual network that you need.
Some configuration examples have been given in the Local Networks help text, if there is anything not clear, please don’t hesitate to ask and we will clean it up and push them to the final 6.3.0 GA release. Thank you so much for your patience to wait for the feature and I hope this will fit your needs