#
e4f2733d |
| 09-Jan-2025 |
Kristof Provost <kp@FreeBSD.org> |
pf: add 'allow-related' to always allow SCTP multihome extra connections
Allow users to choose to allow permitted SCTP connections to set up additional multihomed connections regardless of the rules
pf: add 'allow-related' to always allow SCTP multihome extra connections
Allow users to choose to allow permitted SCTP connections to set up additional multihomed connections regardless of the ruleset. That is, allow an already established connection to set up flows that would otherwise be disallowed.
In case of if-bound connections we initially set the extra associations to be floating, because we don't know what path they'll be taking when they're created. Once we see the first traffic we can bind them.
MFC after: 2 weeks Sponsored by: Orange Business Services Differential Revision: https://reviews.freebsd.org/D48453
show more ...
|
#
c22c9879 |
| 03-Dec-2024 |
Kristof Provost <kp@FreeBSD.org> |
pf: fix potential NULL dereference in SCTP multihome handling
When processing an SCTP ASCONF we re-run the rules processing to check if the new state should be allowed as well. We used to do so agai
pf: fix potential NULL dereference in SCTP multihome handling
When processing an SCTP ASCONF we re-run the rules processing to check if the new state should be allowed as well. We used to do so against the 'all' interface, to allow new connections to use any interface.
This is problematic for two reasons, the first being it may unexpectedly bypass interface restrictions. The more important one is that it can trigger panics. If the ruleset contains a rule which filters on interface group we'd attempt to process the group list for the 'all' interface. As this isn't a real interface it doesn't have an associated struct ifnet, and we end up dereferencing a NULL pointer.
Solve this by not overriding the interface, instead leaving the physical interface the SCTP ASCONF arrived on. This implies that we may end up binding to that interface (if if-bound), and thus denying traffic on other interfaces. Users can allow this anyway by setting 'state-policy floating' on the relevant SCTP rules. This arguably better reflects user intent as well. That is, we'll consider SCTP multihomed states to be floating if we're in floating mode, and if-bound if we're if-bound.
Update the test cases to account for this, while adding a "pass on lo" (i.e. pass on an interface group") rule to provoke this issue. Add separate test cases for the floating and if-bound scenarios.
Reported by: Franco Fichtner <franco@opnsense.org> MFC after: 3 weeks Sponsored by: Orange Business Services
show more ...
|
Revision tags: release/14.2.0, release/13.4.0, release/14.1.0, release/13.3.0 |
|
#
0fe663b2 |
| 16-Nov-2023 |
Kristof Provost <kp@FreeBSD.org> |
pf: always create multihomed states as floating
When we create a new state for multihomed sctp connections (i.e. based on INIT/INIT_ACK or ASCONF parameters) we cannot know what interfaces we'll be
pf: always create multihomed states as floating
When we create a new state for multihomed sctp connections (i.e. based on INIT/INIT_ACK or ASCONF parameters) we cannot know what interfaces we'll be seeing that traffic on. Make those states floating, irrespective of state policy.
MFC after: 1 week Sponsored by: Orange Business Services
show more ...
|
Revision tags: release/14.0.0 |
|
#
483d5c40 |
| 10-Oct-2023 |
Kristof Provost <kp@FreeBSD.org> |
pf tests: ensure that we generate all permutations for SCTP multihome
The initial multihome implementation was a little simplistic, and failed to create all of the required states. Given a client wi
pf tests: ensure that we generate all permutations for SCTP multihome
The initial multihome implementation was a little simplistic, and failed to create all of the required states. Given a client with IP 1 and 2 and a server with IP 3 and 4 we end up creating states for 1 - 3 and 2 - 3, as well as 3 - 1 and 4 - 1, but not for 2 - 4.
Check for this.
MFC after: 1 week Sponsored by: Orange Business Services Differential Revision: https://reviews.freebsd.org/D42362
show more ...
|
#
97340b68 |
| 05-Sep-2023 |
Kristof Provost <kp@FreeBSD.org> |
pf tests: extend SCTP tests to test state removal through ASCONF
pf can now mark shut down multihomed connections shutting down. Verify that pf does the right thing.
MFC after: 3 weeks Sponsored by
pf tests: extend SCTP tests to test state removal through ASCONF
pf can now mark shut down multihomed connections shutting down. Verify that pf does the right thing.
MFC after: 3 weeks Sponsored by: Orange Business Services
show more ...
|
#
1a28d5fe |
| 02-Aug-2023 |
Kristof Provost <kp@FreeBSD.org> |
pf tests: basic SCTP multihoming test
The SCTP server will announce multiple addresses. Block one of them with pf, connect to the other have the client use the blocked address. pf is expected to hav
pf tests: basic SCTP multihoming test
The SCTP server will announce multiple addresses. Block one of them with pf, connect to the other have the client use the blocked address. pf is expected to have created state for all of the addresses announced by the server.
In a separate test case add the secondary (client) IP after the connection has been established. The intent is to verify the functionality of the ASCONF chunk parsing.
MFC after: 3 weeks Sponsored by: Orange Business Services Differential Revision: https://reviews.freebsd.org/D41638
show more ...
|