AXT1800 Will VPN to NordVPN but not my own VPN Server

I have a new AXT1800 and was able to set it up to use my two wifi providers at home (one at a time, of course) and to connect to NordVPN servers. Traffic flows quite well - I’m happy.

I also have a Raspberry Pi 4 with OpenWRT running on it that I set up a couple of years ago to connect to my NetGear router on which I have enabled the OpenVPN server. That’s worked well, but was a real PITA to set up. Still works.

So, I wanted to enable my AXT1800 to use my Netgear router, too. I logged in and downloaded the “nonwindows” zip file, which includes the usual client.ovpn file, as well as a client key, client cert and CA cert.

The VPN seems to connect and the status light turns green, but no traffic flows through it: Traffic stats show 0.00 B up and down, and there is no Client Virtual IP showing.

Here is a cleaned up log:

“Tue Jan 16 19:49:30 2024 user.notice mwan3[26543]: Starting tracker on interface ovpnclient (ovpnclient)\n
Tue Jan 16 19:49:30 2024 daemon.err ovpnclient[26183]: write to TUN/TAP : Invalid argument (code=22)\n
Tue Jan 16 19:49:31 2024 daemon.err ovpnclient[26183]: write to TUN/TAP : Invalid argument (code=22)\n
Tue Jan 16 19:49:32 2024 daemon.err ovpnclient[26183]: write to TUN/TAP : Invalid argument (code=22)\n
Tue Jan 16 19:49:33 2024 user.notice firewall: Reloading firewall due to ifup of ovpnclient (ovpnclient)\n
Tue Jan 16 19:49:34 2024 daemon.err ovpnclient[26183]: write to TUN/TAP : Invalid argument (code=22)\n
Tue Jan 16 19:49:35 2024 daemon.warn ovpnclient[26183]: WARNING: this configuration may cache passwords in memory – use the auth-nocache option to prevent this\n
Tue Jan 16 19:49:35 2024 daemon.notice ovpnclient[26183]: Initialization Sequence Completed\n
Tue Jan 16 19:49:35 2024 daemon.err ovpnclient[26183]: write to TUN/TAP : Invalid argument (code=22)\n
Tue Jan 16 19:49:36 2024 daemon.err ovpnclient[26183]: write to TUN/TAP : Invalid argument (code=22)\n
Tue Jan 16 19:49:37 2024 daemon.err ovpnclient[26183]: write to TUN/TAP : Invalid argument (code=22)\n
Tue Jan 16 19:49:37 2024 daemon.err ovpnclient[26183]: write to TUN/TAP : Invalid argument (code=22)\n
Tue Jan 16 19:49:38 2024 daemon.err ovpnclient[26183]: write to TUN/TAP : Invalid argument (code=22)\n
Tue Jan 16 19:49:39 2024 daemon.err ovpnclient[26183]: write to TUN/TAP : Invalid argument (code=22)\n
Tue Jan 16 19:49:40 2024 daemon.err ovpnclient[26183]: write to TUN/TAP : Invalid argument (code=22)\n
Tue Jan 16 19:49:41 2024 daemon.err ovpnclient[26183]: write to TUN/TAP : Invalid argument (code=22)\n
Tue Jan 16 19:49:42 2024 daemon.err ovpnclient[26183]: write to TUN/TAP : Invalid argument (code=22)\n
Tue Jan 16 19:49:43 2024 daemon.err ovpnclient[26183]: write to TUN/TAP : Invalid argument (code=22)\n
Tue Jan 16 19:49:44 2024 daemon.err ovpnclient[26183]: write to TUN/TAP : Invalid argument (code=22)\n
Tue Jan 16 19:49:45 2024 daemon.err ovpnclient[26183]: write to TUN/TAP : Invalid argument (code=22)\n”

I’ve googled “write to TUN/TAP: Invalid argument (code=22)” but have not yet found anything useful.

Can anyone point me in the right direction?

Here’s my ovpn file contents (with IP address removed):

client
dev tap
proto udp
remote xxx.xxx.xxx.xxx 12974
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
cipher AES-128-CBC
comp-lzo
verb 5

I’d use Meld (F/OSS; WIn, Linux; Mac via Homebrew) or Beyond Compare (30 day trial; Win, Linux, Mac) to compare the troublesome conf against one of your ‘known good.’

Off topic but still related: OVPN?! Really? WireGuard, man… WireGuard.

https://meldmerge.org/

Working with tech support, we figured out that the ax1800 does not support TAP - only TUN. Thanks for the reply.

Wait, what, why does it not support TAP, I only bought the GL-AXT1800 because it SAID it DID support TAP, now they are saying it don’t? FYI WireGuard sucks in so many ways I can not count how many on my fingers… one and the big one, you can not be on the same local network. I have programs that REQ that both sides be on the same subnet. So WireGuard is no better than a OpenVPN TUN! If you can explain to me how to get it on the same network, then I might change my mind, but till then…

Do you understand the meaning behind the abbreviation ‘VPN’?

You blame WireGuard when you should be blaming poorly coded & restrictive apps. File a report on whatever buglog those craptastic devs use.

The router does support TAP TAP-S2S or TUN - GL.iNet Router Docs 4

This works with both the server and client router are GL routers. If you use other routers, that may not work.

The reason is that TAP mode, although called OpenVpn bridge mode, only bridges the vpn client (aka the vpn client router or your windows if you configure tap on your windows) to the vpn network. While in the router scenario, you need to bridge all the client devices under the vpn client router to the vpn network, which needs to be supported by both the vpn server and client.

Do you understand the meaning behind the abbreviation ‘VPN’?

Do you understand that a TUN VPN uses a 2nd network address IE: 10.10.1.1 => 10.10.5.5, and bridges the 2 together to access one another. A TAP VPN tunnel connects it via MAC to the network so that it can get DHCP from the other network, thus being on the same subnet / network IE: 10.10.1.1 => 10.10.1.2. For Most things TUN works great! However some devices, require it to be on the same Subnet / Network for it to function correctly with other devices.

You blame WireGuard when you should be blaming poorly coded & restrictive apps. File a report on whatever buglog those craptastic devs use.

One good example is HomeRUN TV devices. Yes, it may be poorly coded, but at the same time, the nature of the device makes it hard to NAT / TUN it needs to be direct 1 to 1.

The router does support TAP TAP-S2S or TUN - GL.iNet Router Docs 4

TAP-S2S is not true tap then, true TAP should be able to connect to any other tap devices. IE the way OpenWRT does. I am not buying 2 crappy routers, when I have a professional firewall / VPN Router on the other side. All routers should be able to connect to one another, especially if they are both OpenVPN protocol. Guess I will have to buy another mini router, and install OpenVPN with True TAP ability. Not the best solution, but looks like its going to be the only solution. Or OpenWRT Pi

Yeah, IDK man… it seems to me a WG S2S & some table mangling could solve a lot of what you’re stuck on. WG isn’t exactly “plug’n’play” regardless of how well GL automates some aspects for you.

There’s no way I’d deploy OVPN. It’s a dead tech. Obviously YMMV.

(You should get on those dev’s asses, thou. That’s just bullshyte they’d leave it like that.)