Some presale questions for the Peplink Balance One

Hi,

I am currently cross shopping the Peplink Balance One with the Cisco RV325 and had a few questions.

1 - Does the Peplink Balance One do SSL VPN Tunnels with the Cisco Small Business RV Line of routers? Specifically, I am working with RV220Ws

2 - Will it be possible for the Balance One to support HA at some point? I am very space limited at my colocation so I cannot devote 2U just for routers unfortunately.

3 - Currently, all my public IP systems connects to a Cisco SG200-50 switch which uplinks to the colocation’s port. Will I be able to get load balancing and firewall through the balance once I move to the configuration outlined below?

Colocation (Two static public IPS) —> Peplink Balance One (WAN1 and WAN2) —> Cisco SG200-50 Switch Connected to LAN1 (Default VLAN, no tagging) on Peplink ----> Servers with public WAN interfaces.

Then PepLink Balance One LAN2 connects to VLAN101 on the SG200 where ports 24-48 have been set up as VLAN101 access ports. The Peplink would need to provide DHCP to VLAN101, serve as a router for the VLAN and create an SSL VPN Tunnel from that private network.

Thanks in advance for your help!

HI,
In answer to your questions:

  1. The Balance One does not support SSL VPN at this time.
  2. It is unlikely that the Balance One will support HA in the future. The B1 is designed as an entry level/prosumer device and so HA which is an enterprise feature doesn’t fit with this categorisation.
  3. The usual way we would see this kind of configuration is public IPs on the WAN of the Balance and then servers on the LAN side in a private subnet with the Balance performing NAT and PAT to the internal servers/applications.
    3b. The Balance supports VLAN tagging on the LAN and can provide DHCP and inter vlan routing for all configured LAN VLANs.

I’d like to confirm the underlying goal here.

  1. Is it primarily for connectivity resilience for the remote rv220w at the remote sites to the servers at the colocation site?
  2. I assume the two static IPs are on the same physical public network connection - or do the public IPs have different network routes into the colocation site?
  3. What is the WAN connectivity at the colocation site?
  4. Are the servers physical or virtual? If virtual what hypervisor is in use?
  5. How many remote sites with RV220Ws are there?
  6. Do the remote sites have multiple WAN links?
  7. What issues are you trying to solve by using Peplink products?

Thanks,
Martin

Hi Martin,

Thanks for the quick reply.

In regards to #1, I actually meant IPSEC VPN Tunnel - sorry not SSL.

For #3 there will be servers on a private networks that will use NAT, but then there will also be servers connected to the Balance LAN ports that require public IPS as well.

The Balance One would sit at the colocation and have the following goals -

1 - Take two different wan connections (It will appear to be the same ISP to the Peplink) for redundancy and load balancing.
2 - Serve as a hub for two IPSEC VPN tunnels. The end points are Cisco RV220W routers and these locations have one WAN and a dynamic IP (but I use DDNS).
3 - Serve as a VPN server for clients wanting to access the private networks behind the Balance One.
4 - Provide DDOS mitigation/firewall features for the public IPs that connect through the Balance One. I am not quite sure how/if this would work as the Balance One would serve a router for the servers with Public IP addresses. However, if I take an example Webserver like 55.55.55.55 it would be connected to a layer 2 switch that uplinks to the Balance One that would have IPs of 55.55.55.50 and 55.55.55.51 as an example for the WAN interfaces. Linux web servers already have local firewalls but anything on top would be a bonus.

To answer your questions:

1 - We are concerned about connectivity resilience at the colocation because that is where the main production servers are housed. External customers and our internal network connects to resources hosted at the colocation.
2 - The two physical public IPs for use with the Balance One come from the same ISP. My guess is adjacent IP addresses from a /29
3 - The WAN connectivity speed is up to 100MB - that is the speed of the ports I have access to.
4 - The servers are mostly virtual.The hypervisor is VMWare
5 - Two remote sites with RV220Ws.
6 - The remote sites would have dual wan in the future and hopefully use Peplink products, but just single WAN over Cisco at this time.
7 - See goals above.

To clarify, this is what we should expect for users who connect to our colocation over the Balance One right?

