Successful VPN Server and Client (GL.iNet; WireGuard), TLS Handshake Fail on Company VPN

Sorry, repeat? Means that the Windows OpenVPN GUI (directly) can connect to your company OpenVPN server?

When I connect my Windows PC to the GLi.Net router acting as a WireGuard server directly via wifi, and do not use another router as a client, I can then connect to the company OpenVPN with my Windows PC.

But when I connect my Windows PC to my GLi.Net router acting as a client, which is connected to the GLi.Net acting as a WireGuard Server, I can only access the internet, and there is a TLS handshake failure when trying to connect to the company OpenVPN.

Is that your VPN network road?

PC (Open VPN Client) -> E750 (WG VPN Client) -> Internet -> ISP Modem -> AR750 (WG VPN Server) -> ISP Modem -> Internet -> Company -> Open VPN Server. Not works?

PC (Open VPN Client) -> AR750 -> ISP Modem -> Internet -> Company -> Open VPN Server. Works?

PC (Open VPN Client) -> E750 (AirVPN Client) -> Internet -> AirVPN Server -> Company -> Open VPN Server. Works?

Could you please check if is the E750 WG Client -> AR750 WG Server working well? like ping the AR750 server IP in the E750 SSH.

Correct. I just tried to ping the AR750 server internal IP with the E750 client, and there was 100% packet loss! Any recommendations on how to fix this?

I believe you should be fine as long it is /24 and even with /16 still, with /8 you would go into issues, but only if the routing went wrong, since they are virtual ip most of the time if the routing is properly it should be not a huge problem.

With /24 it is - inclusive broadcast, gateway ip and host address.

With /16 it is -

and with /8 well i think you see where im going :slight_smile:

make sure the default route is unchecked on these vpn interfaces, luci -> network -> interfaces -> vpn -> advanced tab -> default gateway checkbox, otherwise it could indeed be possible one vpn sees your other vpn as wan gateway, and since both gateways probably listen aswell on that can give issues you surely dont want to overlap gateways this way ! :slight_smile:

Thank you for the response. I updated the server to a 172.x.x.x address so the problem shouldn’t exist now (if it did in the first place). Still can’t get the connection!

Is there are a chance you could show the result from ip route from the command line by logging in through putty?

here it is:

root@GL-E750:~# ip route show
default via dev wlan-sta0 proto static src metric 20 dev wgclient proto kernel scope link src dev wlan-sta0 proto static scope link metric 20 dev br-lan proto kernel scope link src

I can ping a website with my GL.iNet router acting as a client, but can't ping my server. Do I have to enable something on my server?

Do you want to ping the vpn server's public IP or local IP?

Did you enable this option in the server?

I was trying to ping the internal IP address as someone asked me if I could earlier in this thread. I have enabled "Remote Access LAN" on the sever, but the request times out when I try and ping it with the client. I am able to ping the public ip.

Any other suggestions on how I can allow my client to ping my server? Once it can be pinged, should that fix the issue with OpenVPN not connecting?

So in addition to enabling “Remote Access LAN” on my server, I also went into LuCi and changed zone forwarding wgserver to accept forward (LuCi > Network > Firewall > General Settings). Still can’t ping from client to server internal IP nor get the OpenVPN connection. Anything else I should do in LuCi, or perhaps configure on the client?

Boom! This was the fix! Thank you. I tried it on both my client and server at different times, and each one fixed the issue. Ultimately will keep the setting on my server. Didn’t try this at first because I couldn’t find “vpn,” but the pay was “luci > network > interfaces > lan > advanced tan > default gateway checkbox.”

Couple questions if you don’t mind. When I unchecked the box in the client it said there were 6 changes to be made, and when I reverted and re-checked it said there was 1 change to be made. Is this something to be concerned about? Any changes I need to fix? (After reverting the changes on the client, I then unchecked the box on the server, which said there were 5 changes to be made).

Additionally, when I am connected directly to the server via WiFi (with no client), I can no longer access the internet. Not that big of a deal since I set up the server to access with a client, but how do I get internet access back?

1 Like

This is hard to know, usually the checkbox takes one change, but perhaps you had a concurrent change and then i don't know what has been changed there.

My suspicion is that the default gateway checkbox has to be enabled on lan, lan is kinda a special interface usually if i had this unchecked things didn't work correctly.

Then secondly is the cascading option enabled inside vpn dashboard ?

If it still doesn't work, then my suspicion is tweaking the mtu of the client, the server should be 1420, the client should be stable at 1384, but you can always lower it on the client but first try it with these :slight_smile: