[How to] pfSense Selective Routing via VPN and WAN Interfaces

Skepticatpf

EDIT: PC is also going through VPN instead of WAN… Attaching the NAT rules screen shot.

Thank you guys for the response... As suggested I think I need to reorder the rules as my Roku is still trying to use VPN interface.

A question: in the second floating rule, shouldn't I specify source as SERVER1? Otherwise how would it know? Adjusted below...

@kesawi:

Action: Match
Interface: LAN
Direction: in
TCP/IP Version: IPv4 + IPv6
Protocol: Any
Source: Single Host or Alias - SERVER1
Destination: any
Advanced Options: Mark packets matching this rule: NO_WAN_EGRESS

Action: Reject
Interface: WAN
Quick: Enabled
Direction: out
TCP/IP Version: IPv4 + IPv6
Protocol: Any
Source: Single Host or Alias - SERVER1
Destination: any
Advanced Options: Match packet on a mark: NO_WAN_EGRESS

NAT.png_thumb

Derelict

If you are using NAT you can't match traffic by inside local source address using floating rules on WAN out because NAT has already happened and the source address is now your mapped NAT address.

That's why I use the whole NO_WAN_EGRESS scheme. Mark it on LAN in and let that rule prevent it from going out WAN.

The reject rule should be protocol any source any dest any matching on NO_WAN_EGRESS. You don't care what it is or where it came from and just want it blocked from going out the clear WAN if it's marked.

I am not a fan of using floating rules for things that can be done on interface rule tabs. For instance, mark the traffic NO_WAN_EGRESS on the LAN rule that routes the traffic out the VPN.

Skepticatpf

Apologies for being a dense noob. I set-up the NAT per tutorial posted here. With my set-up, you mind typing up a step by step? Does you comment apply to kesawi's post as additional rules or replacement?

Thank you!

@Derelict:

If you are using NAT you can't match traffic by inside local source address using floating rules on WAN out because NAT has already happened and the source address is now your mapped NAT address.

That's why I use the whole NO_WAN_EGRESS scheme. Mark it on LAN in and let that rule prevent it from going out WAN.

The reject rule should be protocol any source any dest any matching on NO_WAN_EGRESS. You don't care what it is or where it came from and just want it blocked from going out the clear WAN if it's marked.

I am not a fan of using floating rules for things that can be done on interface rule tabs. For instance, mark the traffic NO_WAN_EGRESS on the LAN rule that routes the traffic out the VPN.

Derelict

https://www.infotechwerx.com/blog/Policy-Routing-Certain-Traffic-Through-OpenVPN-Client-Connection

kesawi

@Derelict:

I am not a fan of using floating rules for things that can be done on interface rule tabs. For instance, mark the traffic NO_WAN_EGRESS on the LAN rule that routes the traffic out the VPN.

