[n9nlu]

Hello,

Netgear R7000P
DD-WRT Firmware: DD-WRT v3.0-r49081 std (06/04/22

I have followed the NordVPN published instructions on how to setup NordVPN onto a DD-WRT flashed router. This configuration didn't work at first and I narrowed the issue down to the DNS server addresses in the tutorial - 103.86.96.100 and 103.86.99.100. The tutorial also references checking the --Use DNSMasq for DHCP-- ; that option is not available or may be relabeled as something different or may be placed somewhere different perhaps since this tutorial is probably older than the firmware version I'm using.

While searching for a solution I found a different NordVPN tutorial in which listed the DNS server addresses 103.86.96.96 and 103.86.99.99. I used those DNS addresses and I now can connect to the internet for the most part. Some websites do not work though. I found another NordVPN tutorial addressing the issue of some websites not working. Changing the Tunnel Protocol from UDP to TCP seemed to correct the problem with some websites not loading however brought up a new issue. Clicking a link or entering a URL, there is a very long delay, or stall from the point of clicking to the point of actual page loading. Using the UDP protocol the same sites would load nearly instantly, but using the TCP protocol there is this significant delay.

Speed tests show something interesting as well. With the UDP protocol my speed is around 45meg down / 7 meg up ; TCP protocol has speeds of 95meg down / 10 meg up. Both protocols have around 30 to 32ms ping latency.

I'm not too worried about the download speed difference, but I would like to resolve the issue of websites not loading (UDP), or websites slow to load (TCP).

Any suggestions?

Thank you

[eibgrad]

These kinds of problems are often related to mtu issues.

I reviewed the NordVPN recommended changes, and as usual, they contain things that are NOT recommended by those of us in the forum.

For example, there's no need for all those Additional Config directives (which btw, contain mtu related directives). Just eliminate all of it. In fact, some of it is potentially harmful to the stability of your connection and/or security.

The router is purposely designed to produce the best results by configuring the other GUI options of the OpenVPN client appropriately. The Additional Config is only used in rare cases to handle special situations.

[eibgrad]

A couple more observations.

NordVPN recommends specifying those two DNS servers on the WAN. But that recommendation is based on the assumption you will NOT be using PBR (policy based routing). When PBR is NOT active, the router itself is bound to the VPN just like the rest of the WLAN/LAN clients, so those DNS servers will get routed over the VPN as well.

Problem is, this is NOT necessarily the case when PBR is active. That removes the router from the VPN, and now those DNS servers are routed over the WAN! At least they *would* be but for the fact we anticipated this sort of thing happening and statically bind the push'd DNS servers from the VPN provider (which are typically the same ones you're instructed to assign to the WAN) to the VPN. But that's NOT always the case w/ other third-party firmware, which can often lead to DNS leaks.

Or consider the VPN provider suggestion the use of persist-key and persist-tun in light of the following.

https://svn.dd-wrt.com/ticket/7393

That's why you often have to take the instructions from the VPN provider w/ a heavy grain of salt. Esp. when it comes to configuring beyond the most basic elements (ip, port, protocol, cipher, etc.). Their recommendations are often just bad advice. The router is actually a lot smarter than it may appear to be when it comes to doing the right thing and protecting your security. When the VPN provider goes too far, as NordVPN has done here, it often undermines those efforts.

[n9nlu]

Thanks for the awesomely fast reply !

I'll remove the additional config and see what happens.

In the mean time, I'll post the log of what I get now before I make any changes. Maybe that will point out some issues. I've been trying to make sense of it since there are warnings and errors listed... I have not got far with it.

This is the log immediately after a router reboot.

