OpenVPN: Route to server IP broken

I use the GL.iNet GL-MT300N-V2 with firmware 3.212-0407 in router mode.

Currently, I reside in a hotel with LAN and Wifi connection, and for the better or worse, the MT300N is connected to both, thus having two gateways.

I have configured an OpenVPN client that connects to my OpenVPN server at home. Then, I connect to the MT300N via Wifi from my laptop. This works except for one thing: I cannot connect to all the other services on my home server, e.g. the Web server. In other words, the public IP address of my home server is not routed properly. A traceroute yields:

traceroute to (XXX.XXX.XXX.XXX), 30 hops max, 60 byte packets
 1 (  1.259 ms  1.634 ms  2.117 ms
 2 (  2.083 ms  2.594 ms  2.741 ms

I’m no expert at traceroute but this seems to be a loop.

Note that when I use the laptop to connect to my home VPN, I’ve never experienced such problems.

What I already tried in the OVPN file uploaded to the mini router:

  1. Setting “route <public IP>”, where the latter is the router’s gateway.
  2. Setting “redirect-gateway” (naked and with the def1 option).
  3. Setting “nobind

My OVPN file looks like this:

dev tun
remote 443 tcp

(Then, the key and certificate follow in-file.)

And the server configuration is:

verb 3
key /etc/openvpn/pki/private/
ca /etc/openvpn/pki/ca.crt
cert /etc/openvpn/pki/issued/
dh /etc/openvpn/pki/dh.pem
key-direction 0
keepalive 10 60
mssfix 1200

proto tcp
# Rely on Docker to do port mapping, internally always 1194
port 1194
dev tun0
status /tmp/openvpn-status.log

user nobody
group nogroup
comp-lzo no

### Route Configurations Below

### Push Configurations Below
#push "block-outside-dns"  # Not supported by my client yet
#push "route vpn_gateway"
push "dhcp-option DNS"
push "comp-lzo no"

(Sorry that some things are irrelevant; I wanted to be sure to not miss anything.)

I can’t get beyond your second paragraph. Why are you connected to both the hotel LAN and wifi? If you disconnect the wifi and wire the Mango WAN port to the hotel LAN, does it work?

I connected to both because I could. Does this have a downside?

I now disconnected the wifi but the behaviour did not change.

Yes. Thou shalt not connect two interfaces to the same network. I can’t imagine what state the router might be in after that, and I’m surprised the openvpn client could connect at all.

I would unplug everything, power off the router, plug the wan port of the Mango to the LAN of the hotel, and power on the router and see if it works.

1 Like

Okay, I removed one interface, made a reset and after that even a power restart. But still: Everything is routed properly through the VPN tunnel, except for the VPN server IP itself.

  1. So traffic to the internet goes through the tunnel and out your home internet connection? Not sure I see how that would happen without the redirect-gateway def1 command.
  2. Traffic goes to your home lan machines, but just not to the openvpn server?
  3. What is the openvpn server running on, and is anything on that side 192.168 8.xx?

So traffic to the internet goes through the tunnel and out your home internet connection? Not sure I see how that would happen without the redirect-gateway def1 command.

You’re right, this is strange. I did some research, and when I use my “usual” way to establish a VPN connection (without Mango but with my OS), the redirect-gateway is implicit due to NetworkManager-openvpn always adds default route without asking (#48) · Issues · GNOME / NetworkManager-openvpn · GitLab.

But even with the Mango, yields my home IP address here from the hotel, although I use only the configs cited above.

Does the Mango OpenVPN implementation has some implicit behaviour, too?

Traffic goes to your home lan machines, but just not to the openvpn server?

I haven’t tested other machines in my home LAN (there is only a printer and a Chromecast stick, besides my home server). But I can reach my home server with (its local IP) but not with its current public IP (which changes every 24h).

What is the openvpn server running on, and is anything on that side 192.168 8.xx?

I use the Docker Hub image kylemanna/openvpn, and 192.168.8.xx is not used by anything in my home LAN.

I pasted all VPN-related log that is created by the mini router when establishing a connection at Mon Aug 1 06:45:41 2022 : 1247: gl-vpn-client>> Start, vpnpath=/etc/o -

@hilll can you check this one?

In the OpenVPN server, you can open the button, as follow:

it make the OpenVPN client can access the OpenVPN Server local network server.

for example:

  1. vpn server network interface is “tun-SERVER”, ip is:
  2. vpn client network interface is “tun0”, ips is:

first time, in the vpn client router side, execute command:

ping the vpn server interface IP ok

or, in the OpenVPN Server side, set the openvpn server interface(tun-SERVER) can accept, as:

iptables -I INPUT -i tun-SERVER -j ACCEPT

iptables -I INPUT -i tun-SERVER -j ACCEPT

So you recommend to configure IP tables on the server side to make the server IP routable?

yes, in the OVPN-SERVER side, for example the ovpn-server network interface is “tun-SERVER”, the system firewall not only forward the pkg, also accept the input pkg.

the pkg destation IP address is to the ovpn-server system. firewall accept the pkg.

1 Like

Okay, rather than configuring iptables on the server (which I am a little bit scared of), I added an entry to my personal DNS server (dnsmasq) that maps the domain name of my home server to the private IP address. This makes sense because the DNS server is only available if the private IP is also valid. I am aware that only few are running their personal DNS server, so this is a handy solution but not for everybody. A quite similar solution is explained here: openvpn - Route traffic to vpn server over VPN - Server Fault

To wrap up this topic (at least for me), I have the impression that I was surprised (and still am) by some magical implicit behaviour of the participating components:

  1. Systemd’s NetworkManager adds an implicit “redirect-gateway” after having established a VPN connection.
  2. The OpenVPN client in the Mango mini router seems to do the same thing.
  3. OpenVPN adds a route for the OpenVPN server public IP that directs to the default gateway (instead through the tunnel). For a reason I do not know, this is lacking in the Mango, which led to the original problem of this topic. Note that I don’t like this route anyway and that I’m a lot happier with the DNS-based solution.
1 Like

You can config the ovpn client, such as:

  1. vpn server side static ip is:
  2. in vpn client side, check the route table, as:
    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use Iface
    default * U 0 0 0 tun0 UGH 0 0 0 eth0.2

find, the pkg destation address is the vpn server static ip, will through the eth0.2(WAN interface), not through the vpn interface. if not find this route rule, you can add it as:

ip route add via dev eth0.2**

  1. set the iptable, allow lan forward to wan:

iptables -I FORWARD -i br-lan -o eth0.2 -j ACCEPT

or you can forward all:
iptables -I FORWARD -j ACCEPT

Now, in the lan ip, visit the ovpn server side wan ip, Not through the vpn interface.

so, the ovpn server side’s other web server, can b visited through the server static ip.