dissonant

100Mbps would be acceptable, maybe i'll look into the R3 or other routers that will implement dumaOS 4. have you guys ever thought of broadcasting an additional SSID that you could have behind the VPN? i think that its a little clunky going into the router interface to either add or remove devices so having a separate SSID similar to how you have guest networks would be a nice feature (and also you wouldn't have to give other people the admin password to the router)

Thanks for explaining that this is an older implementation that is no longer relevant for future models... Makes sense why fixing a problem in your old implementation of the feature isn't desirable. I did notice that the downloads through the hVPN when it was working seemed to be limited to around 600kBps where I've noticed speeds of up to 6-7 MBps when i use the VPN app running on Windows. You think that was due to processing power within the router being limited, comparatively speaking? I liked the router hVPN mostly because the windows app seems to use CPU clock time even when not connected.

Ok, well nothing I tried works. Entering any new configs, adding those additional lines to the config or trying UDP do not seem to do anything as I don't think that the router connecting to the VPN is the issue. I've seen connection issues in the past and they are indicated on the hVPN screen. I think its an issue with how the router then chooses which hosts to put behind the VPN. I guess I'll just have to stop using this feature, unless you have any other ways to troubleshoot this in the future.

So I did chat with support at Surfshark and they said: "You can try but I am not sure if that will affect the connection. We are not sure if those syslogs will work. I suggest that you give it a try. If it works, that's great. If it does not, well you know the answer. I am not sure we have any other such logging commands. We have strict no-logs policy so we do not use commands of that sort. My deepest apologies." Pretty sad but at least they're affordable I suppose! Unfortunately I'm 2500 miles to the closest server being out in the middle of the pacific ocean. They do offer other manual protocols such as Wireguard and IKEv2, but i'm not sure how to make key pairs or certificates work with the router. Are these supported, if so how would I go about configuring it? I'm currently only implementing the TCP OpenVPN config as I'm also not sure how to combine with the UDP config, and haven't had issues using just the TCP config in the past. I'm still not sure we know there's a connection issue to Surfshark at all. When I've had connection issues, I would be alerted by the internet being dropped. I would login to the router, check the hVPN page and see that it says the connection has failed, so I would disable and then reenable, see that the VPN connection was successful and then I'd verify my public facing IP to confirm its working. If we assume that the VPN connection is not the issue, is there a way to check for issues with how the router should be adding devices behind the VPN? Without visibility into this process it would seem futile to troubleshoot VPN connection issues given that we do have some visibility over that process, with the limited logs that are available.

No I haven't, that is the primary reason why I have been turning off the VPN because I would lose all access to the app if I reboot with it active. I've been making sure to turn it off before saving configs as well, since it reboots after loading them.

I leave it connected because I have torrents queued when I went to sleep. Some torrents don't have many or any seeders, so I may will keep the VPN on while waiting for seeders to log i. I did try the rebooting at the beginning without success. I have been turning off the VPN when I am not downloading or have downloads queued. I guess I have a hard time believing that features provided should only be expected to work some of the time, especially if there is no indication that it is not working. The router says its connected to the VPN, it says it will drop the connection if the VPN disconnects and it says certain devices are behind the VPN. I would want the router to at least provide a way to letting you know that its not working properly.

Define constantly. Last night I removed the ip reservations in case that was it and reflashed with the 2 bios files, confirmed that the hVPN was working, went to bed, woke up and tested again (less than 12 hours later) and its not working. So if you consider constantly 12 hours then yes, I guess that it is constantly. The issue is if I can't count on the hVPN to not block traffic when its not working then using this feature is too risky and I'll need to go back to using a VPN app or programming a different router (ddWRT). I don't have any configs from earlier versions.

I checked again this morning and hVPN is not working again.... not sure whats going on... One setting I've just started using was reserving addresses in the LAN section. But I tested the hVPN prior to making those reservations, and then added the reservation and checked it again and it was working last night, but then I checked it this morning and its not working anymore. Could this be related?

So I tried loading older config files to see if that had an effect (it did not). Then I reflashed the device and it is working properly again. I did both the part 1 and part 2 firmware to be thorough. Really strange we couldn't figure out why the router says it connects to the VPN provider, yet it won't put the specified devices behind the VPN... Maybe some logging capability on the specified device side would help troubleshoot in the future? Not sure why no one else has had this issue with the hVPN, but maybe its not being utilized or tested much?