1 - Incoming connections across the WAN IPs behind the balance one for example a range like 55.55.55.40-68 would be load balanced and redundant across the two WAN ips.
2 - The IPSEC Tunnels would not be load balanced and resilient because they have to ‘pick’ an IP to create the tunnel against?

and is there any way to be able to use the two WAN IPS to achieve better performance/throughput for website visitors? Right now the theoretical limit is 100MB for the one Wan link. Not sure if two can find a way to get 200MB to the website visitors.

Thanks again for your help.

Hi,
Our devices support IPSEC tunnels so that bit is fine, the challenge here is the mix of servers with both Public & Private IPs behind the balance where you want the balance to act as both a L2 bridge and perform NAT.
With our current feature set you are restricted to one or the other. Typically we will see a balance router providing NAT/PAT to devices with private IPs on its LAN(s) using public IPs on its WAN (The Balance One Supports this), of course we also support Layer 3 routing without NAT too (WAN IP Forwarding). These are standard approaches of course in most typical deployments. However we also support the idea of a Balance acting as a transparent L2 bridge in what we call Drop in Mode. Drop in Mode is supported on our Blue Chip series of devices (the Balance 210 and up see the comparison chart here)

Here are some links to better understand Drop in Mode and its implementation:
http://www.peplink.com/knowledgebase/video-what-is-drop-in-mode/
http://www.peplink.com/knowledgebase/design-and-implement-peplink-speedfusion-site-to-site-vpn-with-drop-in-mode/
http://www.peplink.com/knowledgebase/how-many-ip-addresses-does-peplink-balance-consume-under-drop-in-mode/
http://www.peplink.com/knowledgebase/can-i-have-multiple-wan-connections-in-drop-in-mode/

So there isn’t an immediately obvious way to support your requirements currently - certainly not without topology changes.

If it was me, I’d likely try this approach:

  1. Using a Balance 580, I would have WAN1 + WAN2 in IP forwarding mode and WAN3 + WAN4 in NAT mode.
  2. WAN 1 and WAN2 would have public IP’s in different ranges (with different ISP Gateways), WAN 3 + WAN4 could share a public IP range (but have dedicated public IPs).
  3. On the untagged LAN segment I’d have a third Public IP range for the servers which need Public IPs, I’d also have a VLAN with a Private IP range for the NATed servers
  4. I’d get the ISP to adjust their metrics/routing so that inbound traffic for the Balance LAN side Public IP range uses both WAN1 + WAN2 as possible paths. That way if one WAN failed, traffic would still route to the servers with Public IPs via the 2nd WAN.
  5. I would use inbound load balancing on the WAN3+WAN4 ports to provide HA for the NATed Servers.
    Peplink | Pepwave - Forum

5.Then if budget allowed I’d add another 580 to create a HA VRRP pair.

However - this solution requires 2U of rack space which you did not want, and massive upheaval of your topology as well as ISP involvement, which is likely not what you want either.

So if I take my Peplink hat off for a moment (placing it carefully on my desk beside me - I don’t do this often), I would then suggest you consider the following:

You have already invested heavily in a virtual environment so I think you should consider a fully virtual firewall appliance/router for your perimeter. Take a look at Vyatta and OPNsense - both are awesome. And you should also consider commercially available virtual L4/7 application delivery controllers like the Kemp Loadmaster.

A combination of these products for your specific cloud environment would likely be a good fit. Then when you have your perimeter routing sorted, (one sec as I put my Peplink hat back on) host aVirtual FusionHub Appliance and get rid of your IPSEC for your remote site connectivity using SpeedFusion VPN instead and take advantage of multi WAN packet level bonding and bandwidth aggregation at your remote sites to improve your users experience and availability.

Hope that helps,

Martin

I am as cheap as you are knowledgeable. (I think I am really cheap!) But I also really hate compromising on product quality or feature sets so how about this?

The internal NAT network is far less important than the uptime of the public IP systems.

The three most essential systems and how I propose to connect them would be:

A.) ESXi Host 1 -
NIC1 - Management, VM Network Traffic to Internet - Connects to Balance One LAN 1 Port
NIC2 - Management, VM Network Traffic to Internet - Connects to Layer 2 Switch (Just a failover link, uses same shared IP as NIC1)

  • The idea is that were the switch or the Balance one were to fail, WAN connectivity would be maintained.

