Fix OpenVPN dynamic gateway detection #4433
Conversation
This is a quick hack to fix OpenVPN dynamic gateway detection for 99% of the cases. It is highly unlikely someone has a VPN gateway on their own local tunnel IP / loopback. The gateway usually is the .1 address on the same subnet as the client, this fix will help in that case. If this is not the case, a proper parser should be written (which could be overkill for simple use cases).
|
this likely won't get merged, different discussions have been going on this subject (like #4134 (comment), #4268 (comment)), but in order help this further one will have to prepare test setups for different scenario's and explain what the expected outcome should be when using different options. |
|
Thanks, this will be a local patch only then as well for the time being. How can I help with the test setups? I have multiple commercial VPN tunnel clients set up, they all work as per the proposed patch. I cannot imagine a scenario where the local tunnel address might be the gateway (not even for an OpenVPN server), so the proposed patch should not break anything in any case. |
|
If the issues only involve cases where either |
|
If a "real" fix is going to take time and effort, could you maybe just add a tickbox "use device as gateway" in the interface settings instead ? That wouldn't break any existing setup and would allow people affected by this to finally be able to use their VPN. I know in my specific case using the first IP in the block works but only because it's on the correct device, my VPN's admin very specifically told me that I shouldn't have an IP at all as the gateway, and I suspect that's true for a lot of people. That's likely why it comes up empty in those variables. |
|
For normal destination based routing you probably shouldn't need an address, people trying to use policy based routing should likely add a manual gateway with the correct endpoint. This is the same discussion as #4268 (comment) , when the gateway can't be predicted reliably the script should probably just remove the router file in this section core/src/etc/inc/plugins.inc.d/openvpn/ovpn-linkup Lines 10 to 11 in a0dad1a |
|
You can't do policy based routing without a fix, and if you edit the
gateway then reply-to doesn't get added anymore, so you get policy based
routing working but you lose incoming connections.
Either way by default nothing works, the VPN is unusable unfortunately
…On Tue 27 Oct 2020, 19:34 Ad Schellevis, ***@***.***> wrote:
For normal destination based routing you probably shouldn't need an
address, people trying to use policy based routing should likely add a
manual gateway with the correct endpoint. This is the same discussion as #4268
(comment)
<#4268 (comment)> ,
when the gateway can't be predicted reliably the script should probably
just remove the router file in this section
https://github.com/opnsense/core/blob/a0dad1a3b22de29157db0658cbd1e8bbcc8f5200/src/etc/inc/plugins.inc.d/openvpn/ovpn-linkup#L10-L11
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#4433 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGVHT43LSLJ6ZEBMLI3FELSM4OETANCNFSM4S7HEO6A>
.
|
|
I don't mind fixing something in this area, the question remains what should we fix. My initial question about preparing different scenarios and their expected outcome is all aimed at collecting the relevant data points..... if the |
|
Sadly I don't have IPv6 connection (not even my ISP supports it), so I cannot test it easily. |
|
So I finally got around to testing the patch in this PR and it works fine, except in my case the first IP of the bloc is .129. IMHO if we just added a line to calculate the first IP from the |
…first network address as gateway address. for #4433
|
@Ulrar your probably right, although it would still be practical if more people test different configurations, this 0ad3ec4 should probably help for most setups (assuming |
|
Thanks Ad. (excerpts from the OpenVPN log:) I was thinking either calculating the first IP to be the gateway(?) based on the local IP and netmask OR parsing the routing table (OpenVPN seems to set it up correctly based on the log) OR parsing the openvpn.log file itself to get the gateway IP address. |
|
so, the question is, does the calculation )in 0ad3ec4) work for all use-cases known so-far. I rather prevent parsing route tables or ifconfig statements to be honest. |
|
I also stumbled over this problem. I created issue #4268 . Fo IPv4 the problem only occures with topology |
|
0ad3ec4 does work perfectly, any chance to get that merged at some point ? It'd be nice not to have to go edit the file after each update. |
|
Not fixed? Would anyone look at my data and help with settings? I'm having similar problems in my setup. The openvpn gateway doesn't get correct settings. ovpn-linkup didn't get called with valid gateway address. I suspect the problem is with PUSH_REPLY sent by vpn server. I have two cases with exactly the same OPNsense settings, one of them works another doesn't. PIA VPN - doesn't work routing table logs ExpressVPN - works routing table logs |
…first network address as gateway address. for opnsense/core#4433
This is a quick hack to fix OpenVPN dynamic gateway detection for 99% of the cases. It is highly unlikely someone has a VPN gateway on their own local tunnel IP / loopback. The gateway usually is the .1 address on the same subnet as the client, this fix will help in that case. If this is not the case, a proper parser should be written (which could be overkill for simple use cases).