Protonvpn (openvpn) timing out client connections

Hi all,

I've been using ProtonVPN on a stock Mango (GL.iNet GL-MT300N-V2) for a while and I decided to wipe the stock software and install OpenWRT to get access to additional features. I installed OpenWrt 22.03.5 r20134-5f15225c1e today.

I then followed the setup guide at

Noting that the dns updater script is no longer needed.

I also hit a problem where the firewall step (dnsmasq) would fail to start unless I removed the procd-ujail package because it was trying to edit files that it didn't have write access in.

However, despite the VPN appearing to come up (no failures in the logs, and I see the Initialized message) I am unable to reach any websites from my LAN clients. I can't even ping IPv4 addresses, e.g. ping 1.1.1.1 works without the VPN connection, but times out when VPN is enabled. That tells me this might not even be DNS related. Ping is failing even from ssh-ing into the router itself, so something is definitely wrong here.

I added the dns updater script, recommended for OpenWRT 19 and below, and corresponding lines in the openvpn conf file, but it made no difference.

Does anybody know how I can debug this further or if there is a step that I am missing (and that protonvpn need to update in their instructions).

the protonvpn docs are more or less a copy/paste of these https://openwrt.org/docs/guide-user/services/vpn/openvpn/client-luci

I can see that a traceroute is failing to openwrt.org when the VPN is enabled, it just times out.

Follow the troubleshooting instructions and share here the output.

1 Like

Something of relevance: ProtonVPN sends all IPv6 to a black hole and recommends disabling it. But I can't figure out how to disable IPV6 in OpenWRT... there are a LOT of threads about it but no definitive answer.

Mostly you'd want the lan clients (which are going to route via VPN) to see only an IPv4 network so they don't try to use IPv6. To that end,

  1. Remove the ipv6assign line from lan.
  2. In the lan section of /etc/config/dhcp, change dhcpv6 and ra to disabled.

Further you could restrict the lan->vpn forwarding in the firewall to family ipv4 that will prevent any IPv6 packets that a LAN device might send to the router from being forwarded.

1 Like

I think I've successfully disabled IPv6 and it doesn't seem to have helped.

I've also gone through everything in the Troubleshooting and nothing looks unusual. It's extremely verbose so I'll spare posting it (it's also unclear if there's anything sensitive in the logs).

Kinda weird, at this point it would be good to know if anybody else is successfully running ProtonVPN and what release they are using as I'd be happy to revert to the last known version that is known to work.

I'm going to try downgrading to 21.02.7 tomorrow, I've followed the instructions exactly and the troubleshooting isn't flagging anything up. 22.x seems pretty recently released so if I get the same problems on 21.x I'll post logs.

I see now that VPN is not working at all for you. Some basic troubleshooting, all of these are from the router CLI:

  • Check the log (logread) to see that OpenVPN reached "Initialization Sequence Completed" OpenVPN logs basically every step of the connection negotiation process, so reading the log is very useful to find where a problem occurred.
  • Check the routing table (run route with no parameters) to see if the "split" default route through the VPN interface has been installed.
  • Try to ping the gateway of this split route, which is the Proton server on the other end of your tunnel. In the example it appears it is likely 10.20.0.1.
  • See if DNS works with a nslookup of some site.
  • Try traceroute to some numeric IP.

I would not downgrade to version 21. OpenVPN is strict about enforcing the newest encryption standards by having a new server version refuse to connect to an old client version which does not support them.

2 Likes

"Initialization Sequence Completed" is there. I even intentionally broke the username/password to see if it would fail (it did).

route with no VPN is

root@OpenWrt:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.254   0.0.0.0         UG    0      0        0 eth0.2
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0.2

and with the VPN on it is

root@OpenWrt:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.24.0.1       128.0.0.0       UG    0      0        0 tun0
default         192.168.1.254   0.0.0.0         UG    0      0        0 eth0.2
10.24.0.0       *               255.255.0.0     U     0      0        0 tun0
128.0.0.0       10.24.0.1       128.0.0.0       UG    0      0        0 tun0
143.244.44.186  192.168.1.254   255.255.255.255 UGH   0      0        0 br-lan
192.168.1.0     *               255.255.255.0   U     0      0        0 br-lan
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0.2

Ping is not working with the IP address here, or the one you've sleuthed

root@OpenWrt:~# ping 10.24.0.1
PING 10.24.0.1 (10.24.0.1): 56 data bytes
^C
--- 10.24.0.1 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
root@OpenWrt:~# ping 10.20.0.1
PING 10.20.0.1 (10.20.0.1): 56 data bytes
^C
--- 10.20.0.1 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

With the VPN on, DNS isn't working and neither is traceroute on a numeric IP (both work if the VPN is off, although I did have problems with my upstream modem sending me the correct DNS resolver so I have a fixed set).

basically exactly the same thing in the older version of openwrt... there must be some step in getting ProtonVPN up and running that they've forgotten to mention.

Same thing with TCP as with UDP.

one thing that looks a little suspicious is the NULL here in the tun0 logs, but no warnings or errors (this is the same for UDP and TCP)

Thu Jun 22 11:57:54 2023 daemon.notice openvpn(USNY138TCP)[7706]: /usr/libexec/openvpn-hotplug up USNY138TCP tun0 1500 1586 10.84.0.5 255.255.0.0 init
Thu Jun 22 11:57:54 2023 daemon.notice openvpn(USNY138TCP)[7706]: net_route_v4_add: 143.244.44.186/32 via 192.168.1.254 dev [NULL] table 0 metric -1
Thu Jun 22 11:57:54 2023 daemon.notice openvpn(USNY138TCP)[7706]: net_route_v4_add: 0.0.0.0/1 via 10.84.0.1 dev [NULL] table 0 metric -1
Thu Jun 22 11:57:54 2023 daemon.notice openvpn(USNY138TCP)[7706]: net_route_v4_add: 128.0.0.0/1 via 10.84.0.1 dev [NULL] table 0 metric -1

whatever version of OpenWRT that the ProtonVPN docs is using is expecting more like

Mon Nov 23 09:58:54 2020 daemon.notice openvpn(FR)[3416]: /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.20.0.1
Mon Nov 23 09:58:54 2020 daemon.notice openvpn(FR)[3416]: /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.20.0.1

This is a serious problem. The wan and lan are on the same subnet. This will prevent proper routing of the encrypted packets to the raw Internet and the ProtonVPN server. You will note that the "hole punch" route was improperly assigned to br-lan because the pre-VPN table is ambiguous-- two routes exist to the same subnet.

The solution is to change the LAN IP to something like 192.168.2.1 so it is outside the 192.168.1.0/24 network that your upstream router uses. Or reconfigure the upstream router for a different subnet, if you have access to it.

2 Likes

oooh, that makes sense! When I get this fixed I should update the wike page to include this as a standard problem. Almost all upstream routers that I have used over the years use 192.168.[01].X addresses so it didn't even occur to me that they'd need to be different. It seems I need to update the LAN IP address and the DHCP space too.

wow, that was it! A simple fix...

Network > Interfaces > LAN > Edit > IPv4 address > 192.168.2.1

and reboot. Just remember to update all my ssh / uiadmin references to use the new IP address.

Thank you so much!

Unfortunately I cannot update the wiki page as it says "Self-Registration is currently disabled or conf/users.auth.php is not writable. Please ask your DokuWiki administrator to create your account manually."

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.