Hi ! Would like to have the same option to NAT different LAN’s in PEPVN like you have on IPSEC. Today we only have the option to NAT all networks behind one IP on PEPVPN ( 7.1.0 ).
Virtual Networking Mapping is available on 7.1. IN network settings click the question mark icon on the static route section to enable it.
You then get one to one or one to many mapping options for PepVPN connections:
5 Likes
Thank you !
1 Like
Martin, can you give us an example where this would be useful, and what entries would be made to set it up?
I would think the biggest use case is for MSPs where you deploy SD-WAN as a service to your customers and have no ability to change their subnet.
Picture a scenario where you have two remote devices in customer offices both using the same LAN subnet (192.168.1.1/24) with PepVPN back to a FusionHub in the cloud.
Lets assume they are sites owned by the same customer who wants to keep their configurations at all their locations exactly the same for support purposes and you want to install a Network video Recorder and some CCTV cameras - retail outlets is a great example of this.
So Site A has a NVR with an IP of 192.168.1.100 and Site B also has a NVR with the same IP 192.168.1.100.
As the MSP part of your service includes remote monitoring so you somehow need to be able to route traffic to and from both NVRs over PepVPN.
Without virtual network mapping this is impossible since both sites have the same subnet, whichever one connects via VPN last will generate a route conflict and won’t be accessible over PepVPN from your Fusionhub.
Virtual network mapping is a fix for this scenario. Using it we can overlay an IP addressing scheme that fits our requirement as a MSP and ignores what the customer LAN subnet is.
So I might setup Virtual Network Mapping like this for Site A:
And like this for Site B
Once applied, I would be able to access the NVR at site A on 172.16.1.100 and the one on site B as 172.16.2.100, and in fact with one to one virtual NAT I can access any IP on the remote sites just by changing the host part. So if I wanted to access a IP camera on site A with an IP address of 192.168.1.101 I would use 172.16.1.101 (The same camera on Site B would be accessible on 172.16.2.101).
Many to One NAT is used purely to cope with route conflicts. All PepVPN traffic from the LAN devices at the remote sites will appear to come from the single IP address that is set here. This would enable you to provide SpeedFusion bonding as a service for example to multiple customers who all have the same LAN subnet configured without suffering from route conflicts.
3 Likes
Exactly we have over 50 vessels where 3 networks have shared ip so we really needed this functionality. 
Hi Martin,
This looks great and is exactly what we need to implement for our fleet management. I have been testing this between our head end Balance 310 and a BR1 on our ‘test vessel’. However, when I apply the VNM it doesn’t actually do anything. With the VPN established, I can still successfully ping the BR1 from the Balance on it’s original address (192.168.50.1) but get no response when I ping the virtual address that we have assigned in the one-to-one NAT setting field (172.16.10.1).
No doubt I’m missing something very simple! I have followed your instructions and also the youtube video pepVPN vnm from Steve Taylor.
Clutching at straws but would the VNM only ‘kick in’ if an IP conflict is found between two remote sites (in my testing to date I only have the one remote site so no conflict exists)?
Are there any other pointers on settings that we should check to enable this feature successfully?
Thank you in advance for any advice.