Bug #1823


policy routing for firewall-initiated traffic only works for interface IPs

Added by Chris Buechler about 10 years ago. Updated almost 9 years ago.

Rules / NAT
Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


The rules such as:

pass out route-to ( em1 ) from to ! keep state allow-opts label "let out anything from firewall host itself" 

Only apply to interface IPs, so traffic sourced from CARP IPs, IP aliases, etc. are not automatically routed out the correct WAN. The source needs to be extended to include all locally-assigned IPs on that WAN interface. Can work around it with floating rules for the time being.

Actions #1

Updated by Ermal Luçi almost 9 years ago

  • Status changed from New to Feedback
Actions #2

Updated by Ermal Luçi almost 9 years ago

  • % Done changed from 0 to 100
Actions #3

Updated by Adam Gibson almost 9 years ago

Can this be an option? I actually consider it a feature. I don't want policy routing at all. I change routing on the firewall's route table to route specific MPLS traffic through another connection. I dynamically drop and add that route.

Ideally I wouldn't want any default route-to. Only rules that I specify should have them (I don't need any right now even for locally generated traffic from firewalls).

Actions #4

Updated by Chris Buechler almost 9 years ago

it's always been optional, users can override with floating rules. It's an appropriate default for the vast majority.

Actions #5

Updated by Adam Gibson almost 9 years ago

I didn't think it was possible to override it. I just tested it and could not override it.

You can not create an equivalent rule that removes the hidden rules route-to from applying to future out traffic...
pass out route-to DefaultRouteTable ... # no such thing as this with the gui...

If I create a floating rule that specifies default for gateway in the gui to try and cancel the hidden out route-to rule that doesn't work. It creates the rule below.

pass out from any to any keep state label "USER_RULE: Disable route-to by overridding the hidden rule"

The hidden route-to still gets applied for the local firewall traffic that originates from the real Wan IP of the firewall. I just tested it 20 minutes ago.

Is there some other feature I am not aware of that would cancel the hidden route-to with a floating rule?

Not being able to cancel the route-to is why I commented on this bug fix. I don't think it is possible to cancel it.

Actions #6

Updated by Adam Gibson almost 9 years ago

!!!! Hold up... !!!!

The above rule did cancel the route-to it seems. Sorry about that, I messed up the test. I don't understand why though. Does this mean any out rule I create will override the hidden route-to? Even queue type rules? I use out for specifying queue type rules.

Actions #7

Updated by Adam Gibson almost 9 years ago

Strange. I am seeing inconsistency with this or I am going crazy and making a bunch of mistakes testing this (I am starting the testing over again). Can you comment on how to disable the hidden route-to properly with a rule in pfsense so to mitigate against this fix?

Actions #8

Updated by Adam Gibson almost 9 years ago

As an update. The out rule in floating that I listed does disable the hidden route to.route-to.

I found the mistake in my testing. The rule was disabled when I thought it wasn't.

Fixing this bug will not cause any issues for me as you said it wouldn't with the floating rule. If you can comment why the route-to is canceled without specifying a route-to it would be appreciated as I thought if you dont specify options they are accumulative if you do not set quick option. I honestly didn't think it was possible to disable the route-to.

Thanks for your time. I do appreciate it.

Actions #9

Updated by Adam Gibson almost 9 years ago

I already know the answer after thinking about it. Only if the hidden rule used match would the route-to stack onto the next pass out that matched a packet. It wouldn't make sense to use match there of course because we want outgoing traffic from the firewall to flow :). I just wanted to add this to finish the discussion about this behavior.

Thanks again.

Actions #10

Updated by Renato Botelho almost 9 years ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF