Unable to connect to internet after establishing VPN client with OpenVPN

Hello,

I just flashed a Netgear R6100 router with OpenWrt 22. My goal is to set up a client VPN connection on this router via ProtonVPN.

I followed the steps of this tutorial : [Link to ProtonVPN tutorial for OpenWrt]

However, it doesn't work. OpenVPN seems to establish the VPN connection, but I just can't reach internet with the devices connected to the router.

Here are the logs and some screenshots of my configuration in LuCI :

Sat Jul 15 12:59:58 2023 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan) 192.168.1.127 98:29:a6:48:05:a1
Sat Jul 15 12:59:58 2023 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.1.127 98:29:a6:48:05:a1
Sat Jul 15 12:59:58 2023 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.1.127 98:29:a6:48:05:a1 LAPTOP-BOVVFERS
Sat Jul 15 13:03:39 2023 user.info : luci: accepted login on / for root from 192.168.1.127
Sat Jul 15 13:09:49 2023 user.info kernel: [  695.746622] kmodloader: loading kernel modules from /etc/modules.d/*
Sat Jul 15 13:09:49 2023 kern.info kernel: [  695.764896] tun: Universal TUN/TAP device driver, 1.6
Sat Jul 15 13:09:49 2023 user.info kernel: [  695.782925] kmodloader: done loading kernel modules from /etc/modules.d/*
Sat Jul 15 13:20:49 2023 daemon.warn openvpn(CH)[5254]: DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
Sat Jul 15 13:20:49 2023 daemon.notice openvpn(CH)[5254]: OpenVPN 2.5.7 mips-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Sat Jul 15 13:20:49 2023 daemon.notice openvpn(CH)[5254]: library versions: OpenSSL 1.1.1u  30 May 2023, LZO 2.10
Sat Jul 15 13:20:49 2023 daemon.warn openvpn(CH)[5254]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sat Jul 15 13:20:49 2023 daemon.notice openvpn(CH)[5254]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Sat Jul 15 13:20:49 2023 daemon.notice openvpn(CH)[5254]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Sat Jul 15 13:20:49 2023 daemon.notice openvpn(CH)[5254]: TCP/UDP: Preserving recently used remote address: [AF_INET]185.159.157.7:5060
Sat Jul 15 13:20:49 2023 daemon.notice openvpn(CH)[5254]: Socket Buffers: R=[180224->180224] S=[180224->180224]
Sat Jul 15 13:20:49 2023 daemon.notice openvpn(CH)[5254]: UDP link local: (not bound)
Sat Jul 15 13:20:49 2023 daemon.notice openvpn(CH)[5254]: UDP link remote: [AF_INET]185.159.157.7:5060
Sat Jul 15 13:20:49 2023 daemon.notice openvpn(CH)[5254]: TLS: Initial packet from [AF_INET]185.159.157.7:5060, sid=77261639 06a03a1e
Sat Jul 15 13:20:49 2023 daemon.notice openvpn(CH)[5254]: VERIFY OK: depth=2, C=CH, O=ProtonVPN AG, CN=ProtonVPN Root CA
Sat Jul 15 13:20:49 2023 daemon.notice openvpn(CH)[5254]: VERIFY OK: depth=1, C=CH, O=ProtonVPN AG, CN=ProtonVPN Intermediate CA 1
Sat Jul 15 13:20:49 2023 daemon.notice openvpn(CH)[5254]: VERIFY KU OK
Sat Jul 15 13:20:49 2023 daemon.notice openvpn(CH)[5254]: Validating certificate extended key usage
Sat Jul 15 13:20:49 2023 daemon.notice openvpn(CH)[5254]: ++ Certificate has EKU (str) 1.3.6.1.5.5.8.2.2, expects TLS Web Server Authentication
Sat Jul 15 13:20:49 2023 daemon.notice openvpn(CH)[5254]: ++ Certificate has EKU (oid) 1.3.6.1.5.5.8.2.2, expects TLS Web Server Authentication
Sat Jul 15 13:20:49 2023 daemon.notice openvpn(CH)[5254]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sat Jul 15 13:20:49 2023 daemon.notice openvpn(CH)[5254]: VERIFY EKU OK
Sat Jul 15 13:20:49 2023 daemon.notice openvpn(CH)[5254]: VERIFY OK: depth=0, CN=node-ch-03.protonvpn.net
Sat Jul 15 13:20:49 2023 daemon.warn openvpn(CH)[5254]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1633', remote='link-mtu 1634'
Sat Jul 15 13:20:49 2023 daemon.warn openvpn(CH)[5254]: WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'
Sat Jul 15 13:20:49 2023 daemon.notice openvpn(CH)[5254]: Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 4096 bit RSA, signature: RSA-SHA256
Sat Jul 15 13:20:49 2023 daemon.notice openvpn(CH)[5254]: [node-ch-03.protonvpn.net] Peer Connection Initiated with [AF_INET]185.159.157.7:5060
Sat Jul 15 13:20:50 2023 daemon.notice openvpn(CH)[5254]: SENT CONTROL [node-ch-03.protonvpn.net]: 'PUSH_REQUEST' (status=1)
Sat Jul 15 13:20:50 2023 daemon.notice openvpn(CH)[5254]: PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 10.39.0.1,sndbuf 524288,rcvbuf 524288,redirect-gateway def1,explicit-exit-notify,comp-lzo no,route-gateway 10.39.0.1,topology subnet,ping 10,ping-restart 60,socket-flags TCP_NODELAY,ifconfig 10.39.0.7 255.255.0.0,peer-id 1507333,cipher AES-256-GCM'
Sat Jul 15 13:20:50 2023 daemon.notice openvpn(CH)[5254]: OPTIONS IMPORT: timers and/or timeouts modified
Sat Jul 15 13:20:50 2023 daemon.notice openvpn(CH)[5254]: OPTIONS IMPORT: explicit notify parm(s) modified
Sat Jul 15 13:20:50 2023 daemon.notice openvpn(CH)[5254]: OPTIONS IMPORT: compression parms modified
Sat Jul 15 13:20:50 2023 daemon.notice openvpn(CH)[5254]: OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Sat Jul 15 13:20:50 2023 daemon.notice openvpn(CH)[5254]: Socket Buffers: R=[180224->360448] S=[180224->360448]
Sat Jul 15 13:20:50 2023 daemon.notice openvpn(CH)[5254]: OPTIONS IMPORT: --socket-flags option modified
Sat Jul 15 13:20:50 2023 daemon.warn openvpn(CH)[5254]: NOTE: setsockopt TCP_NODELAY=1 failed
Sat Jul 15 13:20:50 2023 daemon.notice openvpn(CH)[5254]: OPTIONS IMPORT: --ifconfig/up options modified
Sat Jul 15 13:20:50 2023 daemon.notice openvpn(CH)[5254]: OPTIONS IMPORT: route options modified
Sat Jul 15 13:20:50 2023 daemon.notice openvpn(CH)[5254]: OPTIONS IMPORT: route-related options modified
Sat Jul 15 13:20:50 2023 daemon.notice openvpn(CH)[5254]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sat Jul 15 13:20:50 2023 daemon.notice openvpn(CH)[5254]: OPTIONS IMPORT: peer-id set
Sat Jul 15 13:20:50 2023 daemon.notice openvpn(CH)[5254]: OPTIONS IMPORT: adjusting link_mtu to 1656
Sat Jul 15 13:20:50 2023 daemon.notice openvpn(CH)[5254]: OPTIONS IMPORT: data channel crypto options modified
Sat Jul 15 13:20:50 2023 daemon.notice openvpn(CH)[5254]: Data Channel: using negotiated cipher 'AES-256-GCM'
Sat Jul 15 13:20:50 2023 daemon.notice openvpn(CH)[5254]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sat Jul 15 13:20:50 2023 daemon.notice openvpn(CH)[5254]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sat Jul 15 13:20:50 2023 daemon.notice openvpn(CH)[5254]: net_route_v4_best_gw query: dst 0.0.0.0
Sat Jul 15 13:20:50 2023 daemon.notice openvpn(CH)[5254]: net_route_v4_best_gw result: via 192.168.1.1 dev eth1
Sat Jul 15 13:20:50 2023 daemon.notice openvpn(CH)[5254]: TUN/TAP device tun0 opened
Sat Jul 15 13:20:50 2023 daemon.notice openvpn(CH)[5254]: net_iface_mtu_set: mtu 1500 for tun0
Sat Jul 15 13:20:50 2023 daemon.notice openvpn(CH)[5254]: net_iface_up: set tun0 up
Sat Jul 15 13:20:50 2023 daemon.notice openvpn(CH)[5254]: net_addr_v4_add: 10.39.0.7/16 dev tun0
Sat Jul 15 13:20:50 2023 daemon.notice openvpn(CH)[5254]: /usr/libexec/openvpn-hotplug up CH tun0 1500 1584 10.39.0.7 255.255.0.0 init
Sat Jul 15 13:20:51 2023 daemon.notice openvpn(CH)[5254]: net_route_v4_add: 185.159.157.7/32 via 192.168.1.1 dev [NULL] table 0 metric -1
Sat Jul 15 13:20:51 2023 daemon.notice openvpn(CH)[5254]: net_route_v4_add: 0.0.0.0/1 via 10.39.0.1 dev [NULL] table 0 metric -1
Sat Jul 15 13:20:51 2023 daemon.notice openvpn(CH)[5254]: net_route_v4_add: 128.0.0.0/1 via 10.39.0.1 dev [NULL] table 0 metric -1
Sat Jul 15 13:20:51 2023 daemon.warn openvpn(CH)[5254]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sat Jul 15 13:20:51 2023 daemon.notice openvpn(CH)[5254]: Initialization Sequence Completed

I googled my problem and browsed a lot of topics on this forum concerning the issue but I can't seem to find the issue.

I am super grateful for any help you guys could give to me :slight_smile:

By "can't reach internet", what do you mean?

No DNS resolution? No routing? Something else?

What troubleshooting and testing have you already carried out, on both the router and devices behind the router, and what are the results of that troubleshooting and testing?

As I am just a beginner, it is difficult for me to characterize precisely the issue.
Basically, when I turn on the VPN connection on OpenVPN, i can't access any webpage in my browser.

I don't know how to check if the problem comes from DNS resolution, routing, etc but if let me know how, I can check.

As a paying customer of ProtonVPN, you are entitled to support from that company. Have you made use of that entitlement yet? Support is available from https://protonvpn.com/support/ - scroll down to see the "Contact support" link, which contains further links to let you create a support ticket, engage in something called a "Live chat", or send an e-mail.

In the meantime, as this is an OpenWRT forum, someone here might also be able to help you get to the bottom of your problem.

While that doesn't immediately indicate the cause of the problem, it does indicate what you're doing when you experience the problem. And that's a starting point.

Traditionally, the first thing to check is your configuration.

What are the contents of /etc/config/network and /etc/config/firewall? Also, if you use a separate .ovpn file for OpenVPN, what are the contents of that file?

If any of the information contains passwords, certificates or keys, then redact those details.

In the firewall, forwarding from lan zone to vpn zone must be enabled. Masquerading (v4) must be enabled on the vpn zone but not the lan zone.

Your DNS server must be reachable through the VPN. This means configure a public DNS or one provided by the VPN service. The usual default to use DNS provided by the ISP will only work from inside the ISP network, i.e. a non-VPN connection.

On the router network diagnostics page, first try to ping the server end of the VPN tunnel, 10. 39.0.1. Then try traceroutes to Internet sites by number (8.8.8.8) and by name (dns.google).

I contacted them already but got no answer from them at the moment.

Here is the content of /etc/config/network :

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd66:d8a4:28d1::/48'

config interface 'wan'
        option device 'eth1'
        option proto 'dhcp'

config interface 'wan6'
        option device 'eth1'
        option proto 'dhcpv6'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0.1'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '1 2 3 4 0t'

and /etc/config/firewall :

config defaults
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option synflood_protect '1'

config zone
        option name 'lan'
        list network 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'

config zone
        option name 'wan'
        list network 'wan'
        list network 'wan6'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'
        list device 'tun0'

config forwarding
        option src 'lan'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

Here is the .ovpn :

# ==============================================================================
# Copyright (c) 2016-2020 Proton Technologies AG (Switzerland)
# Email: contact@protonvpn.com
#
# The MIT License (MIT)
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
# in the Software without restriction, including without limitation the rights
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in all
# copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR # OTHERWISE, ARISING
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
# IN THE SOFTWARE.
# ==============================================================================

# The server you are connecting to is using a circuit in order to separate entry IP from exit IP
# The same entry IP allows to connect to multiple exit IPs in the same data center.

# If you want to explicitly select the exit IP corresponding to server CH#8 you need to
# append a special suffix to your OpenVPN username.
# Please use "XXXXXX+b:1" in order to enforce exiting through CH#8.

# If you are a paying user you can also enable the ProtonVPN ad blocker (NetShield) or Moderate NAT:
# Use: "XXXXX+b:1+f1" to enable anti-malware filtering
# Use: "XXXXX+b:1+f2" to additionally enable ad-blocking filtering
# Use: "XXXXX+b:1+nr" to enable Moderate NAT
# Note that you can combine the "+nr" suffix with other suffixes.

client
dev tun
proto udp

remote 185.159.157.7 5060
remote 185.159.157.7 80
remote 185.159.157.7 51820
remote 185.159.157.7 4569
remote 185.159.157.7 1194

remote-random
resolv-retry infinite
nobind

# The following setting is only needed for old OpenVPN clients compatibility. New clients
# automatically negotiate the optimal cipher.
cipher AES-256-CBC

auth SHA512
verb 3

setenv CLIENT_CERT 0
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun

reneg-sec 0

remote-cert-tls server
auth-user-pass /etc/openvpn/CH.auth
pull
fast-io


<ca>
-----BEGIN CERTIFICATE-----
XXXXXX
-----END CERTIFICATE-----
</ca>

key-direction 1
<tls-auth>
# 2048 bit OpenVPN static key
-----BEGIN OpenVPN Static key V1-----
XXXXXXXX
-----END OpenVPN Static key V1-----
</tls-auth>

Masquerading seem to be activated such as you describe :

Concerning the DNS, since it was not indicated in the tutorial, and I do not know how to change those settings, i let everything to default. I was expecting the OpenVPN to set up Proton's DNS itself.

The ping to 10.39.0.1 gave this result :

PING 10.39.0.1 (10.39.0.1): 56 data bytes

--- 10.39.0.1 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

Both traceroutes gave this :

Error: XHR request timed out

What is the output of ip route when connected to the VPN?

The output of ip route :

0.0.0.0/1 via 10.29.0.1 dev tun0
default via 192.168.1.1 dev eth1  src 192.168.1.38
10.29.0.0/16 dev tun0 scope link  src 10.29.0.4
128.0.0.0/1 via 10.29.0.1 dev tun0
185.159.157.7 via 192.168.1.1 dev br-lan
192.168.1.0/24 dev br-lan scope link  src 192.168.1.1
192.168.1.0/24 dev eth1 scope link  src 192.168.1.38

It appears as if you may have the WAN interface of OpenWRT plugged into another router which also uses the 192.168.1.0/24 address range.

This will cause conflicts. Routing 101: each subnet must be different.

If what I have described is indeed the case, then you should consider changing your IP addressing. Either set OpenWRT's LAN interface to an address in a subnet which isn't 192.168.1.0/24, or set the upstream router's LAN interface similarly. Doesn't matter which approach you take, as long as you resolve the apparent conflict.

1 Like

Okay I see. I went to network > interface > lan and clicked on the edit button.
I changed the ipv4 IP address and then lost contact with the web interface of the router.

I feel like this was not the way to do it. Could you guide explain to me how I am supposed to change the IP for openWrt lan ?

So change your computer's IP address to sit in the same subnet as the router's LAN interface's new IP address.

For example, if you changed your router's IP address from 192.168.1.1 to 192.168.2.1 (to pick one possibility), then change your computer's IP address to sit in the 192.168.2.0/24 subnet. If you picked a different subnet for the router, then adjust those addresses accordingly.

No, that was the right way to do it. But your computer also needs to move to the new subnet as well. If your computer is set up to be a DHCP client, then it might be as simple as unplugging and reconnecting the Ethernet cable from the computer, or issuing ipconfig /release followed by ipconfig renew in a command prompt (I'm assuming you're using Windows), or using Windows' built-in network diagnostic tools to perform the same actions behind the scenes.

In case this feels a little bit like yak-shaving, don't worry - we are aware that your original problem was no traffic via the VPN. Sorting out your IP addressing is one step along the way to getting the VPN working.

Sorry, where is zone for tun, and forwarding lan->tun?

Have you seen zone for tun in /etc/config/firewall?

tun0 is attached to the wan zone.

Very strange idea. Create specific interface tun, create specific zone, and create specific forwarding. See example like: https://airvpn.org/forums/topic/20303-airvpn-configuration-on-openwrt-preventing-traffic-leakage-outside-tunnel/

I have not seen such example, to sum up, tun was configured as interface, not device.

Yeah, I'm unconvinced that ProtonVPN's instructions are the best. But, as I haven't tried the configuration myself, I'm going to reserve judgement. Besides, ProtonVPN has to support it, so one hopes someone there actually vetted the instructions...

For now, though, if we can get the OP to sort out the local IP address conflicts, we can see what else might need correcting to get the VPN to work.

Okay so you were definitely right about the router’s IP address being the issue.
I had some troubles to connect again to the web administration interface after changing the IP, but finally I could do it.

After that, the VPN is working without any problem.

Thanks a lot for your guidance :slight_smile:

1 Like

For future reference, this is because of how routing works. All routing does is answer the question "where do I send this?"

If you have more than one subnet with the same addressing, it means the router cannot reliably answer the "where do I send this?" question, which leads to the sort of experience you had.

Glad it's working now.

1 Like