Log
Clientlog:
19691231 18:00:43 Socket Buffers: R=[262144->262144] S=[262144->262144]
19691231 18:00:43 W --mtu-disc is not supported on this OS
19691231 18:00:43 I UDP link local: (not bound)
19691231 18:00:43 I UDP link remote: [AF_INET]138.199.42.246:1194
19691231 18:00:43 TLS: Initial packet from [AF_INET]138.199.42.246:1194 sid=19dd5ff8 fce0d6b2
19691231 18:00:43 N VERIFY ERROR: depth=2 error=certificate is not yet valid: C=PA O=NordVPN CN=NordVPN Root CA serial=1
19691231 18:00:43 N OpenSSL: error:1416F086:lib(20):func(367):reason(134)
19691231 18:00:43 N TLS_ERROR: BIO read tls_read_plaintext error
19691231 18:00:43 NOTE: --mute triggered...
19691231 18:00:43 2 variation(s) on previous 3 message(s) suppressed by --mute
19691231 18:00:43 I SIGUSR1[soft tls-error] received process restarting
19691231 18:00:43 Restart pause 5 second(s)
19691231 18:00:48 W NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
19691231 18:00:48 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
19691231 18:00:48 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
19691231 18:00:48 I TCP/UDP: Preserving recently used remote address: [AF_INET]138.199.42.246:1194
19691231 18:00:48 Socket Buffers: R=[262144->262144] S=[262144->262144]
19691231 18:00:48 W --mtu-disc is not supported on this OS
19691231 18:00:48 I UDP link local: (not bound)
19691231 18:00:48 I UDP link remote: [AF_INET]138.199.42.246:1194
19691231 18:00:48 TLS: Initial packet from [AF_INET]138.199.42.246:1194 sid=5e5e3339 126d2ae7
19691231 18:00:48 N VERIFY ERROR: depth=2 error=certificate is not yet valid: C=PA O=NordVPN CN=NordVPN Root CA serial=1
19691231 18:00:48 N OpenSSL: error:1416F086:lib(20):func(367):reason(134)
19691231 18:00:48 N TLS_ERROR: BIO read tls_read_plaintext error
19691231 18:00:48 NOTE: --mute triggered...
19691231 18:00:48 2 variation(s) on previous 3 message(s) suppressed by --mute
19691231 18:00:48 I SIGUSR1[soft tls-error] received process restarting
19691231 18:00:48 Restart pause 10 second(s)
19691231 18:00:58 W NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
19691231 18:00:58 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
19691231 18:00:58 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
19691231 18:00:58 I TCP/UDP: Preserving recently used remote address: [AF_INET]138.199.42.246:1194
19691231 18:00:58 Socket Buffers: R=[262144->262144] S=[262144->262144]
19691231 18:00:58 W --mtu-disc is not supported on this OS
19691231 18:00:58 I UDP link local: (not bound)
19691231 18:00:58 I UDP link remote: [AF_INET]138.199.42.246:1194
19691231 18:00:58 TLS: Initial packet from [AF_INET]138.199.42.246:1194 sid=fe50a42e 4a5d8475
19691231 18:00:58 N VERIFY ERROR: depth=2 error=certificate is not yet valid: C=PA O=NordVPN CN=NordVPN Root CA serial=1
19691231 18:00:58 N OpenSSL: error:1416F086:lib(20):func(367):reason(134)
19691231 18:00:58 N TLS_ERROR: BIO read tls_read_plaintext error
19691231 18:00:58 NOTE: --mute triggered...
19691231 18:00:58 2 variation(s) on previous 3 message(s) suppressed by --mute
19691231 18:00:58 I SIGUSR1[soft tls-error] received process restarting
19691231 18:00:58 Restart pause 20 second(s)
20220718 16:56:53 W NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
20220718 16:56:53 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
20220718 16:56:53 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
20220718 16:56:58 N RESOLVE: Cannot resolve host address: us8796.nordvpn.com:1194 (Try again)
20220718 16:56:58 Socket Buffers: R=[262144->262144] S=[262144->262144]
20220718 16:56:58 W --mtu-disc is not supported on this OS
20220718 16:56:58 I UDP link local: (not bound)
20220718 16:56:58 I UDP link remote: [AF_INET]138.199.42.246:1194
20220718 16:56:58 TLS: Initial packet from [AF_INET]138.199.42.246:1194 sid=26d2f9d9 272ad06f
20220718 16:56:58 VERIFY OK: depth=2 C=PA O=NordVPN CN=NordVPN Root CA
20220718 16:56:58 VERIFY OK: depth=1 C=PA O=NordVPN CN=NordVPN CA7
20220718 16:56:58 NOTE: --mute triggered...
20220718 16:56:58 5 variation(s) on previous 3 message(s) suppressed by --mute
20220718 16:56:58 W WARNING: 'link-mtu' is used inconsistently local='link-mtu 1633' remote='link-mtu 1634'
20220718 16:56:58 W WARNING: 'comp-lzo' is present in remote config but missing in local config remote='comp-lzo'
20220718 16:56:58 Control Channel: TLSv1.3 cipher TLSv1.3 TLS_AES_256_GCM_SHA384 peer certificate: 4096 bit RSA signature: RSA-SHA512
20220718 16:56:58 I [us8796.nordvpn.com] Peer Connection Initiated with [AF_INET]138.199.42.246:1194
20220718 16:57:00 SENT CONTROL [us8796.nordvpn.com]: 'PUSH_REQUEST' (status=1)
20220718 16:57:00 PUSH: Received control message: 'PUSH_REPLY redirect-gateway def1 dhcp-option DNS 103.86.96.100 dhcp-option DNS 103.86.99.100 sndbuf 524288 rcvbuf 524288 explicit-exit-notify comp-lzo no route-gateway 10.8.2.1 topology subnet ping 60 ping-restart 180 ifconfig 10.8.2.6 255.255.255.0 peer-id 5 cipher AES-256-GCM'
20220718 16:57:00 OPTIONS IMPORT: timers and/or timeouts modified
20220718 16:57:00 NOTE: --mute triggered...
20220718 16:57:00 3 variation(s) on previous 3 message(s) suppressed by --mute
20220718 16:57:00 Socket Buffers: R=[262144->524288] S=[262144->524288]
20220718 16:57:00 OPTIONS IMPORT: --ifconfig/up options modified
20220718 16:57:00 OPTIONS IMPORT: route options modified
20220718 16:57:00 OPTIONS IMPORT: route-related options modified
20220718 16:57:00 NOTE: --mute triggered...
20220718 16:57:00 4 variation(s) on previous 3 message(s) suppressed by --mute
20220718 16:57:00 Data Channel: using negotiated cipher 'AES-256-GCM'
20220718 16:57:00 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
20220718 16:57:00 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
20220718 16:57:00 net_route_v4_best_gw query: dst 0.0.0.0
20220718 16:57:00 net_route_v4_best_gw result: via 147.219.100.1 dev vlan2
20220718 16:57:00 I TUN/TAP device tun1 opened
20220718 16:57:00 I net_iface_mtu_set: mtu 1500 for tun1
20220718 16:57:00 I net_iface_up: set tun1 up
20220718 16:57:00 I net_addr_v4_add: 10.8.2.6/24 dev tun1
20220718 16:57:00 net_route_v4_add: 138.199.42.246/32 via 147.219.100.1 dev [NULL] table 0 metric -1
20220718 16:57:00 net_route_v4_add: 0.0.0.0/1 via 10.8.2.1 dev [NULL] table 0 metric -1
20220718 16:57:00 net_route_v4_add: 128.0.0.0/1 via 10.8.2.1 dev [NULL] table 0 metric -1
20220718 16:57:00 W WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
20220718 16:57:00 I Initialization Sequence Completed
20220718 16:58:54 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20220718 16:58:54 D MANAGEMENT: CMD 'state'
20220718 16:58:54 MANAGEMENT: Client disconnected
20220718 16:58:54 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20220718 16:58:54 D MANAGEMENT: CMD 'state'
20220718 16:58:54 MANAGEMENT: Client disconnected
20220718 16:58:54 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20220718 16:58:54 D MANAGEMENT: CMD 'state'
20220718 16:58:54 MANAGEMENT: Client disconnected
20220718 16:58:54 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20220718 16:58:54 D MANAGEMENT: CMD 'status 2'
20220718 16:58:54 MANAGEMENT: Client disconnected
20220718 16:58:54 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20220718 16:58:54 D MANAGEMENT: CMD 'log 500'
19691231 18:00:00

