OK that’s good. Can you ping the LAN IP of the BR1 itself or access the BR1 using its LAN IP?
1 Like
You are going to need routes to the subnet on the BR1.
Either you must enable the (Send All traffic over VPN connection) checkbox
or add static routes.
This can be done by hand, or you can put the commands into a file (modify for your subnets)
% more /etc/ppp/ip-up
#!/bin/sh
/sbin/route add -net 192.168.0.0/24 -interface $1
/sbin/route add -net 192.168.100.0/24 -interface $1
/sbin/route add -net 192.168.123.0/24 -interface $1
I can not successfully ping (from the Macbook) the BR1 IP which I think is 192.168.50.1 or a device on the BR1 LAN such as 192.168.50.16. However, I can ping these addresses from the FusionHub console Ping command.
Enabling all traffic over VPN from the Macbook VPN options does not seem to make a difference.
As to adding static routes, I’m afraid I need some more guidance than PM provided.
It seems like there is a missing route, connection, etc between the VPN from the Macbook to the FusionHub public IP and the path through the PepVPN to the BR1.
As long as I had a LAN configured and attached via a private network in VULTR it all just worked.
Can you ping the LAN IP of the FH from your laptop?.
You should see routing data like this:
% netstat -rn |grep 10
10 ppp0 USc ppp0
10.1.96.3 10.1.96.10 UH ppp0
For further debugging I would run a tcpdump on ppp0 to view that the ICMP traffic is leaving via the VPN:
% tcpdump -i ppp0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type PPP (PPP), capture size 262144 bytes
11:40:14.729477 IP 10.1.96.10 > 10.1.96.3: ICMP echo request, id 51399, seq 0, length 64
11:40:14.780076 IP 10.1.96.3 > 10.1.96.10: ICMP echo reply, id 51399, seq 0, length 64
11:40:15.731427 IP 10.1.96.10 > 10.1.96.3: ICMP echo request, id 51399, seq 1, length 64
11:40:15.784514 IP 10.1.96.3 > 10.1.96.10: ICMP echo reply, id 51399, seq 1, length 64
11:40:34.736940 IP 10.1.96.10 > 192.168.123.254: ICMP echo request, id 52935, seq 0, length 64
11:40:34.817788 IP 192.168.123.254 > 10.1.96.10: ICMP echo reply, id 52935, seq 0, length 64
Next we see if the packets are getting to the BR1 network… try pinging the Pi on the BR1 network and watch for the inbound packets at the Pi via tcpdump… if the packets are reaching the BR1, then they are getting lost on the way back. If they don’t reach the BR1 then they are getting lost on the way (or blocked).
All of this is just building blocks… see that packets get to each step, aren’t blocked and then find their way back to the laptop. Step by step. Your VPN IP will be NAT’ed to the IP of the FH LAN
Just to check that the LAN route for the FH shows up under Status → Speedfusion on the BR1.
There should be no NAT on the peplink tunnels. It should be all routed once you are connected to your networks.
Thanks for the continued help - I deleted all profiles and settings and rebuilt the tunnel using the automation in inControl2. Now it all works! I can ping and also connect (with a browser) to devices on the BR1 LAN which was my goal! I have a few use cases to try tonight, but looking good for the moment! I also had to “route all traffic over VPN” on the MAC VPN settings.
2 Likes
I’m glad you were able to get it working. There is probably a button that we just pushed, or didn’t push that was obvious to us, but I set up my system over a year ago.
If you don’t wan to use the “route all traffic” option then you can put
!/bin/sh
/sbin/route add -net 192.168.50.0/24 -interface $1
Into the file /etc/ppp/ip-up (chmod 755) and pppd will automatically execute those commands after the VPN is established.
Unfortunately there is no RFC standard for the L2TP server to signal the networks that are available. Windows uses one method of their own (DHCP options) and MAC OSX server used a different one, a custom pppd in band signal.
I’ve been experimenting with the configuration and have found an issue I can’t resolve.
Note, at this point, I can VPN (LT2P-IPSEC) from either my MacBook or iPhone to the FusionHub which has a PepVPN tunnel setup to a remote BR-1. On the BR-! (Wifi) LAN is a video encoder. From both the iPhone and Macbook (when connected via VPN), I can ping and even access the built in web server of the encoder. However, the encoder also has an iOS app which can not seem to find the encoder. Normally, the app automatically finds any encoder on the same LAN as the iPhone running the app. However, this is not working in this case. The app is not finding anything. Any suggestions as to settings which might fix this?
The closest I can get is to manually inform the app of the encoders IP address, but then when I try to connect it says “Login Error - Please make sure your device network setting TLS/SSL encryption is disabled.” It is disabled on the encoder.
It’s probably using some kind of L2 discovery mechanism to do that, so when you are connected via the VPN you are behind a layer 3 boundary and the discovery will not work.
At least you can manually specify the IP… quite why any vendor is advocating turning off TLS/SSL for administrative access to anything is beyond me, why would you want to encourage your customers to use less security?!?
What is the encoder out of interest?
1 Like
The encoder is a Teradek Vidiu-X