Feature #5835
open
Improve OpenVPN client gateway detection in edge cases where the remote does not send gateway information
0%
Description
There are a few edge cases where OpenVPN does not set the "route_vpn_gateway" or "ifconfig_remote" environment variables so the "up" script cannot determine the gateway.
Currently the script falls back to using the local IP address in this case, which works OK for some things like policy routing when the interface is assigned, but it causes the wrong IP address to be monitored.
The problem scenario requires BOTH of the following to be true:- tap mode OR tun+topology subnet is used
- Server does not push ANY routes
In that case, the only possible way for the client to determine the gateway is by subnet calculation, assuming the gateway is the first IP address in the block. Our code currently falls back to using the client adapter address in this case when the other two variables are unset.
Fixing it would require the ability to do subnet math or similar calculation from a shell script, or perhaps pulling the config off the interface using ifconfig or another similar function.
Since it appears to work fine from a user perspective aside from picking the right monitor IP address, it's pretty minor as far as I can tell so far.
Updated by Dmitriy K about 8 years ago
I've done experimenting with this (#5981) issue. Looks like it's the issue of OpenVPN itself. If I add this string into server's config:
push "redirect-gateway def1"
Here is PUSH command from server on client side without redirect-gateway:
PUSH: Received control message: 'PUSH_REPLY,route-gateway 172.22.0.1,ping 5,ping-restart 30,ifconfig 172.22.0.2 255.255.255.252'
with redirect-gateway:
PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,route-gateway 172.22.0.1,ping 5,ping-restart 30,ifconfig 172.22.0.2 255.255.255.252'
So, with that redirect-gateway option OpenVPN initialize every needed env. var. properly and ovpn-linkup does it's job well! Here is a debug log:
ifconfig_local=172.22.0.2; route_vpn_gateway=172.22.0.1; dev_type=tap;
I will stick this server config then but I have to add route-noexec into client config or uncheck "Don't add/remove routes" option to make things work as I wanted do.
This should be reported to the OpenVPN team, I suppose.
Updated by Jim Pingle about 8 years ago
Feel free to open a bug upstream with OpenVPN if you'd like to see if they would be willing to accommodate this scenario better in the future.
That said, I believe they do this deliberately. In this scenario if there are no pushed routes the server may have no need to push a gateway and pushing a gateway could potentially have other side effects (e.g. with tap bridges), so I'm not sure if they'd want to alter the behavior for everyone. Unless they were to add another directive for the server to always push a gateway rather than doing so conditionally with no separate controls.
Updated by Chris Buechler about 8 years ago
Jim Pingle wrote:
That said, I believe they do this deliberately. In this scenario if there are no pushed routes the server may have no need to push a gateway and pushing a gateway could potentially have other side effects (e.g. with tap bridges), so I'm not sure if they'd want to alter the behavior for everyone. Unless they were to add another directive for the server to always push a gateway rather than doing so conditionally with no separate controls.
It still pushes the gateway in that case, you see that in the client's log, but OpenVPN doesn't set the environment variable unless there is a pushed route. That seems like a bug, there should be no reason to omit that environment variable in any circumstance where it exists. What's done with that env variable is entirely up to the user-created up script.
I opened an OpenVPN bug on that. https://community.openvpn.net/openvpn/ticket/668