Slate AX does not duplicate opvn behaviour for Windows/iOS based solutions?

Sorry to refer to an old thread, but I believe I have a similar issue with a Slate AX as I believe these folks had with other GLiNET devices.

The old thread is this one:

I have an ASUS RT-AX86U at home with an OVPN Server on it (using Merlin FW). I exported the opvn profiles to a Windows Notebook and my iOS devices and can access my home PC with no issues. It works fine with those devices and the remote desktop software and app.

I thought I could just import the opvn profile into the Slate AX and it would duplicate (mimic) the Windows and iOS based behaviours. Unfortunately it does not, the OpenVPN Profile connects just fine, but when I try to use the RDP s/w or App it does not connect to my home PC. In the RDP App I just get “Unable to Connect” and an error code 0x300005e. In the Windows App it is a similar message.

I am not technically sophisticated enough to understand what is in the openvpn file but the thread above suggests to use a “domain/IP based policy”. I am not sure where this setting is on the VPN Server (but will look for it), but I don’t understand why I would need to change anything at all, if the exported ovpn profile is exactly the same for Windows, iOS and for the GLiNET Slate AX?

Other threads I looked at, re openVPN with GLiNET devices:

Thanks!

k.

Just FYI I gave up on openvpn altogether and switched to wireguard. The convenience of running the vpn server on my router was nice, but setting up wireguard on a pi on my home network was fairly straight forward, and I haven’t had any issues since.

I want there to be a solution for you, because you are a kindred spirit! I’ve just come off two months away with a Beryl (on 3.215b1 snapshot), connected 24/7 to my Asus AC86 (on Merlin 386.5_2) for split tunneling, using the same profiles for the Beryl and windows/ios/chrome devices. So pretty close to your situation, except a different router, in a different place, with different software.

  1. Entirely off topic, but you should think about trying wireguard instead. You have a quad core crypto beast in the ax86 on the home side, and a quad core beast on the travel side, so you should be able to do 4x better throughput with wireguard. I assume you have amtm running and there is a slick add-on for it.
  2. The windows pc works, so there shouldn’t be a subnet conflict in play here. I’m assuming the Slate AX lan subnet is at 192.168.8.x and that doesn’t figure anywhere along the chain.
  3. Just to be clear and perhaps help others thinking of a solution, I assume that you are only trying to access your home local network over the tunnel and not the internet over the tunnel. This is split tunneling and controlled on the server side in merlin by “both” or “lan” setting. The latter adds a route to your home network, and the former does that but also changes the Slate’s default gateway to go over the tunnel. This can be changed on the client side, and it could be the Slate is doing something here that overrides that. That is the reference to domain/ip based policy.
  4. There is in the 3.xx software a switch to “access local network”. I’ve never been clear, tbh, whether that allows the server to access the travel router’s network, or whether it allows the travel router to access the local network to which it is connected, or to access the local network of the server. But you might switch that on and see if it changes something. Can’t hurt.
  5. Be mindful of whether you have two client devices connected to the same VPN Server at the same time with the same profile. It works fine, but you may have to add two instructions to the VPN Server config.

This is almost certainly a routing issue.

A quick thing to check would be to make sure your OpenVPN file includes the line

redirect-gateway 1

Depending on your Asus setup, you may have a new problem after you do this which is that you can access your home network, but not the rest of the internet (because the ASUS router now gets the traffic from your AXT1800 but doesn’t know where/how to forward it).

As an aside, using Wireguard doesn’t really solve these problems on its own. You still have to make sure your routing is set up properly or traffic isn’t going to go where you want / expect it to. My personal opinion is that OpenVPN is actually the easiest of the three major platforms to route in complicated setups, though the others (Wireguard/IPSec) can be easier in certain situations.

Not this, I think. If the server is pushing a route add command, which it seems to be doing, then the Slate will know that requests sent to the home LAN go down the tunnel, and the server will know to route those requests to the home LAN.

