pfSense

The issue appears to be that these setting are only applied to TCP rules. This needs notation in the GUI.

Also, pf is capable of applying some of these options to UDP and ICMP traffic as well. So, functions as well as notations need to be added for rules of traffic type: TCP/UDP | UDP | ICMP

Currently, the following function is handling this, also found by phil.davis in filter.inc:

if (($rule['protocol'] "tcp") && ($type "pass")) {
... do advanced sate-related settings

Direct research on the issue, also from phil.davis:
From http://www.freebsd.org/cgi/man.cgi?query=pf.conf&sektion=5

pf(4) will also create state for other protocols which are effectively stateless by nature. UDP packets are matched to states using only host addresses and ports, and other protocols are matched to states using only the host addresses.

So at least some of the state limiting parameters can be used for UDP/ICMP also. But these ones only apply to TCP:

For stateful TCP connections, limits on established connections (connec-
     tions which have completed the TCP 3-way handshake) can also be enforced
     per source IP.

max-src-conn <number>
      Limits the maximum number of simultaneous TCP connections which
      have completed the 3-way handshake that a single host can make.
     max-src-conn-rate <number> / <seconds>
      Limit the rate of new connections over a time interval.  The con-
      nection rate is an approximation calculated as a moving average.

So it needs a bit of extra explanation and validation in the GUI to allow only the valid combinations of parameters to be entered.

Or better yet, since we already have elements that become visible or hide depending on the traffic type selected on the edit rule page, make the correct advanced options visible or hidden according to whether TCP/UDP, UDP, or ICMP is selected.

Then add code & option validation on the backend functions in filter.inc since that is where it is currently, unless it should be moved out of filter.inc all together?

If someone can update the ticket to "all versions" and "urgent" as I can't imagine this isn't also the case with every release up to this point, that would be awesome.

Keith Hough wrote:

Or better yet, since we already have elements that become visible or hide depending on the traffic type selected on the edit rule page, make the correct advanced options visible or hidden according to whether TCP/UDP, UDP, or ICMP is selected.

Then add code & option validation on the backend functions in filter.inc since that is where it is currently, unless it should be moved out of filter.inc all together?

Wups, make that "according to whether TCP/UDP, TCP, UDP, or ICMP is selected."

I have added pull requests https://github.com/pfsense/pfsense/pull/720 (Main) and https://github.com/pfsense/pfsense/pull/721 (2.1 branch) to validate the rule parameters on the GUI using the same checks that are applied in filter.inc when actually implementing the rules. That will make the current system self-validating without changing the actual behaviour.
Now there can be a discussion of which of these criteria to relax (e.g. allow TCP and UDP protocols...), in what version of pfSense to put the changes (Main for 2.2, or get it into 2.1 or?) and some testing to see that these state-based parameters actually work sensibly for some non-TCP protocols.

Commit request: https://github.com/ky41083/pfsense/commit/abb4614488bab34086c7c1adcf6748221644fc16

Corrected commit request for 2.1 branch: https://github.com/ky41083/pfsense/commit/a3ff93398a5cbec0e18960be36fd2fdc24cd5aa9

The extra flexibility allowing relevant state-related advanced options to be used on UDP and ICMP, in addition to TCP, is committed to 2.1 in:
https://github.com/pfsense/pfsense/commit/98f4043e939ab9e31215a0d9da252f06bca28a4b
https://github.com/pfsense/pfsense/commit/ee1577575981efbd36f1dffe251734f6aa12b621
There are corresponding commits to Master also.
Testers, please confirm that this is now "a good thing".