Bug #13278
closed
OpenVPN dynamic gateway created incorrectly when not pulling routes or server pushes no routes
0%
Description
IF: I configure OpenVPN client and set the "Don't pull routes" check box
OR
IF: I include the advanced option: pull-filter ignore "redirect-gateway";
THEN:
pfSense creates a gateway entry for the interface that uses the IP address of the interface instead of the gateway address that is handed out by the server.
This stops any policy based routes from working as expected.
However, if I manually create a gateway that uses the proper address, policy based routes work.
Example:
With neither option checked, my routing table has these entries for the ovpnc interface, but ALL traffic is redirected over this tunnel.
Destination Gateway
0.0.0.0/1 10.8.8.1
10.8.8.0/24 10.8.8.1
10.8.8.1 link#13
128.0.0.0/1 10.8.8.1
the dynamic gateway entry shows 10.8.8.1 as the gateway IP address
If I use: pull-filter ignore "redirect-gateway"; the routes added look like this:
Destination Gateway
10.8.8.0/24 10.8.8.1
10.8.8.1 link#13
the dynamic gateway entry uses the "Virtual Address" assigned to the VPN client
Updated by Adrien Carlyle over 2 years ago
This appears to be happening because OpenVPN doesn't populate these environment variables when either option is selected.
${route_vpn_gateway}
${ifconfig_remote}
Which causes the ovpn-linkup script to use the interface address in the /tmp/interface_router file
I've modified the ovpn-linkup for now as follows and it's putting the value I'd expect to see in the gateway now. Although I'm sure there's a much more sane way to implement a fix for this.
if [ "${dev_type}" = "tun" ]; then
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
ifconfig ${1} | grep "inet " | cut -f2- -d ">" | cut -f1 -d "n" | sed 's/ //g' > /tmp/${1}_router
Updated by Jim Pingle over 2 years ago
- Project changed from pfSense Plus to pfSense
- Subject changed from OpenVPN dynamic gateway created incorrectly when not allowing default gateway redirect to OpenVPN dynamic gateway created incorrectly when not pulling routes or server pushes no routes
- Category changed from OpenVPN to OpenVPN
- Status changed from New to Needs Patch
- Affected Plus Version deleted (
22.01)
We're aware of this, but it's an OpenVPN bug, not a bug in our code. As you see, the variables are unpopulated even when they should be.
When set not to pull routes, or when the server does not push any routes, OpenVPN cannot determine the remote gateway properly and sets the gateway to its own IP address. In most cases this is harmless, however, because that route just nudges traffic to enter OpenVPN and OpenVPN makes its own routing decisions later. In the non-DCO case this works like it always has, but in the DCO case it can be trickier, though it should work properly on the most recent builds.
One workaround is to allow the client to pull routes (uncheck Don't pull routes) and check Don't add/remove routes instead. That will let OpenVPN find the remote gateway but won't affect the contents of the routing table. This works for the case when the client is opting not to accept routes but it doesn't help when the server doesn't push any routes. Making the server push at least one 'dummy' route to a meaningless network in addition to these client settings will work around it, though.
The code in /usr/local/sbin/ovpn-linkup tries to check route_vpn_gateway and ifconfig_remote but they are both empty so it falls back to ifconfig_local. Looking at the environment variables available there aren't any that have the remote address in there, despite the fact that it's actually on the interface.
Using ifconfig to get the remote address is not a viable long term fix.
There is an OpenVPN bug entry that suggests the empty/unset ifconfig_remote is due to subnet topology, which may be true, though it doesn't explain why it's actually used on the interface but not present in the environment.
There is a separate OpenVPN bug entry about the lack of route_vpn_gateway when no routes are pushed/pulled.
This really needs to be fixed upstream in OpenVPN rather than trying to hack around it locally.