I made some progress. On my MacBook Pro I needed to tell the OS which network interface to use for the 192.168.50.1 request. There were two ways of doing this. The first was to change the order of interfaces. The image below shows that the VPN interface takes precedence over the WiFi interface.
Once I did either of the above steps, I was able to ping 192.168.50.1 and I could point my browser to https://192.168.50.1 and get the login screen for the BR1. Of course, I don’t know the password anymore since IC2 generates it randomly.
Well done! To see the password for the BR1 you click Show All link in the device view on IC2 then click the row of asterisks ***** to see what the password is:
There were two options you suggested for remotely accessing devices behind the BR1. The first was via VPN. The second was via “Port forwarding from the WAN IP to a LAN IP”. I have the first method working (thanks to your help). I’d like learn how to implement the second option. Can I do the configuration on the FusionHub web interface on the Network → WAN page (see first screenshot below) or the Newtork → Firewall page (see second screenshot below).
Hello @djm.tech,
Welcome to the Peplink Forum.
Have you worked through this guide?
Make sure you have set the Security settings with Microsoft CHAP Version 2 (MS-CHAP v2) set correctly.
You find the full details within the guide.
Happy to Help,
Marcus
Martin, I have created this setup thanks to the video you posted on Vimeo. PepVPN is working between my Fusionhub on Vultr and my BR1.
I am trying to take the next step which is to create an OpenVPN connection to the Fusionhub. This is not working. Is there anything unusual about Vultr with respect to firewalling inbound? I have not created any inbound rules on Vultr. It seems to allow all inbound connections.
Hi Dave.
I expect you don’t have a LAN connection on the Fusionhub (you’ll need that so that DHCP can assign your OpenVPN client with an IP)? In Vultr add a private network to the VM and reboot the fusionhub.
If you do have a LAN / or if that doesn’t work let me know what error you’re seeing.
Thanks for the reply. I do have a LAN setup on the VM, 10.2.96.0/20. I assigned 10.2.96.1 to the LAN interface. I also have the DHCP server enabled (check box) but did not adjust the IP range on that screen.
OpenVPN is just not answering on port 1194. I am looking at the client side logs (Tunnelblick on Macbook) and it just times out.
I have openvpn working against a FusionHub on vultr with no additional settings other than LAN setup. This is currently running 8.0.1 build 1644. I’ll upgrade a test against 8.0.2
Not sure you have opened a ticket for this. If you want to verify whether the OpenVPN traffics reaching to the FusionHub, you can actually perform packet capture at the FusionHub Web Admin support.cgi page and open the captured files using WiredShark application to verify any traffics for port 1194 reaching to the Fusionhub WAN. If you did not to see any traffics for the captured logs, that mean the traffics is being blocked at the network level.
Here are the results. I started a capture on FusionHub and then did a port scan from a public website. I am not confident interpreting these results but it appears that the inbound attempt is visible in these results.
Lacking a way to verify OpenVPN is actually running, I’m not sure what to do next. I’m not supremely confident I have FusionHub setup “perfectly” and I suspect I have something set wrong that prevents OpenVPN from running.
I will repeat this capture test from my Macbook running Tunnelblick.
Do you followup the FusionHub captured results in support ticket ? Please include the packet capture file in the support ticket and support team will sure help you to verify on that.
The scan results screenshot that you share can’t conclude the issue because it’s only showing the packet/traffic received at the client device. There are a lot of router hops for the traffics to passing through when travel to internet so it can’t use to conclude the issue. The best ways is to check the traffics received at the FusionHub end and that will tell all the story.
Default when you enable the feature the service will be running. @MartinLangmaid have help a lot to verify whether this is related to firmware issue but look like not. Please followup using the support ticket.
