The closest relevant information I’ve found on the error is this: " This error doesn’t really mean much on its own. The exit code of 2 simply means the kernel rejected your route for some reason. It could be because you already have a route for that network, it could be because the gateway was not appropriate for the network/subnet, or many other things.
In any case bump up the verbosity you should be able to see more details about what specific route was failing.
Depending on the error you may need to fix your configuration, or just ignore the error. Sometimes the vpn server will offer routes, that your computer already has, or do not apply to your current connection."
This was relating to pfsense so I’m not sure if there is a way to get a more detailed log to see which route is failing.
I took a testing on Slate (firmware 3.212) with Home TP-Link OpenVPN server(Archer C3150). Works fine.
Make sure you selected Internet and Home Network
Ugh. It looks like the Omada is not well suited to your purpose. I don’t see that there is any alternative firmware for you (DD-wrt, openwrt, tomato), and I don’t see hooks for you to ssh into the router and monkey with stuff with scripts.
Plan A would be to get a different router, plan b would be to try within TP Link support to see what can be done.
What you want to do I’ve done with little difficulty with five different Asus routers over the last 12 years, but they each supported gobs of customization ala openwrt.
Mango 3.212 snapshot; Beryl 3.212 snapshot; Not affiliated with GL-iNet–just a user
You can look into getting another TP-Link wifi travel router to replace the Slate as OpenVPN client to your TP Link Omada ER605. Confirm with TP-Link on which models are “guaranteed” to work.
I do not work for and I do not have formal association with GL.iNet
You may be right, but I still think the problem is with the Omada. It doesn’t have the button that would otherwise do what he wants. I think he should be ditching the Omada for something else.
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
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.
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.
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.
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.
