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 10.20.30.40
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 10.20.30.40! Even pinging 10.20.30.40 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!
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”.
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?
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:
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: 10.20.30.40 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.
BUT:
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
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: 10.20.30.40 is just a placeholder for my real IP of my VPN server
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?
