Exempt Specific Interface from "redirect-gateway def1"? [SOLVED]

[beremonavabi]

To force all traffic through my VPN, I recently added "redirect-gateway def1;" at the bottom of my OpenVPN clients' Advanced Options list.  That works.  Unfortunately, it shuts down my interfaces that I'd had configured to leave the pfSense box over my regular WAN interface.  On those interfaces, I now get no internet connection at all.  I thought I could get around that by adding the following just after the "redirect-gateway" command:

route 192.168.40.0 255.255.255.0 net_gateway;

where 192.168.40.0 is the subnet assigned to that interface.  It doesn't make any difference (still no internet connection).  I assume that command doesn't do what I think it does.  Anyone have any other suggestions for exempting a specific interface from going through the OpenVPN tunnel?

[Derelict]

Don't use redirect-gateway def1. Instead policy route all traffic from one LAN to the OpenVPN interface gateway and don't policy route traffic from the other.

Or use redirect-gateway def1 and policy route all traffic on the exempt interface to the WAN.

Your choice which one makes more sense for you.

[dvv06]

for testing…
https://community.openvpn.net/openvpn/wiki/IgnoreRedirectGateway

[beremonavabi]

I'm using redirect-gateway to force ALL traffic (including pfSense's) through the VPN:

https://forum.pfsense.org/index.php?topic=130674.msg719951#msg719951

I'm not sure exactly what you mean by "policy route," but I think it means to use NAT and Firewall rules to send the traffic where I want it.  I'm doing that, but it stopped working once I added the redirect-gateway.  Looking at my GUEST_LAN:

I've got an Outbound NAT rule for it that translates traffic leaving from its interface to the WAN address:

WAN 192.168.40.0/24 * * * WAN address * GUEST_LAN to WAN

My Firewall rules for GUEST_LAN are:

Pass IPv4 ICMP any GUEST_LAN net * * * * none GUEST_LAN: Pass ICMP  
Reject IPv4 * GUEST_LAN net * Non Guest Local Subnets * * none GUEST_LAN: Reject Any Local Traffic  
Pass IPv4 * GUEST_LAN net * * * * none GUEST_LAN: Pass WAN (Pass Any, But Local Already Handled)

Those should be allowing any ICMP from the GUEST_LAN interface to anywhere, rejecting any traffic from GUEST_LAN destined for local networks (that aren't on the GUEST_LAN, itself), and allowing GUEST_LAN traffic bound for everything else (i.e, stuff besides my local networks).

Pre "default-gateway," that worked.  Now, systems connected to it say there's no internet connection.  Initially, I thought it might be because the DNS traffic is still trying to go out the VPN (Resolver in non-forwarding mode isn't routed).  But, if that were the case, I ought to have an internet connection – just without an ability to resolve names.

Regarding the link to the IgnoreRedirectGateway page, I'd seen that, but that seems to be overriding the "default-gateway" entirely.  Not just for one interface (subnet).


[Derelict]

Policy routing means forcing traffic to a specific gateway using the source interface firewall rules.

https://doc.pfsense.org/index.php/What_is_policy_routing

https://portal.pfsense.org/docs/book/multiwan/policy-routing-configuration.html

https://portal.pfsense.org/docs/book/openvpn/assigning-openvpn-interfaces.html#policy-routing-with-openvpn

[beremonavabi]

It looks like I've solved it, and, as Derelict said, it was a policy routing issue.  My firewall rule for allowing traffic from that interface out to the WAN was missing a Gateway.  It was:

Pass IPv4 *  GUEST_LAN net  *  *  *  *  none      GUEST_LAN: Pass WAN (Pass Any, But Local Already Handled)

and I changed it to:

Pass IPv4 *  GUEST_LAN net  *  *  *  WAN_DHCP  none      GUEST_LAN: Pass WAN (Pass Any, But Local Already Handled)

I assume the issue was that I hadn't specified how the traffic was supposed to leave, so it defaulted to whatever the system was set up to use.  Before the "redirect-gateway," that was the the WAN.  Afterward, it was the VPN.  Once I added the gateway, that got specific enough to override the use of the VPN and actually use the WAN.