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

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:

I am not following at all where the 192.168.128.252 address is coming from.

It showed up on the GLiNET Admin Page (see picture above), just above the gateway. I am hazarding a guess it’s the IP assigned by the Wi-Fi I am repeating?

elorimer said:
I am not following at all where the 192.168.128.252 address is coming from.

It’s the remote LAN address that the Slate AX is connected to (i.e. the Slate’s WAN address)

But then how can the gateway be 192.168.0.1?

Probably because they have it configured as a /16 or something (even though they probably shouldn’t).

The ping shows 100% packet loss to the default gateway. If it really is /16 then that AP is trying to handle 16,000 devices. Something is very wrong.

Perhaps turning off the VPN entirely, and doing a tracert to 8.8.8.8 would show what is going on.

Okay, I connected my Beryl to a wifi hotspot outside the house, and my OpenVPN client connections to my home server worked perfectly, both for accessing the lan and the internet in split and geolocating modes.

I’ll have to wait on a 4.0 device to look at this again.

Here it is, hope this means something to you :-). I had a few tries, never used tracert before and my fat fingers struggled with iterminal on the iPhone, hence the aborted attempts…

I tested it again at work today btw no joy.

I will take the SlateAX to a coffee shop at lunchtime and see if I can run it off a battery and get some joy out of it. The snapshot FW was recommended by GLiNET for an issue I was having with it constantly rebooting when connected in repeater mode to 5G networks, it fixed that issue I think, although does not affect this scenario anwyay, as it connects at 2.4GHz.

p.s. re the 16,000 devices, the Wifi is at an Airport, do you think this is by design i.e. trying to cater for masses of people?

k.

Thanks elorimer, appreciate you doing this test, I will do my own at a new hotspot, as noted below.

Are you going to wait for their “new” travel router or go with the “hot” Slate AX? At first glance (and this may be slightly unfair), looking at the number of models and the comments here, it seems they seem to going for planned obscelence faster fixing than the S/W :slight_smile:

k.