Firewall Traffic Needs "redirect-gateway def1" to Route Thru VPN?

[beremonavabi]

This is another of those things I thought was working, but, apparently, wasn't.

I thought I'd set up my pfSense box so everything hitting the internet had to go through my OpenVPN tunnel to AirVPN.  AirVPN's main page showed me as going through their servers, and sites like:

https://ipleak.net/

and

https://whoer.net/

showed everything as being fine.

But, I was watching a video in the pfSense Hangout Archive (the October 2016 "OpenVPN as a WAN" video by Jim Pingle) and saw the following on the slide at about the 50 minute point:

-Traffic from the firewall won't use VPN unless the default route or routing table tells it to go that way
    – DNS traffic (resolver, forwarder)...
...

• To manually use VPN as default gateway, use "redirect-gateway def1;" in advanced options, don't set under System > Routing
• OpenVPN will put 0.0.0.0/1 and 128.0.0.0/1 in routing table so it does not stomp system default gateway, otherwise VPN traffic couldn't exit.

From:

https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage

–redirect-gateway flags...
Automatically execute routing commands to cause all outgoing IP traffic to be redirected over the VPN. This is a client-side option.
This option performs three steps:

(1) Create a static route for the --remote address which forwards to the pre-existing default gateway. This is done so that (3) will not create a routing loop.

(2) Delete the default gateway route.

(3) Set the new default gateway to be the VPN endpoint address (derived either from --route-gateway or the second parameter to --ifconfig when --dev tun is specified).

When the tunnel is torn down, all of the above steps are reversed so that the original default route is restored.

Option flags:

local -- Add the local flag if both OpenVPN servers are directly connected via a common subnet, such as with wireless. The local flag will cause step 1 above to be omitted.

autolocal -- Try to automatically determine whether to enable local flag above.

def1 -- Use this flag to override the default gateway by using 0.0.0.0/1 and 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of overriding but not wiping out the original default gateway.

bypass-dhcp -- Add a direct route to the DHCP server (if it is non-local) which bypasses the tunnel (Available on Windows clients, may not be available on non-Windows clients).

bypass-dns -- Add a direct route to the DNS server(s) (if they are non-local) which bypasses the tunnel (Available on Windows clients, may not be available on non-Windows clients).

block-local -- Block access to local LAN when the tunnel is active, except for the LAN gateway itself. This is accomplished by routing the local LAN (except for the LAN gateway address) into the tunnel.

OK.  Fine.  But, two questions:

1.  In something approaching reasonable English, what does pfSense's adding 0.0.0.0/1 and 128.0.0.0/1 to the routing table actually mean?
2.  Is there any way for a plain ol' guy with a simple home network to test that everything's actually going through the VPN tunnel?

[beremonavabi]

Just in case anyone else is wondering about this, this is the best I can come up with on what the addition of 0.0.0.0/1 and 128.0.0.0/1 to the routing table means:

1.  0.0.0.0/1 covers the first half of the IPv4 address space (0.0.0.1 - 127.255.255.254)
2.  128.0.0.0/1 covers the last half of the IPv4 address space (128.0.0.1 - 255.255.255.254)
3.  The two, together, cover the whole address space and are more specific than 0.0.0.0/0, so the route takes precedence over that
4.  I don't know what pfSense's default routing table looks like, but on my computer, 0.0.0.0/0 is present and points to my default gateway (the pfSense box).  So, assuming pfSense is similar, the default gateway will be 0.0.0.0/0 and will point to the WAN.  That means the gateway associated with the redirect-gateway pair will take precedence over the default gateway.
5.  Since the default gateway is still there, if something specifically addresses it, it will be more specific than the 0.0.0.0/1 plus 128.0.0.0/1 pair and will, thus, be used instead.
6.  So, assuming 0.0.0.0/0 points to the WAN address and the redirect-gateway pair points to the VPN, everything will go over the VPN unless it's specifically addressed to the default gateway.  In which case it will go out the WAN.  I assume the VPN itself will use that.

[Derelict]

Yes. Those two routes cover all IPv4 traffic. They are used by OpenVPN in exactly the manner described above. That way OpenVPN does not have to manipulate the system default route.

Most (all?) OpenVPN providers will push redirect-gateway def1. You can control whether you accept these routes from them using the Don't pull routes checkbox in the client configuration.

If you check that box you must assign an interface to the OpenVPN client instance which will create a gateway that you can use to selectively policy route only certain traffic over the VPN.

Many threads on the subject here.

[beremonavabi]

Thanks for the reply.  I do have the "Don't Pull Routes" box checked in my VPN clients and have (hopefully) the appropriate rules set to get normal traffic out.  It just surprised me that pfSense, itself, doesn't send its stuff out that way (though, now that I've thought about it, it shouldn't have).  Odd that there isn't a "Redirect-Gateway" box to check in the GUI for the clients.

I've attached some screenshots of my firewall stuff (most of the NAT stuff can be ignored since nothing is usually on those interfaces).


[beremonavabi]

A couple of additional notes about my earlier posts.  First, I'm embarrassed about not being able to find the routing table in pfSense.  It's at:

Diagnostics > Routes

I thought it was Tables and my brain shut down even more when I didn't see what I expected.

Second, I finally added the redirect-gateway command into the advanced options of my OpenVPN clients.  Everything seems to be working (hopefully, this "seems" is more accurate than my previous "seems").  My routing table now includes both 0.0.0.0/1 and 128.0.0.0/1 and both point to the x.x.x.1 address of my VPN Gateway Group's Tier 1 entry.  I assume it will switch to the address for the Tier 2 entry if the Group fails over.  Default is still there and still points to my WAN.

And, finally, I guess the "Don't Pull Routes" box could be considered that GUI option to enable "redirect-gateway."  The trouble is that we don't know in advance what routes the provider will push if we leave that option un-checked.