I’m trying to setup a fail-over system using the PepVPN hot fail-over. The FusionHub is running as a VM on a server at our internet gateway and we have a selection of remote sites in the internal network that have pepwave devices as routers. These client sites are polled by servers outside out network in the clients company headquarters, they have public IPs that the clients polling servers use to access equipment on each site. What I’m trying to setup is to have the FusionHub assign Nat’d addresses to the pepwave’s vpn interface so that if/when the pepwaves fail-over to cellular connections during any problem with the microwave network the public addresses will still be available to outside clients through the FusionHubs NAT’d VPN connections.
However I cannot get the profiles to connect in NAT mode, they seem to work fine until I try to check the NAT mode box, I’ve configured a SpeedFusion DHCP range, but nada. Do the pepwaves need to be getting their IPs from the FusionHub via DHCP in order to get this to work?
We have other sites where the clients have preferred their own routers and we’ve passed public address through a layer 2 pepVPN without the FusionHub and had it fail over from microwave to cell with no trouble so I’m not sure why I can’t get it to work in NAT mode with the address on the pepwave itself as opposed to on a router behind them.
You’ll have to forgive my shoddy network diagram skills.
What I’d like is to put the public IP on the pepVPN “interface” of the BR1 so that all the incoming connections to the site were being run through the from the FusionHub. This way it wouldn’t matter which connection the pepwave was using to connect to the FusionHub, the site would be available for the same IP.
The clients polling server requests data in a manner similar to a snmpget but using some other system (SCADA and MODBUS I think, the “sites” behind the pepwave are geographically large multi-point systems connected via 9600 baud vhf radios) on different ports depending on which equipment behind the pepwave their polling. the polling server is hardcoded with IP-port pairs which are related to specific analog device variables, a few of these logs are then tied to ESD (Emergency ShutDown) triggers. Previously each site had a cell modem, but as the areas developed the numbers grew to the point where a) the cell network is becoming increasingly unstable because it’s remote and was not designed to take the that many connections (a single omni antenna for a 200km radius) and b) the cost of cellular modem connections is becoming prohibitive.
We’re attempting to replace the bulk of those connections with a high speed microwave network access, but due to the ESD issue downtime is a large concern as ground access to some sites is seasonal, hence the fail-over to cell plan. which brings us back to the pepVPN as the system requires that the devices be reachable behind a consistent IP address, so we need a way of having the pepwave fall-over from microwave to celular without changing the IP the server is using to poll it.
In order for us to understand your environment and requirement better, can you share more details with us?
The netwrok segment between FushionHub WAN and Gateway Router is Public IP range, eg. 200.1.1.1/28 or 200.1.1.1/29, eg:
FusionHub WAN IP: 200.1.1.2/28
Gateway Router IP: 200.1.1.1/28
The application flow is Polling Server will initiate a session to FushionHub NAT’ed IPs, which associated to Max BR1 PepVPN/SpeedFusion tunnel, eg:
IP: 200.1.1.11 represent Max BR1 Site #1
IP: 200.1.1.12 represent Max BR1 Site #2
IP: 200.1.1.13 represent Max BR1 Site #3
The equipment (eg. SCADA and MODBUS) behind the Max BR1 will be accessed by Polling Server by hardcoded IP-Port pairs, eg:
IP-Port: 200.1.1.11:4001 represent Max BR1 Site #1 - Equipment #1
IP-Port: 200.1.1.11:4002 represent Max BR1 Site #1 - Equipment #2
IP-Port: 200.1.1.12:4001 represent Max BR1 Site #2 - Equipment #1
IP-Port: 200.1.1.12:4002 represent Max BR1 Site #2 - Equipment #2
IP-Port: 200.1.1.13:4001 represent Max BR1 Site #3 - Equipment #1
IP-Port: 200.1.1.13:4002 represent Max BR1 Site #3 - Equipment #2
Currently, the primary link for PepVPN/SpeedFusion for the Max BR1 sites is Cellular, and it will be replaced by Microwave links. So ultimate WAN options for the Max BR1 sites will be:
Primary WAN for PepVPN/SpeedFusion tunnel - Microwave link
Backup/Fail-over WAN for PepVPN/SpeedFusion tunnel - Cellular link
With the proposed setup, regardless of which WAN link (Microwave or Cellular) used in Max BR1 sites to establish PepVPN/SpeedFusion to FusionHub, the Polling Server will still able to retrieve data from the equipment (eg. SCADA and MODBUS) by the IP-Port pairs stated in item (3) above, eg:
Scenario #1
Site #1
Primary WAN for PepVPN/SpeedFusion - Microwave link
Backup/Fail-over WAN - Cellular
IP-Port pair for equipment #1 - 200.1.1.11:4001
Scenario #2
Site #1
Microwave link DOWN
Cellular link establish PepVPN/SpeedFusion to FusionHub
IP-Port pair for equipment #1 - 200.1.1.11:4001 (remain unchanged)
Do let us know if these description explain your situation, and let us if you have other points to highlight.
Network segments at the gateway:
Gateway router interconnect address: 204.209.28.233/30
Routered public IP Subnet: 192.174.6.0/25
BGP and OSPF dynamic internal address subnet routes 10.10.x.x, 172.28.x.x there are 4 network segments between the gateway and the BR1s in this instance
FusionHub IP: 192.174.6.54/29
FusionHub pepVPN DHCP pool 192.174.6…/27
That is what I’d like to implement, yes 192.174.6.3 is BR1 site x
3)Yes that is accurate
Currently the modems in place are not peplink devices, but are cellular wan only modems which we are replacing the the BR1s in order to implement the microwave links. Once this is done then yes the primary will be the microwave links and the back-up connections will be the cellular
Yes, that’s what I’d like to see if I can get the NAT mode pepVPN to have the public IP. The BR1 will have a route-able internal address eg, 172.28.150.x on the microwave network and either a public or internal IP on the cellular. If the the pepVPN can establish a link without a public address on the cellular interface that would be preferable as it would cut cost overhead. The polling server would use the public address assigned to the VPN interface, which would route from the server to the FusionHub, then through the vpn to the BR1 regardless of which BR1 interface the vpn is operating with
peplinks are a fairly new product for us, we started using them in order to acheive this functionality. I had first attempted a number of layer 2 connections from the FusionHub to the BR1s in order to pass the public address to a client supplied router behind the BR1. I figured out that functionality is not yet available in the FusionHub and had to setup BR1s on both ends in order to make it work, until layer 2 bridging is supported in the FusionHub. I had thought that this would be more straight forward as the BR1 in this scenario is the router all I needed was to NAT to the vpn interface. However I can’t seem to get the profiles to connect in NAT mode. The FusionHub is configured with a pepVPN DHCP pool of public addresses, when I check the box for NAT mode I lose the field where I can fill in the remote IP addresses. So I’m not sure how the NAT mode is designed to be used or if I’m over looking something. It seems like it should be fairly straight forward, but I’m at a loss as to where I’m going off the rails.
