Bug #1823
closed
policy routing for firewall-initiated traffic only works for interface IPs
Added by Chris Buechler about 13 years ago.
Updated almost 12 years ago.
Description
The rules such as:
pass out route-to ( em1 9.2.2.1 ) from 9.2.3.18 to !9.2.2.0/21 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.
- Status changed from New to Feedback
- % Done changed from 0 to 100
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).
it's always been optional, users can override with floating rules. It's an appropriate default for the vast majority.
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.
!!!! 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.
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?
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.
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.
- Status changed from Feedback to Resolved
Also available in: Atom
PDF