DHCP Reservations or Relay for Fusion Hub Clients, or Selected NAT over PepVPN.

Request:
Here’s what I’m looking for. On a Fusion hub we use our Datacenters to provide WAN access to our clients, we want to use the Peplink device (Balance 20x, BR1-Mini, etc.) as the actual edge router for our clients instead of sticking another firewall behind it. These clients need Static IP addresses for outside access needs requested by 3rd party vendors. We can do that by NAT on the PepVPN tunnel, but that doesn’t allow DHCP reservations or Static Configurations.

History:
Right now The only way we have feesibly accomplished this is by sticking yet another firewall behind the peplink device. Then creating a L2 PepVPN tunnel to our datacenter where that is bridged to one of our core routers. Unfortunately for us, this has a few drawbacks. First is device malfunction, We have had a long issue with a very large name vendor in the industry having software on their devices fail and begin arping for either all the network traffic or the gateway. This for us has been a headache to troubleshoot each time due to the lack of L2 visibility the devices provide. From support’s request we tried L2 isolation to fix the issue. However that causes a whole other raft of problems. Like if two devices need to talk to each other, that’s broken. But it still doesn’t fix the Arp issue, it just moves it upstream.

So what we’ve relegated ourselves to is just to use the Peplink device as the access router as well. The problem here is that we need to have the traffic Natted to a unified IP address. Which means each peplink device needs to have all it’s traffic go out a PepVPN tunnel to our Datacenter, through our Security systems and out to the internet. Howevever you cannot build outbound NAT rules for the PepVPN because it’s treated like a LAN interface and not a LAN.

Any idea what it would take to implement a feature in the fusionhub/peplink devices like this?

So the end result is to have a unique public IP for each remote site, and handle port forwarding / NAT at the DC?

I’d probably look into adding a second interface to the FusionHub and then hang another virtual router / firewall off to the side of it to handle this sort of thing. We do this with a CSR100v or Foritgate VM depending on requirements quite a bit.

Might not be viable though depending on your config at the remote sites, in our instance we are in full control of the IP schema / allocations so there are no overlaps for us to worry about and we don’t have NAT on the PepVPN tunnels themselves.

That’s what we’re doing now with L2 tunnels. We bridge them through to my ASR’s using the LAN.

The problem I have is we have firewalls from Cisco that go off the rails and start ARPing for the entire network. This breaks everything at L2 without playing the reboot round robin with devices. L2 isolation just moves this upstream to the connected switch behind the fusion hub. Still has the same issue overall though.

What we’d like to do is have each Peplink at the site have a public IP directly on it and handle Port forwarding/NAT through policy. But still have a standard static IP address across whatever wan connections there are.

The IDS/IPS at our side is just through a L2 device or to a firewall that is doing inspection of the traffic looking for things that the security features of the Peplink don’t provide.

I didn’t say to build L2 tunnels between the remote sites and the hubs, build a L3 PepVPN tunnel like and route the traffic through it, no NAT mess on the hubs or tunnels. Basically drop a small /29 or whatever on the LAN side of the remote devices and turn up OSPF/BGP or even static routes to whatever you have hanging off the LAN side of the hubs.

This won’t let you do exactly what you want as yes PepVPN interfaces are generally not seen as “WAN” as far s Peplink are concerned but it might solve your L2 related problems, and sounds like you might need that ASA or Firewpower whatever it is for other reasons anyway (I feel your pain, we have some customers with very large ASA5585-X active/active clusters and they are a nightmare!). :slight_smile:

Ps - This is where we tend to also resort to deploying a physical Balance in the DC side for L2 tunnel needs as you can at least drop the remote sites into different VLANs at the Balance, which you can’t do on the FusionHub. Hint hint Peplink, another potential place where a more featured VM appliance would maybe be helpful!