NIC3 - Internal LAN / Storage Network - Example 10.100.100.10 - Connects to Layer 2 Switch which uplinks to a VPN Router. VPN Router takes care of internal network and IPSEC Tunnels.
NIC4 - Backup storage subnet to Balance One - Example 10.100.101.10 - Connects to LAN3 port of Balance One. Protocol is iSCSI using MPIO between 10.100.100.x and 10.100.101.x

  • The idea is that were switch or the Balance were to fail, Storage connectivity would remain although in a degraded state.

B.) ESXi Host 2 -
NIC1 - Management, VM Network Traffic to Internet - Connects to Balance One LAN 2 Port
NIC2 - Management, VM Network Traffic to Internet - Connects to Layer 2 Switch (Just a failover link, uses same shared IP as NIC1)

  • The idea is that were the switch or the Balance one were to fail, WAN connectivity would be maintained.

NIC3 - Internal LAN / Storage Network - Example 10.100.100.11 - Connects to Layer 2 Switch which uplinks to a VPN Router. VPN Router takes care of internal network and IPSEC Tunnels.
NIC4 - Backup storage subnet to Balance One - Example 10.100.101.11 - Connects to LAN3 port of Balance One. Protocol is iSCSI using MPIO between 10.100.100.x and 10.100.101.x

  • The idea is that were switch or the Balance were to fail, Storage connectivity would remain although in a degraded state.

C.) Network NAS -
NIC1 - Failover bond with NIC 2 on the Internal network. - Connected to layer 2 switch. Example 10.100.100.50
NIC2 - Failover bond with NIC 1 on the Internal network. - Connected to layer 2 switch. Example 10.100.100.50
NIC3 - Failover bond with NIC 4 on backup storage network - Connects to LAN3 of Balance One - Example: 10.100.101.50
NIC4 - Failover bond with NIC 3 on backup storage network - Connects to LAN4 of Balance One - Example: 10.100.101.50

I reduce my requirements to:

1 - Take two different wan connections (It will appear to be the same ISP to the Peplink) for redundancy and load balancing.
2 - Provide DDOS mitigation/firewall features for the public IPs that connect through LAN1 and LAN2 on Balance One. (No NAT)
3 - Use the Balance One as a switch for the storage backup subnet. No routing required.

In this scenario will the Balance One appropriately load balance between the two WAN networks for all traffic hitting the public IPs sitting behind NIC1 on ESXi Host 1 and ESXi Host 2? Would there be link aggregation? I want to make sure to try to get as many benefits as possible using a Balance One in this use case.

Is there a way I can optimize this design better?

Were the budget to become available the Balance One could be replaced with Balance 210 and everything would be the same except HA could be an option to keep all the WAN NICs on the balances?

I can use less powerful devices just for VPN routing to the not as essential internal network and accept network failure where the VPN router or the layer 2 switch goes down.

Thanks again for all of your help.

Hi,
This is hard to visualise without a network diagram - I might ask you to sketch one out if I have misunderstood your requirements above - read the following and decide if that’s a good idea or not.

  1. The Balance One does not support Drop in mode so your vms can’t have public IPs on your ESX boxes. To support drop in mode you’ll need a blue chip series device (Balance 210+)
  2. Even with an enterprise device, you can’t have the same network on more than one WAN - the router would not know which it should be using for that traffic. The way to achieve this is with a pair of Balance 210 or higher routers in a VRRP pair (active Passive) so that if one physical WAN link were to fail you would fail-over to the passive router and WAN connectivity would continue.
  3. We don’t support Jumbo frames on our balance products - which i expect you are using on your ESX iSCSI network.

::Reluctantly Takes Peplink hat off and puts in on the desk::

My recommendation for the cheapest approach here would be to add additional NICs to both ESX Hosts to be used as the public WAN connections. Then run a pair of free pfsense vms (one on each host) in a HA pair (pfSense® software Configuration Recipes — High Availability Configuration Example | pfSense Documentation ) . Or depending on your ESX configuration, set fault tolerance on a single VM so that if one ESX host’s public network (or hardware) failed the pfsense would be brought online immediately on the 2nd ESX host.

The pfsense vms can happily do IPSEC termination too, and there is a good guide here about pfsense and DDOS mitigation How to prevent and mititgate DDoS part 1? « Wedebugyou

