Todo #15220
closedHandle ``route-to`` and ``reply-to`` states when using the ``if-bound`` state policy
100%
Description
With the re-introduction of if-bound
as the default PF state policy, services on the firewall (which do not automatically add a route) bound to secondary WAN's will fail. This is due to route-to
outbound states being bound to the route interface (details on #12630).
For rules with reply-to
, outbound traffic doesn't match the state - presumably it only looks for the route interface (and not also the route-to
interface).
vmx2 tcp 10.0.10.30:8999 (192.168.1.253:8999) <- 198.51.100.227:56295 CLOSED:SYN_SENT [0 + 64240] [3309371906 + 1] age 00:00:25, expires in 00:00:12, 4:0 pkts, 240:0 bytes, rule 799 id: edb4ba6500000000 creatorid: af6c8b55 reply-to: 192.168.1.254@vmx2 @799 pass in quick on vmx2 reply-to (vmx2 192.168.1.254) inet proto tcp from any to <d_TEST:1> port = 8999 flags S/SA keep state (if-bound) label "USER_RULE: NAT TEST" label "id:1679170149" ridentifier 1679170149 [ Evaluations: 32 Packets: 75 Bytes: 4500 States: 1 ] [ Inserted: uid 0 pid 0 State Creations: 19 ] [ Last Active Time: Tue Jan 30 12:44:44 2024 ]
This essentially breaks anything that isn't simply a failover-only multi-WAN setup such as an OpenVPN server listening on a second WAN, port forwarding on a second WAN, and accessing the WebGUI on a second WAN.
Related issues
Updated by Marcos M 10 months ago
- Related to Todo #15173: Add global option to set default PF State Policy (if-bound vs floating) added
Updated by Marcos M 10 months ago
- Related to Feature #855: Ability to selectively kill states on gateway recovery added
Updated by Marcos M 10 months ago
- Related to Bug #12630: States are always created on the default gateway interface. added
Updated by Marcos M 10 months ago
- Related to Regression #13420: TCP traffic sourced from the firewall can only use the default gateway added
Updated by Marcos M 10 months ago
- Related to deleted (Regression #13420: TCP traffic sourced from the firewall can only use the default gateway)
Updated by Marcos M 10 months ago
- Related to deleted (Bug #12630: States are always created on the default gateway interface.)
Updated by Marcos M 10 months ago
- Status changed from In Progress to Pull Request Review
It seems the reply-to issue can only really be handled by using floating on the rule. This can be done on rule generation, or in PF itself:
https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/1134
Updated by Kristof Provost 9 months ago
- Status changed from Pull Request Review to Feedback
I've merged a pf change that fixed reply-to with if-bound states. It should mean that the above merge request is no longer required.
Updated by Jim Pingle 8 months ago
- Subject changed from Handle route-to and reply-to states when using the if-bound state policy to Handle ``route-to`` and ``reply-to`` states when using the ``if-bound`` state policy
- Release Notes changed from Default to Force Exclusion
Updated by Marcos M 8 months ago
- Related to Bug #15363: Reply traffic on a secondary WAN may be dropped when passed through dummynet added