OpenVPN access to all Speedfusion remote networks

Hi all,

I have a very weird problem.

I have a FusionHub instance on GCP and various remote locations with a BR1 setting up Speedfusion tunnels to the FusionHub. This has been working fine since long: the hosts on the various locations, behind their BR1s, can connect to the hosts on other locations. Routes are nicely advertised over the Speedfusion tunnels.

Today I enabled remote access using OpenVPN. This has worked fine as well: I got access to all hosts in all active remote locations using the “split tunnel” config. Note however I had to alter the remote IP address (of the VPN server) in the downloaded OpenVPN profile as there the internal GCP IP address was used instead of the public one, which is forwarding the necessary ports to the FusionHub instance.

Today I also added another remote location, called NewLoc, also with a BR1 setting up a Speedfusion tunnel to the FusionHub, which went fine, and I see its subnet 10.0.24.0/24 popping up as remote routes on the other locations.

However, this subnet 10.0.24.0/24 doesn’t pop up on the clients connected using OpenVPN. Even not when restarting the OpenVPN client and connection.

Also, from the other locations, I can ping the BR1 at 10.0.24.1 on the NewLoc, but cannot reach any device on its subnet 10.0.24.0/24.

Even more: since a reboot of both the BR1 and the FusionHub, the OpenVPN service doesn’t work anymore as it should be: I only see the “remote user access” network appearing in the routing table of the client, and no longer the subnets of the various remote locations which are connected using Speedfusion tunnels to the Fusionhub.

If I manually add a route to the 10.0.24.0/24 subnet in my routing table, I can ping to the BR1 on 10.0.24.1, but not to other devices on that network. However, from those devices in that network, I can ping to my computer on its remote access IP address given by the fusionhub.

I am using the latest firmware on all mentioned devices. Replacing the “split tunnel” profile by the “route all traffic” profile didn’t change a thing, except for the fact that I could immediately ping the gateway of NewLoc and the gateway and all active hosts in the older pre-existing remote locations.

On the FusionHub SpeedFusion Status page, I see the various remote subnets correctly advertised. On the various remote locations SpeedFusion Status pages, I also see all remote subnets advertised on the tunnel to the FusionHub, including the 10.0.24.0/24 remote subnet of NewLoc. The config of the NewLoc BR1 is almost exactly the same as the one in the pre-existing locations, apart from the new subnet.

What could be wrong? Thanks.

I got one small step closer: in the Remote Access page on the FusionHub, I disabled “Include OSPF Route” and re-enabled it again. Now the routes to all remote subnets are correctly advertised on the OpenVPN client.

However, from the OpenVPN client, I still cannot reach the hosts on the NewLoc behind their BR1, whilst I can reach the hosts on other remote networks just fine. From other remote networks, I can also not reach the hosts on NewLoc. From the FusionHub admin page, I can ping to the hosts on NewLoc…

I recall that:

  • I can ping from the FusionHub to the hosts at NewLoc
  • I can ping from the hosts in NewLoc to hosts in either which remote location and even the clients connected using OpenVPN
  • I cannot ping from the OpenVPN client or hosts in a remote location to hosts at NewLoc

So this looks like a firewall issue on the FusionHub. However, all firewall rules are disabled. What could be wrong?

OK, I got another step further. It looks like traffic to 10.0.24.0 is routed to somewhere else by the Fusionhub.

When I ping to 10.0.24.20 (a host at NewLoc) from the FusionHub, I got nice responses. But when I do a PCAP capture at the LAN port of the NewLoc BR1, I don’t see those PINGs coming from a known IP address in my overlay network. I do however see PING requests coming from 5.192.187.93, which is weird, as this is no known IP address and it shouldn’t be allowed to enter the network as it is behind NAT on its local internet breakout.

When I try another host at NewLoc, e.g. 10.0.24.110, from the FusionHub, there comes no answer. Whilst this host exists at NewLoc and answers to PINGs from within the NewLoc network.

When I disable the tunnel from NewLoc, no PING is possible from FusionHub to NewLoc hosts, especially not to the mentioned IP addresses, which should be normal, as the 10.0.24.0/24 range is not used at another remote location, and there is no route advertised except by the NewLoc Speedfusion tunnel.

I’m getting a bit crazy…

Note however I had to alter the remote IP address (of the VPN server) in the downloaded OpenVPN profile as there the internal GCP IP address was used instead of the public one, which is forwarding the necessary ports to the FusionHub instance.

What is the internal GCP IP address of your FH host?

FusionHub has 10.132.0.2 as WAN address and 10.0.250.100/24 internally, so no overlap.

When I PING the NewLoc BR1 at its IP address 10.0.24.1 from the OpenVPN client PC, the replies stop coming in when I disable the Speedfusion tunnel from NewLoc to FusionHub and they start coming in again when I re-enable the Speedfusion tunnel, so that part looks good.

It seems there was an issue with SFC. Next to the Speedfusion tunnel to the FusionHub, I also had an SFC tunnel to the Paris server. I normally only use this for InControl, but this time I had also routed all traffic from 10.0.24.20 through this tunnel using Outbound policies with interface priorities to maintain its internet connection and use FEC. This might have caused the problem, next to a misconfiguration in the .110 host.

Sometimes when connecting using OpenVPN, I do not get the routes to all connected Speedfusion peer networks. If I add the route manually myself, it all works. Is this an occasional problem for more people?