::Hurriedly puts Peplink hat back on::
Then run a FusionHub vm for remote SpeedFusion termination.

Kindest,
Martin

Hi Martin,

Right now, I only have a layer 2 switch hooked up to a single WAN at my colocation. The WAN NIC on the two ESXi hosts have a public IP, so all the VMs underneath with public IP route internally route through the WAN NIC without issue.

1.) If the ESXi physical NIC can have a public IP connected to the LAN port of the Balance One, the VMs underneath should be fine as well right? Just an extension of my example above with the L2 switch.

2.) You could have the same network on the Balance One and the Layer 2 switch if only one was active at a time right? Unless configured differently, ESXi defaults to one active adapter and everything is passive for the management/public network. In theory, the NIC connected to the Layer 2 switch would only activate were the Balance One were to go offline (and consequently drop the link on the connected NIC) for some reason. Hopefully never, but just planning for worst case.

3.) This particular computing cluster is small scale with $4k in equipment costs so not fancy enough to warrant that level of tuning and engineering to deal with jumbo frames. Just doing regular 1GBE LAN over prosumer hardware. If I were to try to improve storage performance, direct 10GBE connect between the storage and ESXi host is probably best bang for buck/performance/redundancy/configuration hassle.

I agree with you that a pair of pfSense VMS with automatic HA vmotion turned off would be perfect here. Would be practically free and can cover all sorts of IPSEC VPN, VRRP and firewalling gadgets. There’s only three problems with this approach:

A.) I’m not a network engineer. :frowning: Sure I can tell you that a VLAN is a logical segmentation of broadcast domains on the same physical switch. Knowing the theory and actually going in there to configure switch ports, trunk ports, tagging and untagging stuff, troubleshooting on the packet level is a whole different game. =) A site to site VPN between two Peplink products might take five minutes to configure. The last pfsense ipsec VPN between a Cisco router and pfsense VM took me about two hours to get both ends happy enough to get a session. Once connected, took me another two hours to figure out why they are connected but I can’t ping anything across the tunnel. Apparently, you have to assign a gateway to the tunnel to to allow communication across the tunnel. AND by default no ports or protocols are allowed to communicate across the tunnel. It should be done this way and it’s surely the most secure this way but the five minute GUI clicker in me would be over my head for a long while. I would mind the pain less if I had unlimited time to learn all the awesome networking stuff.

B.) So uhmm, who do I call when I need help with virtual routers? I’m sure there is a ton of resources on pfSense but you have to have enough of a base to make sense of it or solve problems effectively. Not being a networking person, sometimes you don’t even know what questions to look for to solve a particular problem.

C.) Physical appliance is much easier for other people to support. I can ask someone to plug in a network cable, power cycle a switch, tell me what lights are green and orange. VMs are awesome and generally robust until a whack problem develops like this (rare but it does happen). The VM is locked up. You power it off with two mouse clicks (easy!). You then go to power it back it back on with two mouse clicks in theory. NOPE, vCenter says the VM is off and won’t let you power it on because a ESXi host has locked the virtual machine file. To release the lock, someone’s going to have to reboot the storage (and take down every other VM) or use the ESXi client to enable SSH. Then with SSH enabled, you console into the OS and try to find the VM file and what host and datastore it is - type in some long string to release the lock at the CLI. Possibly need to move all the running VMs to another host before rebooting the host with the stuck virtual router.

Lastly is Drop in mode layer two bridging? You mention you can pick layer 2 bridging or NAT but not both right? I’ll have NAT and private network taken care of with another device if the Peplink hardware can uplink the public IPs and load balance the WAN for them. While having the WAN ESXi NICS on LAN1 of the Balance One and having the iSCIS NIC on LAN2 of the Balance One technically be two networks, could the problem be solved this way?

1 - Put them on different VLANS
2 - The storage network would not route at all and have no gateway configured. It’d live on the same /24 as the storage.

Thanks again! It is getting closer, I may need to switch to 210 to get the functionality I’m desiring here.

Got it. Ok. PM me a network diagram of your set up with IP addressing (including VM public IPs) and I’ll come up with some suggestions for how to integrate a Balance 210 into this for you.