Yes, I thought about that and I did add another device and it too isn't behind the VPN. Let me know if there's anything else I can provide to help troubleshoot issues with the firmware before I reflash...

Anything else you think I should try or provide before loading a saved config file or reflashing the bios?

Unfortunately no change with the updated hVPN config. See log file below: Fri Nov 15 23:32:20 2024 OpenVPN 2.4.3 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jul 19 2023 Fri Nov 15 23:32:20 2024 library versions: OpenSSL 1.0.2n 7 Dec 2017, LZO 2.06 Fri Nov 15 23:32:20 2024 WARNING: --ping should normally be used with --ping-restart or --ping-exit Fri Nov 15 23:32:20 2024 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Fri Nov 15 23:32:20 2024 NOTE: --fast-io is disabled since we are not using UDP Fri Nov 15 23:32:20 2024 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication Fri Nov 15 23:32:20 2024 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication Fri Nov 15 23:32:20 2024 TCP/UDP: Preserving recently used remote address: [AF_INET]84.17.41.81:1443 Fri Nov 15 23:32:20 2024 Socket Buffers: R=[87380->87380] S=[16384->16384] Fri Nov 15 23:32:20 2024 Attempting to establish TCP connection with [AF_INET]84.17.41.81:1443 [nonblock] Fri Nov 15 23:32:21 2024 TCP connection established with [AF_INET]84.17.41.81:1443 Fri Nov 15 23:32:21 2024 TCP_CLIENT link local: (not bound) Fri Nov 15 23:32:21 2024 TCP_CLIENT link remote: [AF_INET]84.17.41.81:1443 Fri Nov 15 23:32:21 2024 TLS: Initial packet from [AF_INET]84.17.41.81:1443, sid=94347452 94e8052c Fri Nov 15 23:32:21 2024 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this Fri Nov 15 23:32:21 2024 VERIFY OK: depth=2, C=VG, O=Surfshark, CN=Surfshark Root CA Fri Nov 15 23:32:21 2024 VERIFY OK: depth=1, C=VG, O=Surfshark, CN=Surfshark Intermediate CA Fri Nov 15 23:32:21 2024 VERIFY KU OK Fri Nov 15 23:32:21 2024 Validating certificate extended key usage Fri Nov 15 23:32:21 2024 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Fri Nov 15 23:32:21 2024 VERIFY EKU OK Fri Nov 15 23:32:21 2024 VERIFY OK: depth=0, CN=us-sea-v013.prod.surfshark.com Fri Nov 15 23:32:21 2024 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1603', remote='link-mtu 1583' Fri Nov 15 23:32:21 2024 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher AES-256-GCM' Fri Nov 15 23:32:21 2024 WARNING: 'auth' is used inconsistently, local='auth SHA512', remote='auth [null-digest]' Fri Nov 15 23:32:21 2024 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Fri Nov 15 23:32:21 2024 [us-sea-v013.prod.surfshark.com] Peer Connection Initiated with [AF_INET]84.17.41.81:1443 Fri Nov 15 23:32:22 2024 SENT CONTROL [us-sea-v013.prod.surfshark.com]: 'PUSH_REQUEST' (status=1) Fri Nov 15 23:32:22 2024 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 162.252.172.57,dhcp-option DNS 149.154.159.92,redirect-gateway def1,sndbuf 524288,rcvbuf 524288,explicit-exit-notify,block-outside-dns,route-gateway 10.7.7.1,topology subnet,ping 60,ping-restart 180,ifconfig 10.7.7.7 255.255.255.0,peer-id 5,cipher AES-256-GCM' Fri Nov 15 23:32:22 2024 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:7: block-outside-dns (2.4.3) Fri Nov 15 23:32:22 2024 OPTIONS IMPORT: timers and/or timeouts modified Fri Nov 15 23:32:22 2024 OPTIONS IMPORT: --explicit-exit-notify can only be used with --proto udp Fri Nov 15 23:32:22 2024 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified Fri Nov 15 23:32:22 2024 Socket Buffers: R=[87380->327680] S=[21480->327680] Fri Nov 15 23:32:22 2024 OPTIONS IMPORT: --ifconfig/up options modified Fri Nov 15 23:32:22 2024 OPTIONS IMPORT: route options modified Fri Nov 15 23:32:22 2024 OPTIONS IMPORT: route-related options modified Fri Nov 15 23:32:22 2024 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified Fri Nov 15 23:32:22 2024 OPTIONS IMPORT: peer-id set Fri Nov 15 23:32:22 2024 OPTIONS IMPORT: adjusting link_mtu to 1626 Fri Nov 15 23:32:22 2024 OPTIONS IMPORT: data channel crypto options modified Fri Nov 15 23:32:22 2024 Data Channel: using negotiated cipher 'AES-256-GCM' Fri Nov 15 23:32:22 2024 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key Fri Nov 15 23:32:22 2024 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key Fri Nov 15 23:32:22 2024 TUN/TAP device tun0 opened Fri Nov 15 23:32:22 2024 TUN/TAP TX queue length set to 100 Fri Nov 15 23:32:22 2024 do_ifconfig, tt->did_ifconfig_ipv6_setup=0 Fri Nov 15 23:32:22 2024 /sbin/ifconfig tun0 10.7.7.7 netmask 255.255.255.0 mtu 1500 broadcast 10.7.7.255 Fri Nov 15 23:32:22 2024 /bin/touch /tmp/lua_k3eZws tun0 1500 1554 10.7.7.7 255.255.255.0 init Fri Nov 15 23:32:22 2024 Initialization Sequence Completed