The default gateway gets requests that the Slate doesn’t know how to handle. If the redirect-gateway is used, then it will send unknown addresses down the tunnel, and so access to the internet will be over the tunnel. Without it, the Slate will route unknown addresses to its default gateway, so they won’t go down the tunnel.

But yes, a routing or firewall issue.

Not all implementations handle the push routes correctly (here’s looking at you, mikrotik). I agree that a standard compiled version should, but I wouldn’t take it for granted.

That said, I wouldn’t be confident at all that a masquerade route is being added for clients on the LAN. I suspect the push route works properly on the Slate, but traffic isn’t being forwarded from the LAN interface. Running a redirect-gateway is sort of a sledgehammer approach to seeing if that’s the problem.

Though in thinking about it a bit more, if the LAN forward route isn’t set up it won’t matter. Disregard everything I said!

Hi jdub,

Thanks for your input here, much appreciated I will reply in mire dteail to elorimer’s post as well.

My openvpn profile redacted (as below) and without the actual cert and key details. I am not sure if this tells you anything, but you seem to have gone off the idea anway :-).

# Config generated by Asuswrt-Merlin 386.7, requires OpenVPN 2.4.0 or newer.

client
dev tun
proto udp
remote xxx.myipaddress.xxx.com 1194
resolv-retry infinite
nobind
float
ncp-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC
keepalive 15 60
auth-user-pass
remote-cert-tls server
<ca>

Hi nso,

Thanks for the reccommendation, I did look at Wireguard and it is on my “wait patiently” list for “down the track”, for use between the two Routers (my ASUS RT-AX86U and my GLiNET Slate AX), when Merlin supports it natively on the ASUS Series of Routers; which I understand Asus will do/are doing already with the 386.8 stock FW on “certain devices”.

I only have Diversion installed (w/o any entware packages) as I am a sort of low-power-follow-instructions-type-of-user, and I like to keep scripts to a bare minimum. I have a RPi4 I could set up but I really wanted to keep VPN management to the Router; it works well via other devices … just not via the Slate AX unfortunately!

k.

For auth-user-pass you’re going to need a password file on the Slate AX. See mine ovpn config generated from pfSense below (might SSH into your router to see if the user/pass gets added):

dev tun
persist-tun
persist-key
data-ciphers AES-128-GCM:CHACHA20-POLY1305:AES-128-CBC
data-ciphers-fallback AES-128-CBC
auth SHA256
tls-client
client
resolv-retry infinite
remote server.ip.address 443 tcp4
nobind
verify-x509-name “SERVER.FQDN” name
auth-user-pass /etc/openvpn/profiles/8229/auth/username_password.txt
remote-cert-tls server

Also, I don’t think you need float there, but it probably doesn’t hurt anything.

A couple of extra questions:

  1. Are you able to ping the remote end of the tunnel from the router?
  2. Are you able to ping either side of the tunnel from a client on your LAN?

I also will note that my client config doesn’t have redirect-gateway enabled, which … well, happens. Which suggests to me that GL-iNet may be doing it by default. If you’re trying to split-tunnel (and your ASUS isn’t set up for it) that could be part of the issue.

First up, to all of you, just wow and thank you for giving it a whirl to help out here, very much appreciated.

I am as I noted a fairly “low-power” user, pretty good at following instructions but not super-techy beyond that, just wanting to mimic my current working VPN.

  1. Re Wireguard, see my note in the response to nso above. It is on my list, just not right now. OpenVPN really “should” work. I don’t actually have amtm running, but I do run Diversion Lite.

  2. Yup, I specifically left the subnet at 192.168.8.x.

  3. Yup, I am only trying to access my home local network over the tunnel and not the internet. Double checked the OpenVPN server in my Router at home, it says “LAN Only”. Presumably I do not need to change anything in the Slate settings for them to talk to each other?

  4. I checked that Access LAN settting. It was on, but I tried with it off as well, still no connection via RDP. I turned it back on.

  5. Okey Dokey. Fiddling around yesterday I seem to have added via the App, a second VPN configuration file, called app_custom_MyVPNProfile (I think I added it via the GLi App); whereas the one I added via the WebAdmin is just MyVPNProfile_client. But I can’t seem to find a way to delete the former profile (in the App), would you have any ideas how to get rid of that?

