Speed Fusion VPN Multitenancy

Peplink,

Is there a road-map to support multitenant configurations on the Speed Fusion Hub. Why must I have to run multiple hubs in a MSP configuration to give clients isolated network services?

Hi,

This is on road map. We understand the concern of running multiple FusionHub instances. We do not have ETA yet. Please stay tuned.

Do you only require multi-tenancy for security purposes? Ie to stop traffic routing between customers? Or is there another reason?

Martin,

Yes for security reasons and management reasons. I would like to offer
services similar to MPLS like virtual networks.

Barranett Farquharson, Jr.
CTO

Cinetcomm, LLC

PO Box 571148

Las Vegas, NV 89157-1148

Office: (702) 844 2410

Mobile: (818) 210 2848

So the way we do this currently is by sticking a firewall virtual appliance next to the fusionhub in the cloud. Then you tick the box on the Fusionhub to send all remote pepVPN traffic via the LAN to the FW appliance and you can then control & secure all routing between all remote peers.

An added benefit is you can have multiple public IPs on the firewall appliance - allocate one per customer, and not only let them breakout to the internet on their own dedicated public IP put also do easy port forwarding from that public IP to devices on the customers remote peer.

In this configuration the Fusionhub acts as a VPN concentrator, and the FW appliance is responsible for all the firewall and routing rules - which it is much better at doing to be honest.

2 Likes

Martin,

That’s interesting. I was already thinking of using a virtual Fortigate in a DMZ with the fusion hub. Most of our clients wont touch the internet but mainly applications and connectivity back to their own data-centers. Do you have a sample architecture of this?

So traffic comes into the fusion who then advertises it to the FW via OSPF? then the FW can put them in VRF context if necessary.

Yes thats right. When you tick the send all traffic via LAN, the Fusionhub adds a default rule for all remote peer traffic to be redirected via the LAN of the firewall appliance. However I don’t tend to use OSPF for subsequent routing as I prefer manual control.

Instead I group customers/services by subnet (ie all remote CCTV in 10.1.x.x/24, bonded internet customers in 10.5.x.x/24, multi site customers in 192.x.x.x etc) and then add firewall rules and static routes based on function / customer type. By planning your subnetting you can then create an efficient set of firewall rules to either allow or deny traffic based on source/destination. So a generic rule to block all remote customer inter-site traffic, but specific ones higher up to allow a single customers remote sites to all communicate with each other.

The real magic happens when you duplicate this topology in another geographically distant datacenter on a completely different hypervisor from a different provider and then tunnel between the Fusionhubs. That way the remote peplink devices can create a pair of PepVPN tunnels one to the primary DC and the other to the secondary DC and you have a highly resilient setup with automatic failover.

Take it one step further and you can then move to using the PepVPN infrastructure as underlying transport only - which some of my customers do. This is where we provide the above as a private secure network linking peplink devices deployed at customer sites into which they plug their own third party routing devices and create GRE tunnels back to their own central routing platforms - thus providing VRF context based private routing. The benefit here is that we can then provide bonded (and failover) connectivity transparently to remote sites and vehicles using whatever connectivity is available (fiber, DSL and cellular) and the customers can provision remote sites as they normally would completely ignorant of the underlying connectivity.

1 Like

Martin,

Makes sense. I would like to speak further with you about my use case and setting up the proper design that scales and is easy to manage. I have mesh and partial mesh use cases that will need to connect into multi-site configurations. Our current core runs OSPF with BGP, we have both core and FW edge tiers. all peplink connections will come in from Private APN’s.

The PepVPN idea makes great sense.

1 Like

Martin

“This is where we provide the above as a private secure network linking peplink devices deployed at customer sites into which they plug their own third party routing devices and create GRE tunnels back to their own central routing platforms - thus providing VRF context based private routing”

Can we also provide L2 services in this configuration and if using the PEP VPN does the customer have to create GRE or can we just run OSPF from his router to the onsite Peplink device and advertise his routes across?

1 Like

Always happy to help out with design work - PM me here.

Fusionhub as yet does not support OSPF or L2 PepVPN. You can configure a L2 bridge over GRE from the customer device to a third party gre core. I have customers who use FusionHub appliances for Layer 3 and Balance appliances for L2 where needed currently. If using customer configured GRE from a 3rd party router on the LAN of the remote Peplink you wouldn’t want to run OSPF.

1 Like

We use a SonicWall NSA 6600 to segment VPN traffic between 85 and counting sites for customers that want our premium SNMP monitoring service.

Yes we connect via VPN to each site now and have the SonicWall segment and separate the traffic between each client but we will be moving toward Logic Monitor soon s we use Connectwise as our PSA, with a remote probe, which will be going forward though. No I don’t care to give away info. as anyone can sell tech but it takes a genie to maintain and support it.