[eibgrad]

There's nothing unusual in the syslog. The errors you see are expected. The OpenVPN client is trying to start and verify the certs, but it can't because the time has NOT yet been set. Once it does get set, it retries and finally gets connected.

Yes, there are some warning messages, but these are very common, and can usually be safely ignored. OpenVPN abounds in warning messages in an effort to be as helpful as possible should things go wrong, which is good, but it can end up needlessly worrying users when the situation doesn't warrant it.

P.S. The one warning that can sometimes be an issue is when the compression settings (comp-lzo) don't match on both sides. But if the tunnel is working, you can ignore it.

[eibgrad]

I also just noticed the NordVPN instructions recommend their own killswitch. Again, ignore that advice. It only works correctly when NOT using PBR anyway. The OpenVPN client provides it own (and better) killswitch.

[n9nlu]

I removed all the additional config, set the Tunnel Protocol back to UDP, saved, applied then rebooted.

I still have the issue of some websites not loading.

I changed the Tunnel Protocol to TCP, saved then applied and rebooted the router.

I cannot get a VPN CONNECTED status using the TCP protocol.

So something in that additional config makes the TCP protocol work.

BTW, I'm not using PBR nor have I tinkered with the NordVPN killswitch option. My PC is connected via LAN, and at this point its a fresh flash of DD-WRT with exception to changing passwords and setting up the wifi.