Routing likely, but ff this was the case for the firewall, is there a reason it would work with the current setup but not this one via the SlateAX?

Thanks once again, very much appreciate all your help. I guess I am a little frustrated that what I thought would be a relatively simple “out of the box” solution has taken on a lot more steps than I anticipated. If we get to the bottom of it though (it cannot be far off!) hopefully some other folks will benefit too, if not in changes, then in documented steps.

cheers

k.

Hi jdub,

Uh oh…I’m starting to get way out of my depth here…

The ovpn file has three sections
“ca>”
-----BEGIN CERTIFICATE-----
…Bunch of Gobbledygook…
-----END CERTIFICATE-----
“/ca>”

“cert>”
-----BEGIN CERTIFICATE-----
…Bunch of Gobbledygook…
-----END CERTIFICATE-----
“/cert>”

“key>”
-----BEGIN PRIVATE KEY-----
…Bunch of Gobbledygook…
-----END PRIVATE KEY-----
“/key>”

I was assuming this is where all the password stuff goes?

re your questions:

  1. I know how to use ping, but I don’t really know what (which address) to ping?
  2. I don’t think I can do this remotely, so will need to try that from home. Am at work.

I don’t think I am split tunelling, if the setting is “Lan Only”, would that be correct?

k.

A couple of answers for you:

  1. “Split tunnelling” refers accessing the openvpn server’s lan over the tunnel, but accessing the internet over the Slate’s own internet connection. It happens because the server pushes a route to its lan to the Slate, so if a PC on the Slate’s lan wants to go to 192.168.50.xx (this being the openvpn server’s lan), the Slate sends it over the tunnel. But if a PC on the Slate’s lan wants to go to www.nytimes.com, say, the Slate doesn’t know how to get to that address, so it sends it to its default gateway, out your ISP and not over the tunnel. If you set your ax86u to “both” or “internet”, the openvpn server would push a change in the Slate’s default gateway to the tunnel, and internet requests would go over the tunnel. Sometimes this is a good idea (geolocating), but generally it would be slower. The problem that comes up is that a user with split tunnelling doesn’t immediately know that the tunnel is working or not.

  2. OpenVPN allows three patterns of client authentication: certificate only, user/password only, or certificate plus user/password. The first is secure, the second isn’t really, and the third is slightly more secure than the first and also has some other advantages. The user/password can be included in the .conf file but might be ignored; it might be supplied on the fly and also stored, or it might be supplied in a separate file, which is what jdub is suggesting. The complication is that the GL GUI takes the .conf file and feeds it to openwrt, which stores it in its own fashion. Your Slate AX is a openwrt 4.0 device, and I don’t have hands on with such a thing to know precisely what it does with it. As to that, you might follow the guide here: [OpenWrt Wiki] OpenVPN client using LuCI

  3. You want to ping each address along the path to your ax86 LAN.

elorimer said:
The complication is that the GL GUI takes the .conf file and feeds it to openwrt, which stores it in its own fashion. Your Slate AX is a openwrt 4.0 device, and I don’t have hands on with such a thing to know precisely what it does with it.

Basically it copies it to the /etc/openvpn/profieles/****/ directory, where **** appears to be a random 4-digit number. It then creates a auth/username_password.txt file underneath the directory and appends/replaces the auth-user-pass line to include the location of the auth file. As well as doing all the UCI stuff.

SmurfGliNET said:
I was assuming this is where all the password stuff goes?

No - elorimer’s explanation was perfect. The < ca>, < cert>, and < key> sections (there are other options like < tls> or < tls-crypt>, for example) contain certificate or key information that, in very simplified terms guarantee the identity of the machines. As they also mentioned, OpenVPN (though not GL-iNet’s implementation, I think) allows you to do a certificate-only based connection, which is typically used in site-to-site applications. The fact that your config has a “auth-user-pass” line along with the certificate information indicates that you’re using user authentication.

