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

[jdub]

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.

2. 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.

[elorimer]

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.

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.

[SmurfonToast]

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

[elorimer]

@SmurfonToast

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.

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.

[SmurfonToast]

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

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

cheers

k.

[jdub]

@elorimer

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.

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

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.

[SmurfonToast]

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

k.

elorimer is on it

Use OpenVPN on a GliNET device to VPN into Merlin Router as Server?

[elorimer]

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

[SmurfonToast]

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?

[jdub]

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)

[elorimer]

But then how can the gateway be 192.168.0.1?

[jdub]

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

[elorimer]

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.

[elorimer]

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.

[SmurfonToast]

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.

[SmurfonToast]

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

k.

[SmurfonToast]

Ok so I tested it at lunchtime, two different Wi-Fi hotspots, one with and one without a captive portal … and both Work!!

So it seems like the Airport Wi-Fi has some other setup or routing which prevents OpenVPN over the Slate AX; noting that it doesn’t prevent it over a direct connection to that Wi-Fi …???

[SmurfonToast]

No Biggie, but if that TraceRoute I did above can tell us (GLiNET) what it is the Slate AX OpenVPN implementation is “not” doing, that the OpenVPN implementation direct from phone manages to do (to make the up/down connection work) it’d be a good step forward.

k.

[jdub]

No Biggie, but if that TraceRoute I did above can tell us (GLiNET) what it is the Slate AX OpenVPN implementation is “not ” doing, that the OpenVPN implementation direct from phone manages to do (to make the up/down connection work) it’d be a good step forward.

It’s possible that the issue isn’t actually related to the the particular implementation at all.

Spitballing:

As elorimer noted, it’s odd that your router got a 192.168.128.X address, but the gateway was 192.168.0.1. This seems to imply that particular network is configured as a /16 (meaning all 192.168.X.X addresses). Again as elorimer notes, there’s no good reason to do this, but some admins like to space out their address space, even though it’s not great practice (I actually run a /18 at home and work).

If that’s the case, then the network you were connecting to would be a superset of all the other networks you’re trying to connect to, and it’s very possible that things got weird. The screenshots you posted later seem to show a more sane architecture (192.168.100.0/24), which lies outside any of the networks you’re going to be connecting to.

As a sidenote, this is a large part of the reason I always change the LAN IPs on travel routers to some random /24 or /25 in the 10. space. You’re far less likely to connect to a network where that is going to be an issue. Many years ago when I started using travel routers, I ran my home network in the 172.20.X.X space, which coincidentally is the address space that a large hotel chain uses for their guest WiFi at many of their properties. Moving to something random (e.g. 10.45.45.0/24) makes this a non-issue.

[elorimer]

According to that tracert, from the Slate Lan, you went to what is likely the default gateway on some other router (192.168.0.1, which we saw before) and then to another private ip address (the 172.16. address) and then out to the internet. No tunnel at all.