OpenVPN client - Gateway misconfigured or missing reply-to

[Ulrar]

Hi Opnsense team,

I'm not sure weather it's a bug or if I'm doing something wrong, but after a week of being unsuccessful on the forum and on IRC I'm guessing it must be a bug.

Here's my latest thread for full reference : https://forum.opnsense.org/index.php?topic=19676.0

My issue is that I have an OpenVPN client configured to get a public IP. Whatever I do, the Gateway created when that VPN comes up has "dynamic" in IP the field when editing, but that seems to resolve to the interface's IP when confirming (I'm blacking it out because it's a public IP) :

That IP itself is routed to the loopback interface, which I'm assuming is added automatically :

(the interface's IP is the red box in the above screenshot, you can see it's routed to lo0).

The problem here is that any incoming connections on that interface, or outgoing policy based routed connections are therefore going through lo0 and never leave the router. If I try to do an http query, I get my own local HAProxy answering since it's bound to port 80, it's never going through the ovpnc1 interface.

If I edit the gateway, remove dynamic and put another IP (I've been using the first IP of the bloc my IP is in, since that has an automatic route) then policy based routing starts to work fine. But I've looked at /tmp/rules.debug and in that case the reply-to bits are missing from the inbound rules, which means the default gateway is used to answer incoming connections (internet -> vpn port 80 -> haproxy -> wan interface -> dropped by my isp).

With an edited vpn gateway, if I edit the /tmp/rules.debug file to add the missing reply-to and re-apply that file then everything works as expected. I think the bug here is that the gateway doesn't get generated correctly by default, I don't think I should have to edit that by hand to change it's IP, right ? Since the reply-to are there and valid as long as I don't edit the gateway, I think everything would work fine if "dynamic" were to resolve to the correct IP. An alternative fix would be to be able to force a reply-to on a given rule, but it doesn't look like there's any way to do that short of editing the file after each rule change / reboot.

Sorry for the long text, I hope the issue is clear. If I'm doing something wrong then sorry, but I have been stuck on this for a week now and it really looks like a bug to me. I did all the latest updates and no difference.

Thanks !

[hippi-viking]

Hello,

To second this I also have this long-standing issue with OpenVPN. When an OpenVPN client is set up for policy routing (Don't pull routes and Don't add/remove routes are checked on the VPN:OpenVPN:Clients page the gateway on System:Gateways:Single is set to the client IP instead of the server IP if IP address is set to dynamic on the gateway setup page.

Just a hunch but could the problem be in the ovpn-linkup script?

if [ -n "${route_vpn_gateway}" ]; then /bin/echo ${route_vpn_gateway} > /tmp/$1_router elif [ -n "${ifconfig_remote}" ]; then /bin/echo ${ifconfig_remote} > /tmp/$1_router elif [ -n "${ifconfig_local}" ]; then /bin/echo ${ifconfig_local} > /tmp/$1_router

As far as I understand this piece of code seems to put an IP address in /tmp/ovpnc?_router - ANY IP address for that matter gateway, remote or local - so might confuse later on what the IP address is for?

Related to: #4133 and #4268.

[Ulrar]

I'd add that I'm getting that weather or not I tick the Don't pull routes and Don't add/remove routes checkboxes, I don't think this is related, but that is indeed the goal for me too. It's been like that for months and I've never really bothered looking into it since editing the Gateway solves the policy based routing issues, but unfortunately that still doesn't make inbound connections work and that's what I'm looking for now.

Thanks for the related issues, I hadn't seen these ! Good to know it's affecting more users, I was afraid it was some weirdness in my config. Might be worth trying to fiddle with that script, see if your hunch is right, I'll try to take a look over the week end

[hippi-viking]

I would have thought the pull/add-remove routes switches might set up the routes correctly with ip link commands. Anyway I had a look at the script and indeed the gateway issue can be solved by modifying it (I sent a PR).

Speaking of strange routing issues I also have problems even on the outbound connections (or maybe the related inbound answers I am not entirely sure). It seems like lost packets or packets delivered to the wrong interface. For example if I route ICMP through OpenVPN I have roughly 50%-70% chance of getting an answer to pings through the tunnel - while if I ping the same non-local IP address (say Google) outside the tunnel I have an answer every time. The strange thing is that this goes in 'bursts' so if the connection is set up correctly it works, if not it will not start to work by itself (I have to actively reinitiate a connection for it to work). It feels like some kind of round-robin connection routing going on (incorrectly) behind the scene. (Maybe shared forwarding?) It seems like a deeper OS-level issue and might be related to #4094.

[hippi-viking]

I think I have found the reason for my strange round-robin-like error, and that might be the reason for your problem as well: NAT settings. My setup has two OpenVPN connections policy routed with entirely different IP ranges so they don't clash. For testing I set up NAT for the OpenVPN interface, which was working at the time so (of course) I forgot about it. It was just recently that I noticed that sometime packets are not going through, checking the firewall logs I saw packets on the OpenVPN interfaces with the wrong IPs. (Of course the NAT acted in a random way because of this.) Long story short double check your outbound NAT rules, they might be the culprit. (Defining separate rules for each OpenVPN connection solved the issue for me so far.)

[Ulrar]

Hi

You have to define oubout NAT rules by hand because of this bug indeed. By default they won't be generated, I don't think it's the cause but rather a symptom of the same issue.

On Wed 28 Oct 2020, 10:47 Hippi Viking, notifications@github.com wrote:

I think I have found the reason for my strange round-robin-like error, and that might be the reason for your problem as well: NAT settings. My setup has two OpenVPN connections policy routed with entirely different IP ranges so they don't clash. For testing I set up NAT for the OpenVPN interface, which was working at the time so (of course) I forgot about it. It was just recently that I noticed that sometime packets are not going through, checking the firewall logs I saw packets on the OpenVPN interfaces with the wrong IPs. (Of course the NAT acted in a random way because of this.) Long story short double check your outbound NAT rules, they might be the culprit. (Defining separate rules for each OpenVPN connection solved the issue for me so far.)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/opnsense/core/issues/4419#issuecomment-717850713, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGVHTZ4ZHFNX5KCTJWVCLLSM7ZC3ANCNFSM4SWGQ6MQ .

[ElectronicEconomy317]

Hello!

I too am having issues routing with PIA and OPENVPN. The client connects to PIA without issue...but nothing leaves the router. I have setup the outbound NAT rules...and still can't get any traffic to leave the router....the traceroutes just timeout.

I just migrate from PFsense...and copied my pfsense setup (almost exactly)...and it just doesn't work on OPNSense. A developer needs to look into this. I am happy to help where I can... just let me know what you need from my setup.

[mimugmail]

Hello!

I too am having issues routing with PIA and OPENVPN. The client connects to PIA without issue...but nothing leaves the router. I have setup the outbound NAT rules...and still can't get any traffic to leave the router....the traceroutes just timeout.

I just migrate from PFsense...and copied my pfsense setup (almost exactly)...and it just doesn't work on OPNSense. A developer needs to look into this. I am happy to help where I can... just let me know what you need from my setup.

Please open a thread im Forums with all details and screenshots

[db260179]

So typically a openvpn server would have push options to clients to make sure they are getting the correct settings.

For my vpn provider Surfshark - I do some pull ignore filters so that i can enable the pull routes option in the vpn client config, otherwise the opnsense up script will not correctly set the default gw of the vpn server, and set the vpn client ip address as the gateway in the gateways section.

Example: pull-filter ignore "block-outside-dns"; pull-filter ignore "dhcp-option";

Logic in pfsense is different for some reason, and this confused me.

I dont have the 'add/remove routes ticked' because i dont want the vpn gw being set as the main route gw and tunneling all of my hosts on that gw.

So just double check these options, increase the debug level to 4 to see what is going on with or without these two options?

[AdSchellevis]

https://github.com/opnsense/core/commit/0ad3ec432ff0d1ee45d9969424b7e5b19eb903e2

[kkoshelev]

I asked question in another bug, but maybe this thread is more relevant. Would anyone recommend any special setting to resolve incorrect gateway address?