My preference for using a LAN floating rule to mark traffic is that the floating rule will be processed before the individual LAN rule. If I misconfigure the LAN rules or get the order of my LAN rules wrong, then traffic may not be marked and it could leak out of the WAN interface. At least with the LAN floating rule the traffic will always be marked and blocked by the WAN floating rule, even if I stuff up my LAN interface rules (at least that's my theory :)).

@Skepticatpf:

Apologies for being a dense noob. I set-up the NAT per tutorial posted here. With my set-up, you mind typing up a step by step? Does you comment apply to kesawi's post as additional rules or replacement?

They are replacement rules. If you are using the LAN floating rule (ie as per my post) then there is no need for another LAN interface rule to mark the packets from the host. If you are using a LAN interface rule to mark the packets as per Derelict's suggestion, then you don't need the LAN floating rule.

@Derelict:

https://www.infotechwerx.com/blog/Policy-Routing-Certain-Traffic-Through-OpenVPN-Client-Connection

Nice write up, should probably be a sticky pointing to it.

Skepticatpf

@kesawi:

They are replacement rules. If you are using the LAN floating rule (ie as per my post) then there is no need for another LAN interface rule to mark the packets from the host. If you are using a LAN interface rule to mark the packets as per Derelict's suggestion, then you don't need the LAN floating rule.

OK, would my NAT rules interfere with LAN floating rules? I assume I need to remove NAT for PIAVPN and do everything either from floating or LAN tabs. I want to try one clean set-up to make sure it works and I understand what is being done.

Derelict

NAT rules do not route or pass/reject/deny traffic.

NAT rules simply determine what happens to the source address/port if the router has determined traffic should be sent out the interface identified in the rule.

Skepticatpf

OK, I think I got the point of NAT not routing, but per your post it seems it would prevent my floating rule from working as it translated LAN IPs…

@Derelict:

If you are using NAT you can't match traffic by inside local source address using floating rules on WAN out because NAT has already happened and the source address is now your mapped NAT address.

Reference also tells me that NAT gets processed first:

https://doc.pfsense.org/index.php/Firewall_Rule_Processing_Order
More accurately, the following order (still simplified) is found in the ruleset (Check /tmp/rules.debug):

Outbound NAT rules
Inbound NAT rules such as Port Forwards (including rdr pass and UPnP)
NAT rules for the Load Balancing daemon (relayd)
Rules dynamically received from RADIUS for OpenVPN and IPsec clients
Internal automatic rules (pass and block for various items like lockout, snort, DHCP, etc.)
User-defined rules:
Rules defined on the floating tab
Rules defined on interface group tabs (Including OpenVPN)
Rules defined on interface tabs (WAN, LAN, OPTx, etc)
Automatic VPN rules

So, per my attached NAT screen shot, do I need to remove them if I to use kesawi's recommended floating rule?

This is the instructions PIA listing for NAT set-up:

At this point, automatic rules that were in use in Automatic outbound NAT will be generated. It will look like the following, with the exception that the Source IP subnet will match your LAN IP subnet.
https://www.privateinternetaccess.com/images/tutorials/PfSense4.png?7cd5ee465d9c63d0bcf7bc759a274547

The next step is to duplicate each of these rules, but change the NAT Address from WAN to PIAVPN. Start with the first rule by clicking the Plus sign immediately to the right of the line "to add a new NAT based on this one." A new page will open. Configure as follows:

https://www.privateinternetaccess.com/images/tutorials/PfSense6.png?126ce9963a0353a47776de24cd40b752

NAT.png_thumb

Derelict

Yes, NAT happens before OUTBOUND floating rules are processed so you cannot identify traffic by the real source IP address.

What's the fascination with floating rules? They are great when match rules, "unquick" rules, or rules going out an interface are needed but not for simple in rules. It just adds complexity and makes you look in two different places to see what's really going on.

You have a host on LAN. Put the rules on LAN that forward traffic from it wherever you want. If you never want it to go out WAN mark it on those rules. Then with ONE floating rule on WAN out protocol any source any dest any and matching the mark you can block all traffic that should not go out WAN from all interfaces everywhere (Except the firewall itself, which is a different issue). You never have to worry about NAT because rules coming IN an interface are pre-NAT.

Skepticatpf

@Derelict:

Yes, NAT happens before OUTBOUND floating rules are processed so you cannot identify traffic by the real source IP address.

Thank you for sticking with me! OK, this getting clear to me, I promise.

@Derelict:

What's the fascination with floating rules? They are great when match rules, "unquick" rules, or rules going out an interface are needed but not for simple in rules. It just adds complexity and makes you look in two different places to see what's really going on.

No emotional attachment what so ever: pfSense user of 4 days here. I want to avoid complexity as much as possible.

@Derelict:

You have a host on LAN. Put the rules on LAN that forward traffic from it wherever you want. If you never want it to go out WAN mark it on those rules. Then with ONE floating rule on WAN out protocol any source any dest any and matching the mark you can block all traffic that should not go out WAN from all interfaces everywhere (Except the firewall itself, which is a different issue). You never have to worry about NAT because rules coming IN an interface are pre-NAT.

OK, when I am home I will try to clean up and do this via LAN rules…

Skepticatpf

Success!

I accomplished this with two LAN rules, which I forgot to move to the top, duh. One for Hulu/PC routing to WAN, another for Server routing to PIAVPN. Marked the latter one as NO_WAN_EGRESS. Created then a floating rule.

Question: PIA has a few US servers. Can I create multiple interfaces and use them for failover? E.g. PIA1 US-EAST, PIA2 US-NY, if PIA1 goes down, pfSense will try to bring up PIA2.

Action: Reject
Quick: Checked
Interface: WAN (you can also select multiple WAN interfaces or an interface group here)
Direction: out
Protocol: any
Source: any
Destination: any
Description: Reject outbound traffic marked NO_WAN_EGRESS
Advanced: You can match packet on a mark placed before on another rule: NO_WAN_EGRESS