SCTP Session Timeouts
-
Hello,
After upgrade from 23.09.1 to 24.03 there is a problem with managing sctp sessions in the firewall. We use a lot sctp connections where both ends use the always the same SCTP port and IP address.
In the scenario when there is an ABORT message from one of the endpoints, the firewall blocks new incoming INIT messages for 900 seconds. The session state in the GUI is 8:128 in that case.
Looking at the default SCTP timouts I assume that the session entered "SCTP Closing" state and the default timer for that state is 900s.- Shouldn't the session be in "SCTP Closed" or even be removed in that case? there will be no further messages after the ABORT message.
- I tried to change SCTP timeouts in the "System/Advanced/Firewall & NAT" menu,, but I failed. I can change every timeout except the ones related to SCTP (SCTP Opening,SCTP Established,SCTP Closing,SCTP Closed)
Hope someout would help.
Regards -
Is this perhaps a bug report you submitted?
https://redmine.pfsense.org/issues/15661#change-74029
If not, then it looks like someone else has recognized this issue and created a Redmine bug report on it.
-
@bmeeks The bug mentioned applies only to GUI problem. But SCTP state "SCTP Closing" after ABORT message is another. What should be the best sesion state after an ABORT? Maybe the session should be deleted at all?
-
@rafal-arciszewski said in SCTP Session Timeouts:
But SCTP state "SCTP Closing" after ABORT message is another. What should be the best sesion state after an ABORT? Maybe the session should be deleted at all?
Sorry, but I don't know the answer to that one. STCP is not something I'm very familiar with.
-
@rafal-arciszewski I'm on vacation until around the 12th, but in the mean time can you clarify a few things?
After upgrade from 23.09.1 to 24.03
Do you mean that you did not have this issue in 23.09.01 and did in 24.03?
We use a lot sctp connections where both ends use the always the same SCTP port and IP address.
So you're re-using both source and destination IP and port number? Why?
Shouldn't the session be in "SCTP Closed" or even be removed in that case?
This is going to be the same thing as a TCP closing session, basically to make sure than any in-transmit packets for the closed connection get caught.
-
After upgrade from 23.09.1 to 24.03
Do you mean that you did not have this issue in 23.09.01 and did in 24.03?
Yes. The problem started after the upgrade. I don't have possibility to check it in 23.09.1 again but I presume that either default SCTP timers were different or SCTP session state after an ABORT was different.
We use a lot sctp connections where both ends use the always the same SCTP port and IP address.
So you're re-using both source and destination IP and port number? Why?
We use a lot of telco equipment and in telco world the endpoints are configured usually with fixed IP and SCTP port. In my example endpointA is always using 10.102.81.36:36412 and endpointB is always using 192.168.99.22:36412.
When we restart endpointA, this endpoint sends ABORT message and then after ~3minutes it start to send INIT messages to reconnect. From firewall point of view this is exactly the same session and during this 900s timeout the firewall is blocking those messages.Shouldn't the session be in "SCTP Closed" or even be removed in that case?
This is going to be the same thing as a TCP closing session, basically to make sure than any in-transmit packets for the closed connection get caught.
So the only way is to decrease the SCTP closing timeout? The bug report is already solved (will be included in 24.08), but is there any other way to change this timeout (by modifing manually config.xml perhaps?) I tried to use session timout in the firewall rule but is also seems not to be working with SCTP.
-
@rafal-arciszewski I've added https://cgit.freebsd.org/src/commit/?id=82e021443a76b1f210cfb929a495185179606868 to cope with this.
The TCP path already had a similar thing for similarly broken TCP stacks.It'll be part of the upcoming plus release too.
-
@kprovost Thank you very much!
