Server IP of the VPN endpoint not reachable


I have an issue with the VPN client of my 750S. This is the scenario:

My OpenVPN and Wireguard Server has the public IP address

Beside the VPN endpoints there are other services running on this public IP as well: eMail, a couple of websites (the IP is the entry point of my Webproxy) and so on.

The big issue is: When the 750S has an active VPN connection to my server, routing all the traffic through it, all clients behind the 750S can’t access any services which are using the same IP address! Even pinging from any client behind the 750S does not work!

This happens if the OpenVPN client is used as well as if I’m connecting via Wireshark.

When the 750S does not create the tunnel but any devices behind the 750s (PC, iPad, iPhone) they all can also access all services on the same IP as the tunnel endpoint without any issues!

It appears as if the 750S blocks all traffic which is addressed to the same IP as the VPN server. This is a showstopper for me!

How can this be solved?

It sounds like this is a VPN endpoint that you control. Do you have this OpenVPN server behind a firewall like pfSense? If so (or even if you don’t, this could provide some insight), you might want to read this article about “hairpin NAT”.

Yes and no.

Short version: Yes, all VPN servers are controlled by me. But one of them is a VM with a direct public IP address on my server in the datacenter. No Firewall, no NAT in front. It’s the same: The clients behind the 750S can’t reach or ping the console / webinterface of the server itself!

Long version: The one at home is indeed pfSense, VPN listening on the WAN interface (fixed IP) and hairpin is configured. Also as written before: When a device itself makes the tunnel and not the 750S, it can access also the services on the same IP as the VPN server itself. So hairpin is working pretty well here.

Another information: From the SSH of the 750S itself the IP is reachable and pingable! Only the clients on the LAN side can’t reach this IP! Is there a firewall rule missing by default in the GL.Inet-Devices?

Some more information:

When I set this firewall entry from “reject” to “accept” I can ping the IP of the VPN server from the clients:


BUT: It’s not routed via the VPN tunnel then, but directly via the gateway of the WAN where the 750S is attached to. Also I don’t like to have an uncontrolled common “accept” for forwardings.

Second, as this is not routed via the VPN with the global “accept” I’ve checked the routes. It creates a direct route to my VPN server for the “wlan-sta” interface, using the uplink gateway of the network where the 750S is attached to:

The IP behind the purple box is the public IP of my VPN server where the 750S tunnels to. Not sure what’s the reason for this special route …

My OpenVPN and Wireguard Server has the public IP address

… huh? (That’s a non-routable IP block)

This is not the real IP of course :wink: @kennethrc

So, meanwhile I’m convinced the GL-Inet firmware part does some “special firewall config” in V3 here. Can you please help @alzhao @kyson-lok as I start my travel on Friday and need a solution?

Somewhere the router blocks the route from the LAN clients to the IP of the VPN server via WAN!

When I go to LuCi: “Network” → “Firewall” → “Traffic Rules” and create a rule:

Any Traffic
From any host in lan
To IP: in WAN
→ Accept forward

My LAN clients can reach the IP of my OpenVPN server (of course not via the tunnel) … that’s the behaviour I had with my AR300M in the V2.x firmware and this is fine.

When I disconnect and reconnect the VPN connection in the GL-Inet interface, the rule is not working again! So it seems, although my rule is still visible and active in LuCi, any config change in the GL-Inet interface seems to “override” / overwrite my rule again :frowning:

When I go again into LuCi and make a “Save and Apply” on the Traffic Rules page my added rules are working again.

In “Custom rules” right at the end I see the line “gl-firewall” and I have no clue what this is doing … maybe it’s causing this issue.

Please kindly check your firewall addons @alzhao @kyson-lok and ensure than the LAN clients can communicate with the endpoint IP of the VPN servers where the GL-Inet device is connected to. Any quick workaround is highly appreciated, going into LuCi after each restart of reconnect to activate my custom rules is not acceptable.

Something bad happened here between the V2 branch and the V3 branch …

PS: is just a placeholder for my real IP of my VPN server :wink:

It is easy to fix that.

For Wireguard, edit the file /etc/init.d/wireguard, and search lan2wan_forwarding, change “lan2wan_forwarding disable” to “lan2wan_forwarding enable”.

For OpenVPN, edit the file /etc/init.d/startvpn, the modification is same as WireGuard.

@kyson-lok Awesome, thank you very much! :blush::+1:t2:

I guess this opens LAN2WAN traffic in general, also when the VPN is down? Is there a plan to add an option that only the traffic to the VPN server’s IP is allowed via direct LAN2WAN in future firmware versions?