History log of /freebsd/tests/sys/netpfil/pf/sctp.py (Results 1 – 6 of 6)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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 ...