I’ve just setup a FusionHub VPS Server which is running quite well. But after trying to connect the second router to it, it looks like it isn’t working at all. Looks like I’m doing something wrong.
I do get a ‘route conflict’ and updating routes all the time.
I setup the FusionHub. Within the Speedfusion VPN Profile I defined several Remote IDs and Pre-shared Keys.
Every router does connect well with the FusionHub server. But when trying to connect both the issues do come up.
I also tried ‘Allow shared Remote ID’ but if I unterstand correct this is related to something else?!
So what am I doing wrong?
Is it maybe because the routers do have the same ‘internal’ IP-addresses? Or is it something else which I’m missing at the moment?
Hey Den,
which License do you have on your fusionhub? How many peers are you allowed to connect to your fusionhub? You can check this under System ->License
You can buy the right License from your distributor.
So it looks like we need to buy some small (but expensive) license in that case.
Why do you get Care (Essential Care and so on) plans for FusionHub licenses? Don’t understand the licensing there.
It’s cheaper to run multiple instances of the Solo version, as the license is free. Each Peplink you buy and link to your inControl gives you one FusionHub Solo license.
When you need inControl after the first year, you can use the inControl license (ICS-012), which is cheap. This same inControl2 license is also compatible with the FusionHub Essential and FusionHub Pro.
If you need active support, you need to pay for that support the same as you would for their hardware products, first year included in price.
My understanding is that peers under prime care do not count towards the limit of a FusionHub Solo. I have seen a solo-licensed FusionHub serve 10+ peers. One of the peers being an older BR1 (not prime), the others being a mix of B20X and BR1 Pro units (all under prime care coverage).
If you have overlapped subnets on the remote sites that are being advertised to the hub multiple times you will see things stuck “updating routes” as it would be creating a conflict.
You could enable NAT on the VPN profile to work around this, though a better and neater solution is generally to uniquely address each remote site as it would make passing traffic between them easier in the future.
If you do not need every subnet from every remote site advertising to the hub you could also filter them from the OSPF advertisements, same for advertising static routes into the VPN.
As for licensing I can confirm you should be fine with the FH Solo licence if all your devices connecting to it are under Prime Care support (well, you get one free licence slot for a non-prime care device), we have a couple of hubs handling a dozens of remote endpoints working this way just fine and has been for a number of years now.
If you have remote sites where you are using pairs of Peplink routers in HA they also only consume one licence on the hub side too as they share a remote ID.
Each node router on the network has its own untagged LAN IP address. We use 192.168.nn.0/24, with nn being a unique number for each node.
VLANs on the nodes are created for each distinct, local functionality (e.g., IoT LAN, guest LAN, Asia LAN, etc.), possibly with systemwide SSID names for corresponding Wi-FI networks. VLANs/SSIDs with the same functionality are named (and numbered) the same across all nodes, as appropriate. E.g., 192.168.204.0/24 is the IoT network everywhere, 192.168.210.0/24 is the network for routing to an Asia breakout node everywhere) likely overlapping in address assignment from one node to the next - which does not matter (see the next step).
Network Advertising is enabled, but only for the Untagged LAN. Therefore overlapping VLAN address spaces/assignments do not matter.
Consequently:
There are no routing conflicts (because only the node-distinct address spaces are shared).
The SSID and firewall rules w.r.t. local LANs are identical across all nodes (e.g., IoT devices are all isolated, all Asia LAN packets are routed to the hub (see below)).
For SSIDs that are defined across multiple nodes the same SSID/PW combo works on all. Easy roaming.
Outbound policies are all the same (e.g., all packets with an Asia LAN source IP address are routed to an Asia breakout node, or more interestingly, all packets with an Asia LAN source IP address may be routed to the hub, which then routes them through its Asia breakout connection (remember, the source IP address retains its Asia VLAN IP address)).
(Almost) all done with IC2 (the exception being the network advertising setting).
