Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Rule errors for icmp rules after upgrade to 2.3.3

    Scheduled Pinned Locked Moved Problems Installing or Upgrading pfSense Software
    4 Posts 2 Posters 1.2k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • A
      adam65535
      last edited by

      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.

      1 Reply Last reply Reply Quote 0
      • P
        phil.davis
        last edited by

        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).

        As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
        If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

        1 Reply Last reply Reply Quote 0
        • P
          phil.davis
          last edited by

          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???

          As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
          If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

          1 Reply Last reply Reply Quote 0
          • P
            phil.davis
            last edited by

            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

            As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
            If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.