Advanced Options - Multiple State / Connection Controls Not Working

ky41083

Also, while I'm on that train of thought, I have also tried every other state limiting option and the established connections limiting option under "Advanced Options" and either all of them seem to have an effect (with the older snapshots) or none of them seem to have an effect (with the latest snapshots, at least a months worth or so).

kejianshi

The newer ones have an effect for me. They break my connections rather than limiting them.

ky41083

The absolute only thing I have had consistent success with, if you can call it that, is globally limiting the number of sessions. But as I said in my first post, this disrupts LAN services, especially internal DNS.

ky41083

Here is a copy of my /tmp/rules.debug, IP's masked, quickly proofed, IP masks should be consistent.

It does indeed appear that those limits are not being applied to any rules.

Edit: With those values in all 4 fields (Maximum state entries this rule can create, Maximum number of unique source hosts, Maximum number of established connections per host, Maximum state entries per host) this is the result from /tmp/rules.debug:

pass in quick on $LAN inet from 192.168.1.0/24 to ! $PrivateIPv4 label "USER_RULE: Session Limit Internet Traffic"

Same is true with the rule on the WAN interface, no additional parameters appear.

rules.debug.txt

kejianshi

Its strange that it applies to nothing.
Whenever I've attempted to apply a limit to the port associated to the port that forwards to my mjpeg tilt/pan cameras, it has effectively killed the port. I've applied connection/second and max states and both have had an effect that feels like a DOS attack. The ports just seem to work rarely when I apply limits. It must be affecting some parameter somewhere.

kejianshi

I've actually checked this. I have access to computers all over the globe (I do some admin here and there) and I have checked the effects of those settings outside my networks. It makes a difference. Not a good difference or expected difference, but a difference never the less.

kejianshi

Don't get discouraged. Explain your findings. I'd love to know why this isn't working as expected.

ky41083

Not discouraged, just waiting to see if a dev will notice and chime in. Will most likely create a bug report on the issue tracker if nothing that makes solid repeatable sense comes up first.

Clearly none of the values are being applied at all, not even in the wrong location, according to the /tmp/rules.debug log.

kejianshi

I also had same feeling as you, but I've been too busy to dig into the "why" of it the way you have.
I think that you are correct that its not working as advertised.
Do you have a proposed fix? Can you see where the failure is?

kejianshi

Have you done a pfctl -sa dump into a file then apply a rule and pfctl -sa into a seperate file and compare the files?
See if there are differences?

ky41083

The failure is the script that reads / parses the saved options and turns them into PHP commands.

Yes, I could find it. No, I couldn't fix it without about a days worth of Googling for the correct way to parse / implement it on the command line and massaging it all together.

That is why I would just submit a bug in the issue tracker, the devs know far better than me off hand, what script specifically processes or is supposed to process these options, and the proper way to code in the commands to implement the options properly again.

For me, it's 2:35am and time to relax until tomorrow ;-)

kejianshi

I'll check and see what differences I see after another beer (-: Then rest.

ky41083

According to rules.debug, after applying a Maximum new connections / per second(s) value of 704 per 5 seconds it, nor any of the other settings under the "Advanced Options" section appear, the rule remains as follows:

pass in quick on $LAN inet from 192.168.1.0/24 to ! $PrivateIPv4 label "USER_RULE: Session Limit Internet Traffic"

Update: Running - pfctl -sa | grep "704" - at the command line returns absolutely nothing.

kejianshi

That is weird. Must be broken.

phil.davis

filter.inc

	$noadvoptions = false;
	if(isset($rule['statetype']) && $rule['statetype'] <> "") {
		switch($rule['statetype']) {
			case "none":
				$noadvoptions = true;
				$aline['flags'] .= " no state ";
				break;

If the state type (another advanced rule option) is set to "none" then the "Advanced Options" settings on the rule do not apply. That is the only obvious way I see that the code can bypass putting max-src-states and similar into the pf rule.

kejianshi

I've tried this last night with beer and today without and got the same results.

So, this time I'm only applying 853 connections / 1 second then doing a filter reload.
Checked to make sure its still "keep state"

pfctl -sa | grep "853"
pass in quick on nfe0 reply-to (nfe0 78.22.113.1) inet proto tcp from any to 192.168.13.1 port = 49132 flags S/SA keep state (source-track rule, max-src-conn-rate 853/1, overload <virusprot>flush global, src.track 1) label "USER_RULE: NAT 49132 Stunnel to Foscam"

It is making changes to PF on my version. If same thing in 2.1 doesn't end up in PF rules it must be broken.
Mine is 2.03</virusprot>

ky41083

Ok, so just for the record, you're on 2.0.3-RELEASE? and it's working (you're getting something anyways).

I'm on 2.1-RC0 (i386) built on Thu Jul 18 21:59:09 EDT 2013 (pfSense-2.1-RC0-2g-i386-nanobsd_vga-upgrade-20130718-2159.img.gz)

@phil.davis:

filter.inc
	$noadvoptions = false;
	if(isset($rule['statetype']) && $rule['statetype'] <> "") {
		switch($rule['statetype']) {
			case "none":
				$noadvoptions = true;
				$aline['flags'] .= " no state ";
				break;
If the state type (another advanced rule option) is set to "none" then the "Advanced Options" settings on the rule do not apply. That is the only obvious way I see that the code can bypass putting max-src-states and similar into the pf rule.

The state type on all of my rules in question (and the rest to be honest) are all set to the default value of "keep state", so by that function all of the advanced options I have set should be applied on the backend, and they are not :P

So, bug submittal time ;)

phil.davis

I looked further up the code block:

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

So this is only actioned for rules that are for protocol TCP.
If protocol is "all" it won't put the advanced settings in.
I guess that is reasonable, states are only TCP things, but for protocol "all" it could first write a TCP rule with the advanced settings then another generic rule for everything else (UDP, ICMP…). Or at the GUI could give an error message when saving, telling you that these advanced settings are only for protocol TCP.

ky41083

Submitted to Redmine, can follow up at:

https://redmine.pfsense.org/issues/3098

ky41083

@phil.davis:

I looked further up the code block:
	if (($rule['protocol'] == "tcp") && ($type == "pass")) {
... do advanced sate-related settings
So this is only actioned for rules that are for protocol TCP.
If protocol is "all" it won't put the advanced settings in.
I guess that is reasonable, states are only TCP things, but for protocol "all" it could first write a TCP rule with the advanced settings then another generic rule for everything else (UDP, ICMP…). Or at the GUI could give an error message when saving, telling you that these advanced settings are only for protocol TCP.

Ahh that's starting to make sense ;D Sweet, and I agree, it should at LEAST be notated that they will ONLY apply to TCP rules. Going to test now…

Update: These options should be applied on the backend for UDP also at the very least, and honestly for any protocol that can make a state table entry. Outgoing UDP can cripple a router, in the session table sense, in a matter of seconds…. we need more control here, and I believe pf is more than capable of this.