Clients connected via vpn to our PRTG server are through site to site IPsec from Balance to SonicWall. If the Balance was able to handle internal rules similar to a true UTM them we would just buy say a pair of 1350 or even 2500 and connect all off our sites via Pepvpn or Speedfusion dependent on the remote device.

Keep in mind that I am a VoIP Company monitoring SNMP traffic and monetizing on this more and more by the month.

We rely on Peplink for ease of use and the support on this forum.

At the minimum I feel Peplink should convert toward the “1 Rule Firewall Policy” as well as Outbound Policy to stay current.

I CANT STAND SONICWALL SUPPORT, HEY SONICWALL. I USE YOU FOR CERTAIN CASE SCENARIO AND THATS IT!!!

Peplink is almost there on many fronts. I feel when Peplink finds the true balance between easy of use, load balancing, UTM capabilities, and keeps the same support then it’s game on and all road’s lead to money.

Sorry to rant guys, I just see see so much potential and even more programming which I understand but I’m telling you if you come out with a 1 policy firewall rule alone then your sales will double.

Regards,

TJ

1 Like

Martin,

Is there a road-map for OSPF support on the FusionHub? If I have hundreds of customers coming into my core will I need static routes for each network. It would be nice if the Fusion adv the prefixes learned for the edge.

1 Like

Would you mind to elaborate more on the “1 Rule Firewall Policy”?

1 Like

No not for each - so long as you have your subnetting planned. You could use a supernet static route to direct traffic back to the Fusionhub (so 10.0.0.0/8 → fusionhub IP which would catch all the /16/24/32 subnets and route them in the right direction), then use firewall rule sets to block or allow communication between individual customer networks - it takes some planning but you can easily manage routing and firewall rules for hundreds of sites with just a handful of rules and routes. The trick is service standardization so you can categorize the remote peer sites easily and manage them with a limited number of rules/routes.

If you have larger customers with more complicated or larger numbers of sites then they can be migrated to their own Fusionhub/firewall pair if needed.

I should clarify that the Fusionhub does support OSPF for remote peer routes, That’s how the Fusionhub to Fusionhub routing discovery of remote peers works - I just haven’t seen the ability to use OSPF (or RIP for that matter) to share remote routes with 3rd party routing devices sat alongside the Fusionhub.

1 Like

Hey WeiMing,

This is referring to creating a single firewall rule for as many ports, applications, networks, hosts as needed for say a specified subnet or subnets as opposed to creating a single rule for everything like now and just having a very cluttered not so easy to manage set of firewall rules. And assuming this can be done then applying this to the outbound policies I’m assuming wouldn’t be to much of a problem then.

Regards,

TJ

1 Like

Wow so they’ve never heard of the Zebra Daemon? they could have RIP,OSPF and BGP all at once. I currently use virtual fortinets in my DMZ and it would be easy to just setup OSPF or BGP to carry the prefixes from the edge of my network to the internet or any other sites where application servers are housed. Maybe I should use the Balance router instead would this allow me to use OSPF upstream?

TJ,

Yes this would actually be very nice indeed.

There is full support for RIP and OSPF in the full Balance product. FusionHub is intentionally a stripped down feature set of the Balance - originally designed to be ‘just’ a neat fast cloud based VPN concentrator rather than a full routing product.

Over time more and more features have been added to FusionHub, but each one is hard won and very carefully considered by the product management team.

I still hope that one day we will have a fully featured virtual Balance appliance - but I understand this is not planned as yet.

3 Likes

So I’m better of using a Balance product and just connecting it to my VM firewall

1 Like

Well it depends. If you have a co-location facility where you can host hardware appliances (you’ll need two for resilience) and you can commercially justify doing that (the hosting fees and the capex of the hardware purchases), and you want full routing capabilities from your core PepVPN/SpeedFusion appliance alone then yes perhaps.

Personally I wouldn’t. The capability to spin up a Fusionhub appliance quickly in just about any datacenter environment - anywhere, and the ability to start with a small 5 peer licensed instance that can scale to 1000’s of remote peers later is just too valuable to me technically and operationally.

We have clients running virtual Opensource Firewall appliances alongside virtual Fusionhubs in active / active dual datacenter configurations supporting hundreds of remote peers with the hosting costing <$250/month. And when more capacity is needed, or new points of presence in new countries are required (to improve latency for new deployments) I can do that for them from my desk here within hours.

There is always a middle ground of course. As a MSP you could offer multiple tiers of service. The entry level tier with enforced configuration limitations (to simplify operational demands from routing / security config perspective), that has functional/feature limitations (no Layer2, lower remote peer count limits, NAT only perhaps) and then a gold level service with all the additional features possible when using a physical balance - at a higher cost.

1 Like