Ok, 10.8.0.0/24 is the openvpn segment. What is the IP address of the linux box on that segment? can you ping that?. In the 10.8.0.? space? It also says that the netmask is 255.255.255.255 which isn’t normally correct for a /24 but that might be an openVPN side effect.
Can you ping 10.8.0.8 from the linux or other VPN clients?..
Now, I see that you are using NAT on the OpenVPN interface. NAT means that by default, flows only leave the Soho, and the 10.8.0.8 IP is the only one shown to the VPN segment. You could port forward from the OpenVPN wan interface, but why bother since you want full access to your lan.
You can change the Routing Mode parameter to IP forwarding by clicking on the blue ? to the left and selecting IP forwarding. that will remove the NAT and allow access to the full /24.
Without making any changes:
Pinging 10.8.0.8 from the linux box is not successful, nor is pinging from the iphone 10.8.0.3. Pinging the iphone from the linux box and the SOHO is successful.
You can change the Routing Mode parameter to IP forwarding:
I made this change and now the ping to 10.8.0.3 is NOT successful from the SOHO:
We see that the packets are getting to the OpenVPN system, it just isn’t handling them in the way we expect.
I don’t have personal openvpn resources, but if you are using a bridged network you need to have “client-to-client” enabled. That ICMP redirect is indicative of the packets hitting the TUN interface and the kernel Not handling them as desired.
If that is enabled, then I would re-investigate the 255.255.255.255 Netmask. a /24 bridged network behaving as an ethernet shoudl be 255.255.255.0. So you need to know where that mismatch is coming from.
I would also poke around in the CLI and view the ARP tables.
Out of everything I posted, I’m unclear what exactly makes it look like there is a mismatch happening. Can you elaborate on that?
Could this be caused for some reason due to me using the USB connection with my jetpack?
I have client-to-client enabled.
The SOHO router CCD file on the linux box has:
iroute 192.168.50.0 255.255.255.0
Is there something different I should use here?
Here is my server.conf file from the linux box, minus some of the private info:
port 1194
proto tcp
dev tun
user nobody
group nogroup
persist-key
persist-tun
keepalive 10 120
topology subnet
reneg-sec 0 #turns off hourly key renegotiation
reneg-bytes 1073741824 #renegotiates key after 1 GB of data transfer
tcp-queue-limit 1024
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push “dhcp-option DNS 8.8.8.8”
push “dhcp-option DNS 8.8.4.4”
dh none
ecdh-curve prime256v1
tls-crypt tls-crypt.key 0
crl-verify crl.pem
ca ca.crt
cert server_lJ2FaiwnIxJUsEdP.crt
key server_lJ2FaiwnIxJUsEdP.key
auth SHA256
cipher AES-128-GCM
ncp-ciphers AES-128-GCM
tls-server
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
status /var/log/openvpn/status.log 30
verb 3
log openvpn.log
client-config-dir /etc/openvpn/ccd/
push “route 192.168.50.0 255.255.255.0”
client-to-client
ccd-exclusive
Also, I tried turning off the SOHO openvpn connection and using the built-in ipsec and openvpn servers on the SOHO, none of them will connect either from my iphone. Very strange.
This all worked on the Asus router but the Asus might be doing something “behind the scenes” that the SOHO isn’t???
Thanks Paul. I haven’t heard of the support arp table or PCAP so I’ll have to research that.
Here is client ovpn file loaded to the SOHO, minus the certificate information:
client
proto tcp
remote xxx.xxx.x.x 1194
dev tun
tun-mtu 1500
resolv-retry infinite
nobind
persist-key
persist-tun
reneg-sec 0 #turns off hourly key renegotiation
reneg-bytes 1073741824 #renegotiates key after 1 GB of data transfer
remote-cert-tls server
verify-x509-name server_lJ2FaiwnIxJUsEdP name
auth SHA256
auth-nocache
cipher AES-128-GCM
tls-client
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
setenv opt block-outside-dns # Prevent Windows 10 DNS leak
verb 3
Do you see anything here that would cause the problem?
you might need to set the pool explicitly with the expected netmask?
ifconfig-pool 10.8.0.2 10.8.0.100 255.255.255.0
CLI settings are under System, Admin Security, CLI SSH and console. there are some debugging commands that are only available if you SSH into that port.
The built in servers on the SOHO only work if you can reach the WAN IP... and behind CGNAT that is not possible. You can search elsewhere where many run a FusionHUB out at our VM provider, expose L2TP (supported natively by iphone, android, mac and Windows) and use SpeedFusion to connect to all WAN links simultaneously.
Tried putting this in the router client.ovpn file, no improvement there.
Is there a “how to” to make this work? I’m starting to read about it but haven’t figured out how it would work. I see there is an extra cost for this and would want to insure it was going to work.
Especially since I already spent $20 on the opvn client add-on which does not appear to work.
I did some additional research on this netmask. This is the standard netmask for openvpn to issue when client-to-client is being used.
So I seem to be back to the problem of the SOHO not handling the traffic correctly, when the Asus router it is replacing works flawlessly.
I submitted a support ticket but no response yet. Anyone know how long it takes to get a response? At this point I have what amounts to a paperweight sitting in my office which is extremely disappointing.
Thanks again Paul, if you think of anything else please add it to the discussion.
At this time I would open a ticket with peplink directly. You will need to do arp and packet captures, peplink is the only group that can get root and do a full investigation of kernel level issues. Responses can take time, it depends on the load.
I suspect that client-to-client is not the most used mode for peplink openvpn users. Most of them use the remote to the internet features.
With a system interaction like this one cannot affirmatively say that the Soho isn’t handling the traffic correctly. You must follow the evidence and investigate where it leads. The evidence indicates that the packets are getting to the linux openvpn server, but that it isn’t handling them in the expected way.
I would have looked in the openvpn server logs at the difference between the packets from the Asus and from the peplink. then, are the differences logical?.. run some tcpdumps on the br0 and tap0 interfaces.
I would also look at the tcpdumps of the system in NAT mode, when some communication seemed available.
I’ve heard of NorVPN. I set up my own openvpn server on Digital Ocean.
Do you have direct experience with NordVPN working on Peplink routers with the client add-on? If you got it to work I guess I could consider trying NordVPN to see if that solves my problems.
NordVPN is just a provider of openvpn services to go out to the internet, not to provide peer to peer private VPN’s. Their target market is people who want to hide/secure their browsing from local snooping (public wifi) or to change their country for streaming/content access reasons.
This is what I suspect most peplink users enable the openvpn client for, and there may have been minimal testing of client-to-client setups.
Thanks Paul,
You have been extremely helpful, and I really appreciate that.
Ah, I was wondering that. I won’t spend any time researching NordVPN.
I did open a ticket with support. I included a link to this forum thread asking them to read it. Based on the first response, it seems clear they didn’t read it because they asked for screen shots, etc. I politely asked them to look at this thread and sent them an additional screen shot.
Unfortunately I didn’t save any logs from when it was hooked to the Asus. If support can’t help id the problem I will try and do that.
Wow, sounds intriguing. If this would replace the openvpn client-to-client I would definitely consider it. I’ll try and do the Digital Ocean setup and see how that goes.
Haven’t heard back from support a second time yet to see if they looked at this thread.
Remember to assign WAN and LAN interfaces to the fusionhub. I found that the LAN was required for the L2TP access to work.
If the LAN is required, do you know if my cellular failover will work with this L2TP arrangement as well? My main goal for switching routers was to have the cellular failover capability. That is what started this whole journey.
This is a stub “LAN” on the VM provider side. It is a space to assign the L2TP DHCP pool to.
Just like the 10.8.0.0/24 space openvpn uses.
Yes, you will have cellular failover with the default PepVPN, but it would be an unlock key for Speedfusion, bonding. Which are technologies that use both WAN links at the same time.
Thanks Paul. I really appreciate the time you are investing here to help me.
I’ve been reading up on the items you posted. I’m pretty confident I could set up the new server on Digital Ocean.
I’m trying to tease out all of the details from the “marketing terms” Peplink uses. It’s dizzying trying to get the terminology straight in my head.
Is this extra paid key necessary if I don’t need “hot” failover? I don’t care if it takes a minute or two to fail over as long as when wired LAN is down that it fails over to 4G, and I can access my network remotely over the 4G connection. And of course access my network when on regular LAN (default state).
I don’t have VOIP or anything mission critical.
I read in one of the web pages that “some” Peplink devices don’t have full support - I can’t find anything that confirms the SOLO will work for this.
I haven’t heard anything back from support on my Openvpn problem. Perhaps they are doing some testing on my use case? I would really like that to work since it’s already set up.
And I’m already paying for one server to run Openvpn and am not looking to buy multiple licenses if I don’t need to.
I don’t actually have a SOHO in house, We will probably pick one up for the Summer condo this spring, This past year I used a MaxTransit when visiting. My Peplink devices are all Primecare so the full Speed fusion is part of the package.
PepVPN alone should have failover, so the PEPVPN will be only connected via WAN#1… and if that connection fails it will reconnect via WAN#2. With a slight outage during the failover.
It is the extra key for speedfusion bonding and hot failover that will connect both WAN’s at the same time, and continuously send health checks so that there is seamless connectivity.
I wanted to post an update on the problem I was having with client-to-client openvpn. After working with support for about 2 1/2 weeks they have concluded that openvpn client-to-client is not supported even when using the $20 client license. Its unclear to me if Pepwave intends to get this working with some firmware changes, but in the meantime I’ve returned the router to my supplier as I must have access to my LAN over my openvpn server.
Hopefully they will support it in the future. I furnished them with my openvpn configuration and screen shots of how I set it up with my Asus router.
