I don’t think any of us knows what the problem is yet. It may not be about a “button” because ithe Omada router works using the same config on the Windows and Android client:
I see other threads on this forum with users having problems with OpenVPN that may be due to configuration and/or software. Maybe TP-Link can provide a solution that just works with their own router or another brand … very easy to ask them.
I do not work for and I do not have formal association with GL.iNet
Yes, but that may because of split tunnelling–I don’t think we heard how the tracert came out, did we?
That’s my point when I stated that I don’t think any of us knows what the problem is yet … only conjectures. I also stated “It may not be about a “button””.
Is it bad to ask TP-Link for information?
I do not work for and I do not have formal association with GL.iNet
Please try WireGuard.
Connect the WAN port of Slate to the LAN port of TP-LINK Omada, then set port forward on Omada. WireGaurd use port 51820 by default. Set Slate as WireGuard Server.
For your cell phone and PC, just use the official WireGuard app/client.
I think this is the best solution and don’t need to buy a new device.
I highly doubt it’s an issue with my router as it’s designed to do this and, as I have said, it works with both the android and Windows client, just not my Slate. I had listed the results of the tracert, traffic was going to my Slate gateway. I opened a ticket with GL.iNet so I’ll see what they say.
On some of my Ubuntu based VPN servers I use the SoftEther VPN package which provides OpenVPN along with multiple other VPN protocols. I have had problems with some versions of GL iNet router firmware not being able to connect to the SoftEther OpenVPN servers, where Android, Windows 10, Macos, and Ubuntu OpenVPN clients work just fine with the SoftEther OpenVPN server.
I could never figure it out, so I also installed the native OpenVPN package on my Ubuntu servers using the angristan script on a different port, and it works fine with the GL iNet OpenVPN clients, and all other OpenVPN clients. I cannot tell you what it is, but I have definitely seen something similar to what you are experiencing, where the GL iNet OpenVPN client fails, but all other OpenVPN clients work.
Ok, I didn’t see this.
Okay, finally a conclusion for this saga. Thank you to everyone who has commented on this and GL.iNet support was very helpful. Buried deep on the internet and confirmed by TP-Link support, my routers OpenVPN implementation does not allow access to the internet and was indeed using split tunneling.
Here you go:
There is a comment:
In Omada menu there is no option of “Internet and home network Client Access” as it seems to appear in router menu when it is not addotped by Omada Controller.
Did TP Link suggest that you could SSH in to their router and fool with stuff? You can redirect the gateway on the client side as step one.
Yeah, I had came across that exact forum which made me pretty sure that was the issue before I emailed their support. It was like the only mention of it not being a full tunnel, they should probably put it in some documentation somewhere, but that’s beside the point.
Honestly I didn’t even ask. This has been more of a “fun” project for me so I don’t really have a need for it. So I’m fine waiting until they implement it. Just unfortunate that a business class advertised product with “VPN” in the name doesn’t have a better OpenVPN implementation.
Were you able to solve this? This thread is a few months old but I currently have the same issue