If you note in the configuration snippet I posted, the auth-user-pass line has file location after it - I should note that this is the configuration file as it exists on my Slate AX, not as it was generated by my VPN router. So I suspect yours has that appended as well.

  1. I don’t think I can do this remotely, so will need to try that from home. Am at work.

Just so you’re aware, you can get some weird stuff happen when you try to debug situations like this from behind the router you’re trying to connect to, for reasons I really don’t want to go into. I usually end up using a spare router to tunnel everything out to somewhere else and then have the router I’m debugging connect back in from that endpoint. That may not be practical here. Anyway.

  1. I know how to use ping, but I don’t really know what (which address) to ping?

So I’m going to make up a bunch of numbers here to give you an idea of the structure, and you’ll need to change them as appropriate.

Home network: 192.168.1.0/24 (the router will generally be 192.168.1.1)
Slate AX network: 192.168.8.0/24 (default with router at 192.168.8.1)
Tunnel network: 10.8.0.0/24 (for our application, home router will get 10.8.0.1, Slate AX 10.8.0.2)

So in the example above, you’re trying to connect from a computer in the Slate AX network to a computer in the Home network. For giggles, let’s say your laptop on the Slate network gets the address 192.168.8.100, and the computer at home is 192.168.1.50.

There are a few things we can try to do to debug the connectivity using ping and traceroute (tracert on windows)

So in theory, the path that the traffic should take would be:

192.168.8.100 → 192.168.8.1 → 10.8.0.2 → 10.8.0.1 → 192.168.1.1 → 192.168.1.50

The shoot-the-moon approach would be to ping something from the Slate AX network that you know is reachable on the other side and have it respond (ping 192.168.1.50). (Sidenote: I would temporarily disable your firewall on your “192.168.1.50” machine for debugging purposes). If that works, then your problem is likely a firewall issue on the 192.168.1.50 computer - probably that it doesn’t like connections from what it thinks is a foreign subnet.

From there, I would start walking back along the chain and figure out where things break - every “break” has a different problem/solution.

Again, your numbers above are probably going to be different, but hopefully that gives you an idea of what you’re looking for. The VPN tunnel addresses are going to be something you’ll probably find in the ASUS OpenVPN configuration.

If you can SSH into the router (via Putty, similar), executing the pings above can also give you a good idea of where things may be breaking down - e.g. if your router can ping 192.168.1.50, but 192.168.8.100 can’t, that’s a good clue that you’ve got a problem on the Slate AX side of things.

Let us know if that helps / what you find out.

Hmm. I pulled my Beryl out of its case and had a go at this, from within my AC86 home lan [so, completely invalid for anything!!].

I used my Openvpn client .conf file within the GL-inet GUI, successfully made the connection…and was not able to reach my local network. So I deleted it, and followed the Luci steps I noted earlier, successfully made the connection, and was now able to reach my local network. :grinning: :dizzy_face:

So I’ve replicated your experience and a possible solution. You might try it…I’ll have to get out of my basement and get a cell signal to verify it works in a proper fashion, and if so we can move on to why the GUI is having an issue.

You guys are fabulous, thank you. I feel a wee bit embarrassed to have dragged you into a discussion where you clearly know what you’re talking about and I’m struggling to keep up.

@ elorimer that’s a great explanation of split tunneling very succinct.
I’m loathe to go the Luci Route for the OpenVPN connection for the moment, it’s daunting but doable, but ultimately in my view GLiNET should be sorting this out, given they are selling a unit based in its promised ability to run opvn.

@ jdub I’ve used WinSCP before so might have a look inside that dir. I can only do this from home, to date all my trials at work are from iPhone.

I’ll test ping from work using a terminal App on my iPhone (can’t believe I’m writing stuff like this :-), my inner geek).

Might need some time.

Cheers

K