Eventually, I would like to "lock down" this router, but first I would like to get the VPN to behave.

I really appreciate the help and information you are giving me. thank you.

[eibgrad]

Are you sure TCP uses all the same options as UDP? That's not always the case. In my experience, it often requires *minimally* a change in port, esp. if it's to the same server. Sometimes even the server IP.

I don't see anything in the Additional Config field that itself would make the difference.

[eibgrad]

I normally use Mullvad, but I just switched over to my NordVPN account for a moment, which normally uses UDP (udp4 to be exact). That works fine. I then *only* changed it to TCP (tcp4 to be exact) and it failed to connect.

[n9nlu]

UDP seems to just be smoother and faster for whatever reason. Plus my wife, if she needs to go to a site, I just need it to work for her, she's not "technical" , to have her switch Tunnel Protocols on the router is not really realistic.

There's has to be a way to configure this so the UDP Tunnel Protocol works for all websites.

FYI, this is the browser error I receive when using the UDP protocol trying to get to a website that is having this issue. It has to deal with the DNS it appears.

This site can’t be reached wcca.wicourts.gov’s DNS address could not be found. Diagnosing the problem.
DNS_PROBE_POSSIBLE

The error here is one website that does not work with the VPN using the UDP Tunnel Protocol using either HTTP or HTTPS and using Chrome Browser, Brave Browser or Firefox

http://wcca.wicourts.gov/
or
https://wcca.wicourts.gov/

[eibgrad]

If it's a DNS problem, then check specifically with DNS what it's returning, both on the router itself, and a WLAN/LAN client bound to the VPN.

[n9nlu]

This is weird,

[eibgrad]

I have an idea. Let's get away from the NordVPN DNS servers. They don't offer anything special that you can't get from say Cloudflare or Quad9.

If you want to try the Cloudflare DNS servers instead, remove the NordVPN DNS servers from the WAN. Just accept the DNS servers from the ISP for the time being.

Add the following to the Additional DNSMasq Options field on the Services page.

[n9nlu]

Since I put the NordVPN DNS servers in the DD-WRT Setup > Basic Setup > Static DNS 1 and Static DNS 2 - could I just change then to the cloudflare DNS addresses instead of adding the additional config?

Just wondering since dd-wrt is already asking for DNS servers. I've always just used 8.8.4.4 and 1.1.1.1 out of habit...

[n9nlu]

Well, That answered my own question...

I put 1.1.1.1 and 1.0.0.1 in the DNS server 1 and 2 fields in Setup > Basic Setup.

Didn't work...

I put your additional config code into the fields you mentioned to put it and WHAMMO! I have the websites loading now.

Thank you.

you taught an old dog a new trick