Here you go: client dev tun proto tcp remote us-sea.prod.surfshark.com 1443 remote-random nobind tun-mtu 1500 mssfix 1450 ping 15 ping-restart 0 reneg-sec 0 remote-cert-tls server auth-user-pass #comp-lzo verb 3 fast-io cipher AES-256-CBC auth SHA512 <ca> -----BEGIN CERTIFICATE----- MIIFTTCCAzWgAwIBAgIJAMs9S3fqwv+mMA0GCSqGSIb3DQEBCwUAMD0xCzAJBgNV BAYTAlZHMRIwEAYDVQQKDAlTdXJmc2hhcmsxGjAYBgNVBAMMEVN1cmZzaGFyayBS b290IENBMB4XDTE4MDMxNDA4NTkyM1oXDTI4MDMxMTA4NTkyM1owPTELMAkGA1UE BhMCVkcxEjAQBgNVBAoMCVN1cmZzaGFyazEaMBgGA1UEAwwRU3VyZnNoYXJrIFJv b3QgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDEGMNj0aisM63o SkmVJyZPaYX7aPsZtzsxo6m6p5Wta3MGASoryRsBuRaH6VVa0fwbI1nw5ubyxkua Na4v3zHVwuSq6F1p8S811+1YP1av+jqDcMyojH0ujZSHIcb/i5LtaHNXBQ3qN48C c7sqBnTIIFpmb5HthQ/4pW+a82b1guM5dZHsh7q+LKQDIGmvtMtO1+NEnmj81BAp FayiaD1ggvwDI4x7o/Y3ksfWSCHnqXGyqzSFLh8QuQrTmWUm84YHGFxoI1/8AKdI yVoB6BjcaMKtKs/pbctk6vkzmYf0XmGovDKPQF6MwUekchLjB5gSBNnptSQ9kNgn TLqi0OpSwI6ixX52Ksva6UM8P01ZIhWZ6ua/T/tArgODy5JZMW+pQ1A6L0b7egIe ghpwKnPRG+5CzgO0J5UE6gv000mqbmC3CbiS8xi2xuNgruAyY2hUOoV9/BuBev8t tE5ZCsJH3YlG6NtbZ9hPc61GiBSx8NJnX5QHyCnfic/X87eST/amZsZCAOJ5v4EP SaKrItt+HrEFWZQIq4fJmHJNNbYvWzCE08AL+5/6Z+lxb/Bm3dapx2zdit3x2e+m iGHekuiE8lQWD0rXD4+T+nDRi3X+kyt8Ex/8qRiUfrisrSHFzVMRungIMGdO9O/z CINFrb7wahm4PqU2f12Z9TRCOTXciQIDAQABo1AwTjAdBgNVHQ4EFgQUYRpbQwyD ahLMN3F2ony3+UqOYOgwHwYDVR0jBBgwFoAUYRpbQwyDahLMN3F2ony3+UqOYOgw DAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQsFAAOCAgEAn9zV7F/XVnFNZhHFrt0Z S1Yqz+qM9CojLmiyblMFh0p7t+Hh+VKVgMwrz0LwDH4UsOosXA28eJPmech6/bjf ymkoXISy/NUSTFpUChGO9RabGGxJsT4dugOw9MPaIVZffny4qYOc/rXDXDSfF2b+ 303lLPI43y9qoe0oyZ1vtk/UKG75FkWfFUogGNbpOkuz+et5Y0aIEiyg0yh6/l5Q 5h8+yom0HZnREHhqieGbkaGKLkyu7zQ4D4tRK/mBhd8nv+09GtPEG+D5LPbabFVx KjBMP4Vp24WuSUOqcGSsURHevawPVBfgmsxf1UCjelaIwngdh6WfNCRXa5QQPQTK ubQvkvXONCDdhmdXQccnRX1nJWhPYi0onffvjsWUfztRypsKzX4dvM9k7xnIcGSG EnCC4RCgt1UiZIj7frcCMssbA6vJ9naM0s7JF7N3VKeHJtqe1OCRHMYnWUZt9vrq X6IoIHlZCoLlv39wFW9QNxelcAOCVbD+19MZ0ZXt7LitjIqe7yF5WxDQN4xru087 FzQ4Hfj7eH1SNLLyKZkA1eecjmRoi/OoqAt7afSnwtQLtMUc2bQDg6rHt5C0e4dC LqP/9PGZTSJiwmtRHJ/N5qYWIh9ju83APvLm/AGBTR2pXmj9G3KdVOkpIC7L35dI 623cSEC3Q3UZutsEm/UplsM= -----END CERTIFICATE----- </ca> key-direction 1 <tls-auth> # # 2048 bit OpenVPN static key # -----BEGIN OpenVPN Static key V1----- b02cb1d7c6fee5d4f89b8de72b51a8d0 c7b282631d6fc19be1df6ebae9e2779e 6d9f097058a31c97f57f0c35526a44ae 09a01d1284b50b954d9246725a1ead1f f224a102ed9ab3da0152a15525643b2e ee226c37041dc55539d475183b889a10 e18bb94f079a4a49888da566b9978346 0ece01daaf93548beea6c827d9674897 e7279ff1a19cb092659e8c1860fbad0d b4ad0ad5732f1af4655dbd66214e552f 04ed8fd0104e1d4bf99c249ac229ce16 9d9ba22068c6c0ab742424760911d463 6aafb4b85f0c952a9ce4275bc821391a a65fcd0d2394f006e3fba0fd34c4bc4a b260f4b45dec3285875589c97d3087c9 134d3a3aa2f904512e85aa2dc2202498 -----END OpenVPN Static key V1----- </tls-auth>

