VPN server: run on RT-AC68U or RPi 3?

[robca]

I need to install a VPN server to access some of my devices remotely. I'm on an Xfinity 200/5Mbps contract, so quite slow specially for upload.

Given the relatively low end use, I'd like to use my existing hardware: either my RT-AC68U with Merlin, or one of my almost unused RPi 3B+ (1GB). Sooner or later I'll upgrade my main router to a better Asus model, but not for now. The router is only running Diversion and a few extra iptables rules, so it's very lightly loaded. The RPI3 is doing lightweight home automation, and even lower utilization. I will only need to connect while traveling, to check on a couple of thermo/humidity sensors, check a camera, etc. No heavy duty transfers

On the AC68U, OpenVPN seems to be the default choice, even if there now seems to be a way to run Wireguard. On the RPi3, plenty of choices.

I'd like to get input from this knowledgeable community on the best option both in terms of device to run the server on, and VPN to choose.

 

[Crimliar]

Much as I've loved my Raspberry Pi's and their replacements, it'll be far easier to set up via the router. If you were to use the RPi you'd still need to get the devices to use the RPi as their gateway. Far easier to use VPN Director and just set everything up on the router Web-GUI! With a more modern Asus router, you could use Instant Guard and save even more hassle.

 

[ColinTaylor]

Much as I've loved my Raspberry Pi's and their replacements, it'll be far easier to set up via the router. If you were to use the RPi you'd still need to get the devices to use the RPi as their gateway. Far easier to use VPN Director and just set everything up on the router Web-GUI! With a more modern Asus router, you could use Instant Guard and save even more hassle.

You're talking about the router's VPN client, but he's asking about a VPN server.

 

[robca]

You're talking about the router's VPN client, but he's asking about a VPN server.

Correct, thanks! I need to be able to securely access devices on my home network while traveling. I'd rather not open ports for those devices, especially considering the iffy security of the Chinese cameras (which currently are on a "segregated" subnet and with iptable/ebtables rules to prevent internet access)

 

[Tech9]

Xfinity 200/5Mbps

No matter where you run your VPN server your upload will be limited by your ISP. Run it on the router, OpenVPN. Extra complication not needed.

 

[robca]

Yes, of course. The slow upload of my internet provider is the gating element here, I think I mentioned it upfront.

But I was reading that OpenVPN adds ~20% overhead vs Wireguard's ~4%, so that will further slow things down, even if real time video streaming is not going to happen either way

More than anything, I wanted to be sure that an old RT-AC68U can handle light OpenVPN with no stability issues. Which, from your answer, seems to be the case. If so, I agree, simple is better and OpenVPN is the way to go

 

[ColinTaylor]

The RT-AC68U has no problem running an OpenVPN server, albeit at fairly low throughput (<50Mbps). WireGuard is not a practical alternative for the RT-AC68U as there is no kernel support for it. Whether the RT-AC68U's OpenVPN is faster than your Pi I don't know so I suggest you try it for yourself. It only takes a minute to setup the OpenVPN server on the router and a couple more minutes to test it.

 

[Tech9]

I was running an RT-AC66U B1* for some time as VPN server in another country. It was doing about 40Mbps consistently and was up and running for months until Asus killed it by accident with the bad ASD update. Confirming - the built-in OpenVPN server is reliable and the speed is fast enough.

* - the same hardware as RT-AC68U running the same firmware

 

[robca]

Thanks @ColinTaylor and @Tech9, that settles it

I started also testing Wireguard and OpenVpn on the RPi using https://docs.pivpn.io/, but I'll get OpenVPN enabled on the AC68U now. One less thing to manage and keep updated. Thanks everyone for the help

 

[robca]

I followed this guide https://www.snbforums.com/threads/vpn-instructions-for-a-newbie.59478/#post-523302 and got OpenVPN working for TCP, but not UDP. As per the suggestions on that post, I have 2 instances of the server, one for TCP, one for UDP. With the TCP server/port 443, everything works as expected. With the UDP/11194 (I changed port on server and checked it's the same on the client), I cna ping devices on my network, but not connect the them.

I installed the official OpenVPN client for Android, and also Arne Schwabe's version, it makes no difference. My router is on the Xfinity/Comcast network and from Android I'm using either an external WiFi or wireless data (Google Fi)

