Issue:
Connecting to a client device works for one pepwave but not the other when using the Ping feature with fusionhub.
For more clarity:
- Fusionhub → pepwave A > 192.168.1.126 works
- Fusionhub → pepwave B > 192.168.1.126 does NOT work
The setup is simple:
- Fusionhub with Speedfusion vpn configured with IC2
- Pepwave A with 2 clients:
- 192.168.1.126 - reachable
- 192.168.1.100 - unreachable
- Pepwave B with 3 clients:
- 192.168.1.126 - unreachable
- 192.168.1.12 - reachable
- 192.168.1.11 - reachable
All testing was done via FusionHub and its ping feature thus removing any extra complexity.
Furthermore, all clients are reachable using Device Tools within IC2 and verified to exist and be active. How can ping work for one client behind pepwave A but not the other (pepwave B)?
Just to check.
Are you saying you have a single FusionHub with two remote Pepwave devices connected at the same time via VPN, and both Pepwave devices have the same LAN subnet (192.168.1.0/24)? And you want to know how to remotely access all the LAN devices individually from the Fusionhub?
If so Virtual Network mapping is the right way to do this since you can’t have two remote subnets that are in the same range connected at the same time. If you look at Status > SPeedFusion on the Fusionhub you’ll see it is in a flip flopping state of conflict.
Virtual Network Mapping lets you keep the LAN subnets the same on both Pepwaves (192.168.1.0/24), but replace each with a unique virtual subnet for remote access over the VPN that can map the real 192.168.1.1-254 IPs to a virtual network (eg 10.10.1.0/24) individually. So remote access to 192.168.1.126 on Pepwave A could become 10.10.1.126 and on Pepwave B it could be 10.10.2.126.
This is how you might have the Pepwave A configured to achieve this:
1 Like
Thanks for the reply and the questions. Reading over my post I see how vague I was.
Are you saying you have a single FusionHub with two remote Pepwave devices connected at the same time via VPN, and both Pepwave devices have the same LAN subnet (192.168.1.0/24)? And you want to know how to remotely access all the LAN devices individually from the Fusionhub?
No. They do have conflicting subnets but we only use one device at time for a short term workaround. So I can use IC2 to set the client device for the speedfusion to pepwave A and i can ping 192.168.1.126. I can then go back to IC2 and remove pepwave A and add pepwave b to the configuration and 192.168.1.126 suddenly becomes unavailable (even though both address are still reachable via remote webadmin in ic2. I recognize that connection doesnt rely on the speedfusion vpn, but it does prove the address is reachable and replies/acknowledges connections).
I initially noticed this issue because 192.168.1.100 on pepwave a was unreachable. so i looked for a device with similar ips/connected devices to compare and found pepwave b with a similar ip (.126) and similar connected devices and fortunately noticed .126 was a cleaner example.
All that to say thats what lead me to think it might be an issue updating the client routes when a pepwave connects to a speedfusion vpn.
If so Virtual Network mapping is the right way to do this since you can’t have two remote subnets that are in the same range connected at the same time
Interesting. I’ve been looking into VRF (Virtual routing and forwarding) to solve the conflicting subnet issue so I’ll take a look into that as well. Seems like that might be the more appropriate solution for what we need.
OK. So one FusionHub and then either one or the other remote peers are connected but not at the same time.
If you can ping the remote peer LAN IP (ie 192.168.1.1 or whatever the remote Pepwave LAN is set to) then Speedfusion VPN is working and OSPF which provides dynamic routing is working.
If you can then ping the LAN device IP (ie 192.168.1.126) from the webui of the remote peer then the LAN device is online.
If you can’t ping the 192.168.1.126 from the FusionHub you most likley have an issue with the default gateway settings on the 192.168.1.126 device. Check to make sure it is using the Pepwave as the default gateway.
If it is, check the status > SpeedFusion page on the FusionHub and look for any conflicts, or appearing / disappearing subnets)
Thanks for the detailed reply. Full disclosure, a different team works with the client device setup while I setup the infrastructure side of things. I’ve taken a look at both IC2 and the remote webadmin for the pepwave the client device is connected to but haven’t seen where I can configure the default gateway. Where can I configure that? Ive asked the other team and they are unsure as well.
So the default gateway question is in case their are LAN clients that are both DHCP (which will be assigned IP, DNS and Gateway IPs) or statically assigned devices (like printers, cameras and access control) where either no one bothers to put in a gateway IP in their configuration because they are expecting all access to be to and from the local network, or where a different gateway is set.
On a windows machine you’d see the gateway that is currently set by running the ipconfig command in a command window.
I see what you mean. The device in question is statically set so we would have had to get physical access since this speedfusionvpn issue is still occurring. We were able to use the intouch feature in ic2 to get access to the device and get things operational.
That being said, I do still think there is an issue with the speedfusion vpn. As far as I’m aware, the device was working for some time, and still was working correctly, we just weren’t able to route to it any longer with no configuration changes.
I was able to monitor the network traffic on the pepwave so I know it was receiving the traffic. Coincidentally, failed pings caused traffic spikes up to 20x when compared with successful ping which suggest retries in my opinion. Weirdly, the peplink’s routing to the client device was fine(verified with traceroute) so theres definitely something weird going on.
Thank you again for the support.
Just to add more info for anyone seeing this. I also tried:
- Manually bridging local (to the pepwave - 192.168.1.0/24) network to the speedfusion vpn
- Advertise a static route
- Removed any dhcp reservations on the pepwave (shouldnt be an issue, but just in case)
- Comparing the setup with an identical unit that had no issues. No differences were found.
