Posted: Thu May 25, 2023 2:20 Post subject: nighthawk x10 OpenVPN Client help
Hello all,
Very long time DD-WRT user, first time posting on the forum.
I have a nighthawk x10 with Firmware: DD-WRT v3.0-r50057 std (09/03/22)
I have a pretty basic setup on my router I am not sure what details would be pertinent to help resolve my issue. For the first time the other day i decided to setup OpenVPN on the router itself rather than all my individual devices. I use Mullvad for my provider and their instructions are pretty straight forward. I applied the settings and everything was working great. Then two days later in the middle of streaming some video i lost internet. I did not change any settings it just stopped. I reset my router a few times that made no difference. If I disable the VPN client i have internet again. I restored the router back to the settings i had before I did the OpenVPN changes (took a backup before making any changes) and tried the same process again and I cannot get it to work. I dont understand why it would work for a few days and then completely stop with no changes. Ive also downloaded the OpenVPN instructions from this site and compared them will Mullvad and they seem pretty close? I've attached some output from the OpenVPN status log below:
State
Client: CONNECTED SUCCESS
Local Address: 10.8.0.1
Remote Address: 10.8.0.1
Log
Clientlog:
20230524 19:03:21 W WARNING: Using --management on a TCP port WITHOUT passwords is STRONGLY discouraged and considered insecure
20230524 19:03:21 W WARNING: file '/tmp/openvpncl/credentials' is group or others accessible
20230524 19:03:21 I OpenVPN 2.5.7 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Sep 3 2022
20230524 19:03:21 I library versions: OpenSSL 1.1.1q 5 Jul 2022 LZO 2.10
20230524 19:03:21 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:16
20230524 19:03:21 W NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
20230524 19:03:21 W WARNING: normally if you use --mssfix and/or --fragment you should also set --tun-mtu 1500 (currently it is 1400)
20230524 19:03:21 I TCP/UDP: Preserving recently used remote address: [AF_INET]198.54.###.##:1194
20230524 19:03:21 Socket Buffers: R=[262144->262144] S=[262144->262144]
20230524 19:03:21 I UDPv4 link local: (not bound)
20230524 19:03:21 I UDPv4 link remote: [AF_INET]198.54.###.##:1194
20230524 19:03:21 TLS: Initial packet from [AF_INET]198.54.###.##:1194 sid=50f59425 53ec236f
20230524 19:03:21 VERIFY OK: depth=2 C=SE ST=Gotaland L=Gothenburg O=Amagicom AB OU=Mullvad CN=Mullvad Root CA v2 emailAddress=security@mullvad.net
20230524 19:03:21 VERIFY OK: depth=1 C=SE ST=Gotaland O=Amagicom AB OU=Mullvad CN=Mullvad Intermediate CA v5 emailAddress=security@mullvad.net
20230524 19:03:21 NOTE: --mute triggered...
20230524 19:03:21 5 variation(s) on previous 3 message(s) suppressed by --mute
20230524 19:03:21 W WARNING: 'link-mtu' is used inconsistently local='link-mtu 1450' remote='link-mtu 1534'
20230524 19:03:21 W WARNING: 'tun-mtu' is used inconsistently local='tun-mtu 1400' remote='tun-mtu 1500'
20230524 19:03:21 W WARNING: 'comp-lzo' is present in local config but missing in remote config local='comp-lzo'
20230524 19:03:21 Control Channel: TLSv1.3 cipher TLSv1.3 TLS_CHACHA20_POLY1305_SHA256 peer certificate: 4096 bit RSA signature: RSA-SHA256
20230524 19:03:21 I [us-phx-ovpn-101.mullvad.net] Peer Connection Initiated with [AF_INET]198.54.###.##:1194
20230524 19:03:22 SENT CONTROL [us-phx-ovpn-101.mullvad.net]: 'PUSH_REQUEST' (status=1)
20230524 19:03:28 SENT CONTROL [us-phx-ovpn-101.mullvad.net]: 'PUSH_REQUEST' (status=1)
20230524 19:03:29 PUSH: Received control message: 'PUSH_REPLY dhcp-option DNS 10.8.0.1 redirect-gateway def1 bypass-dhcp route-ipv6 0000::/2 route-ipv6 4000::/2 route-ipv6 8000::/2 route-ipv6 C000::/2 route-gateway 10.8.0.1 topology subnet socket-flags TCP_NODELAY ifconfig-ipv6 fdda:d0d0:cafe:1194::1006/64 fdda:d0d0:cafe:1194:: ifconfig 10.8.0.8 255.255.0.0 peer-id 7 cipher AES-256-GCM'
20230524 19:03:29 NOTE: --mute triggered...
20230524 19:03:29 1 variation(s) on previous 3 message(s) suppressed by --mute
20230524 19:03:29 W NOTE: setsockopt TCP_NODELAY=1 failed
20230524 19:03:29 OPTIONS IMPORT: --ifconfig/up options modified
20230524 19:03:29 OPTIONS IMPORT: route options modified
20230524 19:03:29 OPTIONS IMPORT: route-related options modified
20230524 19:03:29 NOTE: --mute triggered...
20230524 19:03:29 4 variation(s) on previous 3 message(s) suppressed by --mute
20230524 19:03:29 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
20230524 19:03:29 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
20230524 19:03:29 net_route_v4_best_gw query: dst 0.0.0.0
20230524 19:03:29 net_route_v4_best_gw result: via 98.59.###.# dev vlan2
20230524 19:03:29 GDG6: remote_host_ipv6=n/a
20230524 19:03:29 net_route_v6_best_gw query: dst ::
20230524 19:03:29 net_route_v6_best_gw result: via fe80::21c:73ff:fe00:99 dev vlan2
20230524 19:03:29 I TUN/TAP device tun1 opened
20230524 19:03:29 I net_iface_mtu_set: mtu 1400 for tun1
20230524 19:03:29 I net_iface_up: set tun1 up
20230524 19:03:29 I net_addr_v4_add: 10.8.0.8/16 dev tun1
20230524 19:03:29 I net_iface_mtu_set: mtu 1400 for tun1
20230524 19:03:29 I net_iface_up: set tun1 up
20230524 19:03:29 I net_addr_v6_add: fdda:d0d0:cafe:1194::1006/64 dev tun1
20230524 19:03:29 net_route_v4_add: 198.54.###.##/## via 98.59.###.# dev [NULL] table 0 metric -1
20230524 19:03:29 net_route_v4_add: 0.0.0.0/1 via 10.8.0.1 dev [NULL] table 0 metric -1
20230524 19:03:29 net_route_v4_add: 128.0.0.0/1 via 10.8.0.1 dev [NULL] table 0 metric -1
20230524 19:03:29 I add_route_ipv6(::/2 -> fdda:d0d0:cafe:1194:: metric -1) dev tun1
20230524 19:03:29 net_route_v6_add: ::/2 via :: dev tun1 table 0 metric -1
20230524 19:03:29 I add_route_ipv6(4000::/2 -> fdda:d0d0:cafe:1194:: metric -1) dev tun1
20230524 19:03:29 net_route_v6_add: 4000::/2 via :: dev tun1 table 0 metric -1
20230524 19:03:29 I add_route_ipv6(8000::/2 -> fdda:d0d0:cafe:1194:: metric -1) dev tun1
20230524 19:03:29 net_route_v6_add: 8000::/2 via :: dev tun1 table 0 metric -1
20230524 19:03:29 I add_route_ipv6(c000::/2 -> fdda:d0d0:cafe:1194:: metric -1) dev tun1
20230524 19:03:29 net_route_v6_add: c000::/2 via :: dev tun1 table 0 metric -1
20230524 19:03:29 W WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
20230524 19:03:29 I Initialization Sequence Completed
20230524 19:03:38 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20230524 19:03:38 D MANAGEMENT: CMD 'state'
20230524 19:03:38 MANAGEMENT: Client disconnected
20230524 19:03:38 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20230524 19:03:38 D MANAGEMENT: CMD 'state'
20230524 19:03:38 MANAGEMENT: Client disconnected
20230524 19:03:38 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20230524 19:03:38 D MANAGEMENT: CMD 'state'
20230524 19:03:38 MANAGEMENT: Client disconnected
20230524 19:03:39 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20230524 19:03:39 D MANAGEMENT: CMD 'status 2'
20230524 19:03:39 MANAGEMENT: Client disconnected
20230524 19:03:39 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20230524 19:03:39 D MANAGEMENT: CMD 'log 500'
19691231 16:00:00
Would really appreciate any thoughts/ideas. I am probably missing something simple but I do not understand why it worked for a few days and then just stopped.
Here's a shot in the dark: Upgrade your R9000 to v52330 (*) (04/14/2023) and see if same problem persists.
I have two customers whose R9000's are on DDWRT V52330, running OpenVPN on both Client and Server, with no issue at all. Theỉr VPN provider is not Mullvad, however.
First X10 is not a model. See bottom of your router there are three variants of 802.11ad Netgear hardware series.
While r52330 and r52369 are fine use r52671 or later. Asking for help with old builds generally ignored see guides.
not saying this is the issue but may help.
why not use Wireguard with Mullvad? _________________ Netgear R7800 PPPoE Main Router
Network IPV4 - Isolated Vlan's with IoT Devices. Unifi AC-Pro x 3 AP's, Router Wi-Fi Disabled. OVPN Server With Paid Commercial Wireguard Client's. Gateway Mode, DNSMasq, Static Leases & DHCP, Pi-Hole DNS & Running Unbound.
No one can build you the bridge on which you, and only you, must cross the river of life!
Joined: 18 Mar 2014 Posts: 12877 Location: Netherlands
Posted: Thu May 25, 2023 14:02 Post subject:
OpenVPN does not always recover gracefully from a lost connection.
That happens e.g. when a server is overloaded and you are kicked off, network glitch, server down for maintenance etc.
Optimal settings can mitigate some problems and @foz111 is right that you better block IPv6.
Also compression should be set to Disabled nowadays (But No should also work).
There are more things you can do like specifying more server addresses.
Actually all things which are covered in the OpenVPN client setup guide.
But in the end you often have to enable the watchdog to restart openvpn client (also described in the guide).
WireGuard does a better job recovering from lost connections but WireGuard also has a watchdog and even fail over capacity.
Thank you all for the suggestions! I will try a few and see how it goes. I will report back here My next move was to upgrade versions and I was about to do that yesterday but decided I would post here first.
I only used openvpn as thats what the Mullvard guide says to use. I used their guide here:
again thank you for your help I am happy I posted. I've been using DD-WRT since my WRT54G router that i zip tied to the television antenna on my roof so my neighbor and I could play warcraft back in the day haha.
I flashed the router to 52242 but left all the settings the same and that did not help with the issue (didnt hurt either)
I then ignored the mullvad VPN instructions (some of them) and I did not enable IPv6 as it suggested and I also set compression to disabled per the DD-WRT guide suggestions. I had set it to no before per mullvad guidelines.
Its working again will keep an eye on it and hope it keeps working this time Thanks again for all the suggestions!
Today I lost power. Long enough that my battery backup failed. WHen power was restored my OpenVPN would no longer work.
So I followed the OpenVPN setup exactly as they have it in the documentation in the forum. That did not work but as soon as i changed compression from 'NO' to 'DISABLED' my VPN connected and is working. I dont know if that is unique for my setup but wanted to post it here in case it is useful for someone else with the issue.
It may have been just power cycling of ISP equipment (modem, router, ONT) or DD-WRT reboot that was needed.
Have yet to see any VPN provider with accurate, compatible, optimal or current config documentation for DD-WRT.
It's almost as if they have never tried any 2023 DD-WRT build or ever read egc's OpenVPN and WireGuard guides.
My next move was to upgrade versions and I was about to do that yesterday but decided I would post here first.