Possibility to stop certain default block-rules from logging?

rgijsen

Hi, pfSense 2.7.0 in HA setup, running on Hyper-V. I know there have been multiple posts about CARP messages flooding the logs. Same in our environment, I litterly have 80 or 90% of our logs being blocked CARP to 224.0.0.18, from self. This results from the default rules being generated in /etc/inc/filter.inc:

function filter_process_carp_rules($log) {
	if (config_path_enabled('system','developerspew')) {
		$mt = microtime();
		echo "filter_process_carp_rules() being called $mt\n";
	}

	$increment_tracker = 'filter_rule_tracker';
	$lines = "";
	/* Only add CARP rules if there are CARP VIPs
	 * https://redmine.pfsense.org/issues/13908 */
	foreach (config_get_path('virtualip/vip', []) as $vip) {
		if (!empty($vip) &&
		    is_array($vip) &&
		    ($vip['mode'] == 'carp')) {
			$lines .= "\n# CARP rules\n";
			**$lines .= "block in {$log['block']} quick proto carp from (self) to any ridentifier {$increment_tracker()}\n";** 
			$lines .= "pass {$log['pass']} quick proto carp ridentifier {$increment_tracker()} no state\n";
			break;
		}
	}
	return $lines;
}

The ~~bold line~~ line marked with ** (bold not working in code it seems) creates the rule that floods our logs. Now, I think there is some discussion whether or not this is actually a L2 issue or not. I think this may occur because we run pfSense on Hyper-V, where the vswitch creates this 'issue'.

However, the environment is perfectly stable and working top-notch. So what I would like is to disable logging for that particular default rule. If I disable logging for default rules in the log-settings, and I would like to see the other blocks (which I do want to see) I'd need to setup seperate block-rules on all my interfaces I assume, which is a pain in the @$$. I tried creating a floating rule to prevent this logging, but it seemd internal rules are processed first, and as QUICK is enabled on this one, it never comes as far as my own floating rule.

So is there a way around this?

provels

@rgijsen
I had to do something like this to prevent a flood of IPv6 logs.
Back up the file or copy the line and comment out the original line.

In that line remove the string (and one space):

{$log['block']}

I don't think it will survive an upgrade. HTH and blow things up!

rgijsen

@provels I thought about that, but I haven't dared yet :) I tried disabling the default logging and create a floating default block rule with logging (the CARP block rule has been processed at this point) but that resulted in blocking way more than I wanted it to.

I'll try during off-hours, and report. Thanks!

provels

@rgijsen This is a note I made back when I was working on this, from a post here which I cannot seem to find. It was a reminder to copy off filter.inc before upgrades. All credit to the original poster, I just followed their recipe.

Found what *may* be a better solution.  Based on this:
https://doc.pfsense.org/index.php/How_can_I_edit_the_PF_ruleset

ssh to pfsense
vi /etc/inc/filter.inc
Find the two lines following:
                $ipfrules .= "block in {$log['block']} quick inet6 all tracker {$increment_tracker($tracker)} label \"Block all IPv6\"\n";
                $ipfrules .= "block out {$log['block']} quick inet6 all tracker {$increment_tracker($tracker)} label \"Block all IPv6\"\n";
In both of those lines remove the string (and one space):
{$log['block']}
Save and quit vi

Go back to pfsense UI and
1) remove the custom rule we added from previous posts
2) uncheck the "Allow IPv6" again
3) let pfsense rewrite it's rules

Now those default rules are back in place BUT without the log parameter.

rgijsen

@provels Thanks for the insights. I thought about removing that entry there, as I figured it was for logging, but I figured it might mess up the structure of the line. I thought there were a set number of parameters, and it would expect the log-thing there. Removing that would shift all parameters one position. But looking more closely to it, it doesn't work that way. It seems to interpret the values otherwise.

Thanks again, I'll let you know if it worked.

By the way, I wouldn't copy the edited file back after an update, but rather make the changes to the new file again. The filter.inc file might also have been updated with new or changed bits during an update.

rgijsen

Yes this worked! While I hate having to change at this low level, it's better than recreating the default block rules I guess. Thanks!