Bug #7299


Error loading rules for old rule with ICMP type specified

Added by Phillip Davis over 7 years ago. Updated over 7 years ago.

Rules / NAT
Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


1) Have an old config with a rule that specifies Protocol ICMP and ICMP type "Echo Request" (for example)
The old rule should be from a previous version where:
was not stored in the rule config XML.
The rule must not have a gateway specified, and must not be on a WAN-interface that has an IPv4 address (if either of these conditions are true, then the rule is written with an IPv4 gateway specified, or a reply-to clause with an IPv4 address - which seems to allow pf to deduce that it is an "inet" rule)
2) Use the rule in a system upgraded to 2.3.3

Errors are reported like:
There were error(s) loading the rules: /tmp/rules.debug:247: must indicate address family with icmp-type/code - The line in question reads [247]: pass in quick on $WANIF proto icmp from $ahRemoteManagement to $ahWanVip icmp-type echoreq tracker 1463665353 keep state label "USER_RULE: ICMP monitoring"
@ 2017-02-22 16:22:43

See forum

Actions #1

Updated by Phillip Davis over 7 years ago for minimal fix to this particular problem.

Actions #2

Updated by Phillip Davis over 7 years ago has a more general fix that should catch any other ways that rules from old configs can generate pf rules that are missing the 'inet' keyword and then cause problems.
Of course this more general fix needs some thought about if there is some other corner case that will now cause a problem.

Actions #3

Updated by Grischa Zengel over 7 years ago

The worst thing is that there are no rules loaded and the pfsense is unusable.

Actions #4

Updated by Phillip Davis over 7 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100
Actions #5

Updated by Renato Botelho over 7 years ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF