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