Hi – my central office peplink is sitting on a very fast, very reliable, publicly routable network. I initially setup the device with only a WAN1 interface – the intention is that the WAN1 ip of this box be the speedfusion remote ip used by each of our remote sites. This actually worked however the speedfusion initialization never completed – the process would hang forever with ‘Updating routes’ displayed in the status menu of each peplink. I theorized that the speedfusion process must learn about the networks connected to each peer via that peer’s LAN interface – so I configured the LAN interface on the central node with another address on the same network as the WAN1 interface. This seems to work I think – but I**'**m not entirely sure if its the ‘right thing’? Will this cause problems? Is there a better way?
Additionally we externally advertise the central node as owning the ‘route’ to the networks on the remote sites. Which ip addresses should own the route in this case – that of the LAN interface or that of the WAN1 interface? I’m advertising the LAN’s ip addresses as having a route to the remote sites and it seems to be working – however I’m not entirely sure if I’m running afoul of the way the firewall configuration works (the intention to have a firewall on the central node to allow or certain kinds of access to the remote site through the speedfusion)… Thanks for any advice.
Peplink does a NAT from the LAN to WAN interfaces so the LAN network must be unique from the WANs. Here is a knowledge base article to help get you started.
Hi – I’ve already configured speedfusion, its up and seems to be functioning correctly so the kb article you link to isn’t particularly relevant to me …
I disabled the NAT on the shore box already as in this screenshot – note that as I tried to make clear, the only traffic routing via the central node peplink is traffic destined for speedfusion managed ip space – on my nodes, the remote networks actually contain public ip space, however for policy purposes and for reliability purposes we desire that the only way to get to that ip space is via the central office’s peplink – hence the peplink at the central site. The peplink at the central office however, is sitting on a very fast publicly routable network, so its a bit strange that I have to configure two interfaces … Anyway what I’ve done seems to be working. As in the picture I disabled nat in favor of ‘ip forwarding’ – firewall rules at the central office are defined as ‘outbound firewall rules’ limiting which ip address can initiate traffic to the remote networks.