Looking for clues, I found https://www.snbforums.com/threads/openvpn-not-working-with-udp-anymore-tcp-works.86646/ Stupid question: how do I add the mssfix option to OpenVPN? I tried adding it to the custom configuration UI (just below "local ddns") as mssfix 1452, but it doesn't seem to do nothing

Here's the OpenVPN official client log when connecting using UDP, just n case someone here can spot the issue

[Dec 18, 2023, 13:48:24] ----- OpenVPN Start -----

[Dec 18, 2023, 13:48:24] EVENT: CORE_THREAD_ACTIVE

[Dec 18, 2023, 13:48:24] OpenVPN core 3.git::081bfebe:RelWithDebInfo android arm64 64-bit PT_PROXY

[Dec 18, 2023, 13:48:24] Frame=512/2048/512 mssfix-ctrl=1250

[Dec 18, 2023, 13:48:24] UNUSED OPTIONS
4 [resolv-retry] [infinite]
5 [nobind]
7 [ncp-ciphers] [AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC]

[Dec 18, 2023, 13:48:24] EVENT: RESOLVE

[Dec 18, 2023, 13:48:25] Contacting xx.xxx.xxx.170:11194 via UDP

[Dec 18, 2023, 13:48:25] EVENT: WAIT

[Dec 18, 2023, 13:48:25] Connecting to [xxxxx.ddns.net]:11194 (xx.xxx.xxx.170) via UDPv4

[Dec 18, 2023, 13:48:25] EVENT: CONNECTING

[Dec 18, 2023, 13:48:25] Tunnel Options:V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,keydir 1,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client

[Dec 18, 2023, 13:48:25] Creds: Username/Password

[Dec 18, 2023, 13:48:25] Peer Info:
IV_VER=3.git::081bfebe:RelWithDebInfo
IV_PLAT=android
IV_NCP=2
IV_TCPNL=1
IV_PROTO=30
IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:BF-CBC
IV_GUI_VER=net.openvpn.connect.android_3.3.4-9290
IV_SSO=webauth,openurl,crtext
IV_BS64DL=1


[Dec 18, 2023, 13:48:25] VERIFY OK: depth=1, /C=TW/ST=TW/L=Taipei/O=ASUS/OU=Home/Office/CN=RT-AC68U/emailAddress=me@asusrouter.lan, signature: RSA-SHA256

[Dec 18, 2023, 13:48:25] VERIFY OK: depth=0, /C=TW/ST=TW/L=Taipei/O=ASUS/OU=Home/Office/CN=RT-AC68U/emailAddress=me@asusrouter.lan, signature: RSA-SHA256

[Dec 18, 2023, 13:48:25] SSL Handshake: peer certificate: CN=RT-AC68U, 2048 bit RSA, cipher: TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD


[Dec 18, 2023, 13:48:25] Session is ACTIVE

[Dec 18, 2023, 13:48:25] Sending PUSH_REQUEST to server...

[Dec 18, 2023, 13:48:25] EVENT: GET_CONFIG

[Dec 18, 2023, 13:48:25] OPTIONS:
0 [route] [192.168.1.0] [255.255.255.0] [vpn_gateway] [500]
1 [dhcp-option] [DNS] [192.168.1.1]
2 [redirect-gateway] [def1]
3 [route-gateway] [10.16.0.1]
4 [topology] [subnet]
5 [ping] [15]
6 [ping-restart] [60]
7 [ifconfig] [10.16.0.3] [255.255.255.0]
8 [peer-id] [1]
9 [cipher] [AES-128-GCM]
10 [key-derivation] [tls-ekm]


[Dec 18, 2023, 13:48:25] PROTOCOL OPTIONS:
cipher: AES-128-GCM
digest: NONE
key-derivation: TLS Keying Material Exporter [RFC5705]
compress: NONE
peer ID: 1
control channel: tls-auth enabled

[Dec 18, 2023, 13:48:25] EVENT: ASSIGN_IP

[Dec 18, 2023, 13:48:25] Connected via tun

[Dec 18, 2023, 13:48:25] EVENT: CONNECTED info='xxxxx@xxxx.ddns.net:11194 (xx.xxx.xxx.170) via /UDPv4 on tun/10.16.0.3/ gw=[10.16.0.1/]'

 

[ColinTaylor]

I don't know why there's a need for the wall of text in that "guide". I suggest you ignore it, reset your UDP VPN settings and just use the defaults (but change the port number). No custom configuration is required. It should just work. If you still have problems post the new server and client logs.

