OPENVPN client - cannot ping router or anything behind it

I just purchased the SURF SOHO router in hopes to replace my Asus. What I am about to describe works perfectly on the Asus but I cannot get it to work on the SOHO. I’m confident someone has had this issue and would appreciate some help.

I purchased the opevvpn client license from Peplink. Right now I am using only my Jetpack via USB to test this out to see if the router is going to work. My vpn runs on a Ubuntu machine on digital Ocean.

The router appears to be refusing connection from the vpn tunnel and I can’t figure out why. Apparently there is more to configure than the basic setup covered here:

Everything works up until step 7, trying to ping the SOHO or something attached to it. I get no response.
If in step 7 I ping my iphone which is connected to the vpn, I do get a response.

I tried adding port forwarding onto the SURF for port TCP 1194 pointing at which is the lan address of the SOHO. That didn’t help either.

I will attempt to include some screenshots. Here is dashboard window. VPN is connected under the USB jetpack:

Here is part 1 detail on the openvpn client page:

Here is part 2 detail on the openvpn client page:

Port forwarding:

Using SOHO vpn connection to ping my iphone connected to LTE, connected to the VPN tunnel (successful):

Pinging the router (not successful):

Thanks for any help

To start, the port forwarding is not necessary so remove that.

Next, You need to show the data behind “details” for the OpenVPN WAN link.

That is the data you need to test step #7.

Step #6 was viewing those details (on a Balance which looks different from a soho/transit)

Their example uses as the openVPN network… not the LAN network… You are using as the LAN, so you need to ignore specific IP addresses. Which is why your ping to won’t work.

So step #7 takes the details from #6 and tries to ping an IP on the remote OpenVPN side of the link. I don’t know where their example pulled from. You are not trying to ping the Soho, you are trying to use the built in ping tool to ping from the Soho’s OpenVPN interface to IP addresses on the remote VPN network.

Once that is sucessful, then you need to tell the Soho what traffic should go via the VPN. If everything then the OVPN should be in priority #1, Otherwise you will need to use the outbound policy so route traffic by type.

Thanks very much Paul for your response. I’m not a network expert (as you can probably tell) and appreciate your help and patience.

i just deleted the port forwarding as you recommended.

Big picture, what I need is for my iphone etc. to be able to access my security cameras and other devices on my home lan. I don’t need everything going through the openvpn. I don’t know how to do that on the new router - it worked without me doing anything special on my current router, but my current router does not support failover to my jetpack which is desirable.

I think my screen shots 2 and 3 above (labeled part 1 & 2 of Openvpn client pages) are the same data as what is in step 6 of the quick start. I didn’t include the ip address of the openvpn server.

On my openvpn server here is what I see when I run status:
Updated,Sun Dec 5 14:43:06 2021
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
Router2,,1311295,1223648,Sat Dec 4 12:24:36 2021
diphone,,5415,7985,Sun Dec 5 14:38:56 2021
Virtual Address,Common Name,Real Address,Last Ref,Router2,,Sat Dec 4 12:24:38 2021,diphone,,Sun Dec 5 14:42:09 2021,Router2,,Sun Dec 5 14:42:59 2021
Max bcast/mcast queue length,5

In addition to the last original screen shot above where I tried to ping I also tried to ping (from the openvpn connection) which is the openvpn address of the router. That ping failed. But I can ping my iphone using the openvpn connection.

I tried to access an ethernet device at hooked to the SURF (using a web browser, from my iphone) and that didn’t work either.

Once that is sucessful, then you need to tell the Soho what traffic should go via the VPN. If everything then the OVPN should be in priority #1, Otherwise you will need to use the outbound policy so route traffic by type.

I’ll need some help on that.

thanks again.

Ok, 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 which isn’t normally correct for a /24 but that might be an openVPN side effect.

Can you ping 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 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.

Thank you Paul.

Without making any changes:
Pinging from the linux box is not successful, nor is pinging from the iphone 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 is NOT successful from the SOHO:

Thank you for the continued help.

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 Netmask. a /24 bridged network behaving as an ethernet shoudl be So you need to know where that mismatch is coming from.

I would also poke around in the CLI and view the ARP tables.

Thanks Paul for the continued help.

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:
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
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
ifconfig-pool-persist ipp.txt
push “dhcp-option DNS”
push “dhcp-option DNS”
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-version-min 1.2
status /var/log/openvpn/status.log 30
verb 3
log openvpn.log
client-config-dir /etc/openvpn/ccd/
push “route”

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 for the continued help.

Your second screen shot show a Netmask of

Do you have a copy of the client OPvpn file? Who is setting that netmask?.

I would also ssh to the CLI prompt and get a dump of the “support arp” table.

Next up would be running some PCAP’s from the support.cgi page (search for that)

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:

proto tcp
remote 1194
dev tun
tun-mtu 1500
resolv-retry infinite
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
cipher AES-128-GCM
tls-version-min 1.2
setenv opt block-outside-dns # Prevent Windows 10 DNS leak
verb 3

Do you see anything here that would cause the problem?


Nothing in there…

you might need to set the pool explicitly with the expected netmask?


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.

Hi Paul,

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.

thanks again

I use the NordVPN application to use the Internet by hiding my IP…

Hello Paul,
Thanks again for your help.

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.

Thanks again.

On your other question, the FusionHub solo is no charge for a single connection. Your SOHO will connect via pepvpn.

Remember to open ports if you have a cloud firewall at digital ocean. Internet->Wan on Fusion HUB

Use UDP4500 if there is one PepVPN.
If UDP4500 cannot connect, use TCP32015.

L2TP for remote access. (open the L2TP WAN ports)

Remember to assign WAN and LAN interfaces to the fusionhub. I found that the LAN was required for the L2TP access to work.

Some other threads:

1 Like

Thanks Paul,

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.

Thanks again

This is a stub “LAN” on the VM provider side. It is a space to assign the L2TP DHCP pool to.

Just like the 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.