Rule errors for icmp rules after upgrade to 2.3.3
-
I did disable syncing on the primary before upgrading the secondayr (still disabled right now when I upgraded the secondary). The primary is still at the previous 2.3.2_2
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 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:46 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:47 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:51 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:52 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:24:10 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:24:25 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:24:28
Rule after upgrade:
<rule><id><type>pass</type> <interface>wan</interface> <tag><tagged><max><max-src-nodes><max-src-conn><max-src-states><statetimeout><statetype>keep state</statetype> <os><protocol>icmp</protocol> <icmptype>echoreq</icmptype> <source> <address>ahRemoteManagement</address> <destination><address>ahWanVip</address></destination> <tracker>1463665353</tracker></os></statetimeout></max-src-states></max-src-conn></max-src-nodes></max></tagged></tag></id></rule>
The rule shows up in the main WAN rule list with as 'IPV4 ICMP echoreq' but if I go to the edif/view screen for the rule, It does not show that an icmp type is selected. It seems to default to all. I changed it in the gui to 'Echo request' and now the edit/view rule page does show that Echo request is selected. The raw rule in the config now looks like this:
<rule><tracker>1463665353</tracker> <type>pass</type> <interface>wan</interface> <ipprotocol>inet</ipprotocol> <tag></tag> <tagged></tagged> <max></max> <max-src-nodes></max-src-nodes> <max-src-conn></max-src-conn> <max-src-states></max-src-states> <statetimeout></statetimeout> <statetype>keep state</statetype> <protocol>icmp</protocol> <icmptype>echoreq</icmptype> <source> <address>ahRemoteManagement</address> <destination><address>ahWanVip</address></destination> <updated><time>1487799664</time> <username>someuser@1.1.1.1</username></updated></rule>
- I removed my username and ip and replaced it with someuser@1.1.1.1
EDIT: change previous version in first paragraph from 2.3.2_1 to 2.3.2_2 to show the correct previous version.
-
I can reproduce this. See issue https://redmine.pfsense.org/issues/7299
And specific fix for this problem: https://github.com/pfsense/pfsense/pull/3571
Note: There might be more weird things that could happen for old rules that come from a time before 'ipprotocol' was always saved in the rule config XML. I will also propose a wider fix…
The workaround here is to edit the rule, make sure to re-select the ICMP types that are wanted, and save. That re-writes the rule config with the 'ipprotocol' specifically set (as is done for new rules).
-
A more general fix that might cover other odd corner cases from old rules is in PR https://github.com/pfsense/pfsense/pull/3572
But that might also break something else??? -
Also, when the user edits an old rule that has no 'ipprotocol' tag in the XML, the ICMP types listed in the XML are not automagically selected on the rule edit GUI. So the user can easily press Save without noticing and lose the previously-selected values.
Issue: https://redmine.pfsense.org/issues/7300
PR: https://github.com/pfsense/pfsense/pull/3573