Bear in mind that whichever VPN profile you use you will have to make allowance for its subnet in the firewall (if it has one) of any device you're connecting to.

 

[robca]

I don't know why there's a need for the wall of text in that "guide". I suggest you ignore it, reset your UDP VPN settings and just use the defaults (but change the port number). No custom configuration is required. It should just work. If you still have problems post the new server and client logs.

Bear in mind that whichever VPN profile you use you will have to make allowance for its subnet in the firewall (if it has one) of any device you're connecting to.

Thanks for your patience with me,

You're right, that post has a lot of extra info. But, bottom line, the settings recommended are pretty much the default settings

and

The only thing changed was the TLS Control channel, set to Incoming. I reset it back to Disable

But still UDP doesn't work. TCP works perfectly, UDP I can only ping but not connect to any device. I don't think it's a device or firewall issue, since OpenVPN using TCP transport works, just UDP doesn't.

Granted, TCP works, so I could call it a day.... but I'd like to have both options, just in case.

 

[sfx2000]

I wanted to be sure that an old RT-AC68U can handle light OpenVPN with no stability issues.

Just note that the AC68U is getting towards it's end of support - so exposing any services to the WAN is going to introduce risk as new issues are found.

 

[ColinTaylor]

What type of Wan connection do you have? DHCP, PPPoE, etc.

How are you testing connectivity? You say ping works, what doesn't?

 

[robca]

What type of Wan connection do you have? DHCP, PPPoE, etc.

How are you testing connectivity? You say ping works, what doesn't?

It's "automatic IP", with the router connected to a Arris modem, connected to Xfinity cable.

I connect my Android phone to a different WiFi network or use my cellular data. Connect via OpenVPN to server2 (TUN,UDP), no errors on the router or client log. Ping to any internal device works, then try to connect to an embedded webserver on my home network (Tasmota) for a few devices, and nothing. Everything else being the same but using TUN/TCP, ping and Tasmota web browsing works. I know it's not Tasmota, as trying to connect to the AC68U web UI (or another AC68U I use as AP) doesn't work either. None of the webservers on my home network can connect when using OpenVPN in UDP mode. All work in TCP mode.

 

[robca]

Just note that the AC68U is getting towards it's end of support - so exposing any services to the WAN is going to introduce risk as new issues are found.

That's a good point, but once support ends, the risk profile of running OpenVPN or just having that router internet facing is roughly the same (unless an OpenVPN specific issue is found). Once the AC68U is not supported anymore, I'll have an excuse to update it to a better Asus router

 

[ColinTaylor]

It's "automatic IP", with the router connected to a Arris modem, connected to Xfinity cable.

I connect my Android phone to a different WiFi network or use my cellular data. Connect via OpenVPN to server2 (TUN,UDP), no errors on the router or client log. Ping to any internal device works, then try to connect to an embedded webserver on my home network (Tasmota) for a few devices, and nothing. Everything else being the same but using TUN/TCP, ping and Tasmota web browsing works. I know it's not Tasmota, as trying to connect to the AC68U web UI (or another AC68U I use as AP) doesn't work either. None of the webservers on my home network can connect when using OpenVPN in UDP mode. All work in TCP mode.

Try adding tun-mtu 1400 to the VPN server's Custom Configuration box.

If that doesn't work try replacing that line with mssfix 1400 instead.

Otherwise I can't think what the problem is. My server settings are exactly the same as your's and I've never had a problem with them (they're the defaults for a reason).

 

[robca]

Try adding tun-mtu 1400 to the VPN server's Custom Configuration box.

If that doesn't work try replacing that line with mssfix 1400 instead.

Otherwise I can't think what the problem is. My server settings are exactly the same as your's and I've never had a problem with them (they're the defaults for a reason).

That did the trick, thanks so much! Really appreciated the time you spent on this. Happy to have both transports enabled now

 

[ColinTaylor]

Great! For future reference which option was it that worked?

I deliberately chose a very low value. It's likely you could edge it up from 1400 to something approaching 1500. Experimentation will be required.

 

[robca]

Great! For future reference which option was it that worked?

I deliberately chose a very low value. It's likely you could edge it up from 1400 to something approaching 1500. Experimentation will be required.

tun-mtu 1400

worked.

And, yes, I was already planning to experiment, but for now having something that works was the most important thing. Optimization can wait