Yeah, I have noticed in the past the IP might be cached on certain ip location sites if I check right before enabling the hVPN and then check again, so I open an incognito window and also try other IP location sites that I haven't been to recently so I know the IP is not cached. Here's the log: Tue Nov 12 08:59:18 2024 OpenVPN 2.4.3 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jul 19 2023 Tue Nov 12 08:59:18 2024 library versions: OpenSSL 1.0.2n 7 Dec 2017, LZO 2.06 Tue Nov 12 08:59:18 2024 WARNING: --ping should normally be used with --ping-restart or --ping-exit Tue Nov 12 08:59:18 2024 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Tue Nov 12 08:59:18 2024 NOTE: --fast-io is disabled since we are not using UDP Tue Nov 12 08:59:18 2024 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication Tue Nov 12 08:59:18 2024 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication Tue Nov 12 08:59:18 2024 TCP/UDP: Preserving recently used remote address: [AF_INET]149.102.254.32:1443 Tue Nov 12 08:59:18 2024 Socket Buffers: R=[87380->87380] S=[16384->16384] Tue Nov 12 08:59:18 2024 Attempting to establish TCP connection with [AF_INET]149.102.254.32:1443 [nonblock] Tue Nov 12 08:59:19 2024 TCP connection established with [AF_INET]149.102.254.32:1443 Tue Nov 12 08:59:19 2024 TCP_CLIENT link local: (not bound) Tue Nov 12 08:59:19 2024 TCP_CLIENT link remote: [AF_INET]149.102.254.32:1443 Tue Nov 12 08:59:19 2024 TLS: Initial packet from [AF_INET]149.102.254.32:1443, sid=c19aadce 207590bd Tue Nov 12 08:59:19 2024 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this Tue Nov 12 08:59:19 2024 VERIFY OK: depth=2, C=VG, O=Surfshark, CN=Surfshark Root CA Tue Nov 12 08:59:19 2024 VERIFY OK: depth=1, C=VG, O=Surfshark, CN=Surfshark Intermediate CA Tue Nov 12 08:59:19 2024 VERIFY KU OK Tue Nov 12 08:59:19 2024 Validating certificate extended key usage Tue Nov 12 08:59:19 2024 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Tue Nov 12 08:59:19 2024 VERIFY EKU OK Tue Nov 12 08:59:19 2024 VERIFY OK: depth=0, CN=us-sea-v051.prod.surfshark.com Tue Nov 12 08:59:19 2024 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1603', remote='link-mtu 1583' Tue Nov 12 08:59:19 2024 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher AES-256-GCM' Tue Nov 12 08:59:19 2024 WARNING: 'auth' is used inconsistently, local='auth SHA512', remote='auth [null-digest]' Tue Nov 12 08:59:19 2024 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA Tue Nov 12 08:59:19 2024 [us-sea-v051.prod.surfshark.com] Peer Connection Initiated with [AF_INET]149.102.254.32:1443 Tue Nov 12 08:59:21 2024 SENT CONTROL [us-sea-v051.prod.surfshark.com]: 'PUSH_REQUEST' (status=1) Tue Nov 12 08:59:21 2024 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 162.252.172.57,dhcp-option DNS 149.154.159.92,redirect-gateway def1,sndbuf 524288,rcvbuf 524288,explicit-exit-notify,block-outside-dns,route-gateway 10.7.7.1,topology subnet,ping 60,ping-restart 180,ifconfig 10.7.7.13 255.255.255.0,peer-id 11,cipher AES-256-GCM' Tue Nov 12 08:59:21 2024 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:7: block-outside-dns (2.4.3) Tue Nov 12 08:59:21 2024 OPTIONS IMPORT: timers and/or timeouts modified Tue Nov 12 08:59:21 2024 OPTIONS IMPORT: --explicit-exit-notify can only be used with --proto udp Tue Nov 12 08:59:21 2024 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified Tue Nov 12 08:59:21 2024 Socket Buffers: R=[87380->327680] S=[21480->327680] Tue Nov 12 08:59:21 2024 OPTIONS IMPORT: --ifconfig/up options modified Tue Nov 12 08:59:21 2024 OPTIONS IMPORT: route options modified Tue Nov 12 08:59:21 2024 OPTIONS IMPORT: route-related options modified Tue Nov 12 08:59:21 2024 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified Tue Nov 12 08:59:21 2024 OPTIONS IMPORT: peer-id set Tue Nov 12 08:59:21 2024 OPTIONS IMPORT: adjusting link_mtu to 1626 Tue Nov 12 08:59:21 2024 OPTIONS IMPORT: data channel crypto options modified Tue Nov 12 08:59:21 2024 Data Channel: using negotiated cipher 'AES-256-GCM' Tue Nov 12 08:59:21 2024 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key Tue Nov 12 08:59:21 2024 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key Tue Nov 12 08:59:21 2024 TUN/TAP device tun0 opened Tue Nov 12 08:59:21 2024 TUN/TAP TX queue length set to 100 Tue Nov 12 08:59:21 2024 do_ifconfig, tt->did_ifconfig_ipv6_setup=0 Tue Nov 12 08:59:21 2024 /sbin/ifconfig tun0 10.7.7.13 netmask 255.255.255.0 mtu 1500 broadcast 10.7.7.255 Tue Nov 12 08:59:21 2024 /bin/touch /tmp/lua_LSJMk6 tun0 1500 1554 10.7.7.13 255.255.255.0 init Tue Nov 12 08:59:21 2024 Initialization Sequence Completed

Oh, well that side didn't change.... I've had it the same way the entire time and it just stopped working, but here you go.