Give it a try if you can. I think you may have stumbled on something and the more specific we can neck it down the faster GL-iNet can replicate it and fix it. In a way the users here are helping other users, to free the factory up for the things only they can improve.

I’m totally jealous that you have quad core routers on both ends. Use amtm to install wgm on your ax86 and I bet you can get to 500gbps through your tunnel.

Hi jdub.

It certainly helps. I didn’t turn off the firewall at home (maybe my next try) as it’s tricky to navigate the Windows PC from an iPhone. Doable, but tricky.

Using your excellent example above (see pics) I believe I am going this path?

192.168.8.144 → 192.168.8.1 → 10.8.0.2 → 10.8.0.1 → 192.168.1.1 → 192.168.1.10.

or maybe it is this one, see pics below?

192.168.8.144 → 192.168.8.1 → 192.168.128.252 → 192.168.0.1 → 192.168.1.1 → 192.168.1.10.

So, ignoring the first two hops (jargon) as I am 192.168.8.144 and and I connected to 192.168.8.1, results for rest are like this (with opvn running after it says connected in the log and success in the error message):

192.168.128.252 = OK, 0% Packet loss
192.168.0.1 = NG, 100% Packet loss
192.168.1.1 = NG, 100% Packet loss
192.168.1.10 = NG, 100% Packet loss

10.8.0.1 = OK, 0% Packet loss
10.8.0.2 = NG, 100% Packet loss
10.8.0.3 = OK, 0% Packet loss

I do not know why the first and third worked but the 2nd didn’t .The pic shows the virtual IP to be 10.8.0.3, I asume this was what you meant above?

I guess I could have stopped at the Wifi’s Server as this seems to be the stoppage point (using the Slate AX, but not using my phone.






I then tested pinging my home PC after connecting directly with my phone, and it’s fine; 0% packet loss, see pic. So that works fine, firewall or no firewall.

Also, just for kicks, I connected to my homePC via my Iphone-based OVPN Tunnel while I was connected to the Slate’s Wifi, with it working as a repeater and it works just like the direct connection (to the same wifi), which is probably not surprising.

Not sure what to do with this info :slight_smile:

Hope it is useful! The guys at work are looking at me like I am somewhat unhinged …

cheers

k.

Eh. Quad-core ARM/MIPS is lightweight. Just grab a Xeon-D off eBay or a fanless 1165G7 off AliExpress and don’t worry about encrypted bandwidth for the foreseeable future. 500mbps is easy :slight_smile:

SmurfGLiNET said:
many things

Ok. Interesting.

The path is the first one, except 10.8.0.3 rather than 10.8.0.2 (probably because your iPhone or something else got assigned 10.8.0.2 - not a big deal). The other addresses (192.168.128.252 and 192.168.0.1) are related to the network that your Slate AX is connected to. The VPN tunnel creates a kind of fiction where you don’t really see any of the addresses between the two tunnel points, even though there are a lot. You just see the tunnel entry point (10.8.0.3 in your case) and the tunnel exit point (10.8.0.1 in your case).

Just to confirm what I think you’re saying, you are able to ping 10.8.0.1 (0% packet loss) but not 192.168.1.1 (100% packet loss) from a device connected to the Slate AX, correct?

If that’s the case, it feels like the problem is actually on the ASUS Merlin side, not on the Slate AX. Said differently, 10.8.0.1 is the OpenVPN address on the ASUS, and 192.168.1.1 is the main router address on the ASUS, so it looks like something (firewall or routing) is blocking the transition from OVPN to LAN on the ASUS. I’m not super familiar with how Merlin implements things, and I think I’ve thrown away all my routers that are compatible with that firmware, though I may have one up in an attic somewhere. It does sound like elorimer may be more helpful than me there.

Just to confirm what I think you’re saying, you are able to ping 10.8.0.1 (0% packet loss) but not 192.168.1.1 (100% packet loss) from a device connected to the Slate AX, correct?

Correct. Okey Dokey I’ll hit up the guys at snbforums to see if anyone else has such an animal. Thanks :pray:

k.

elorimer is on it :+1:t3: