pfSense

Jonas Libbrecht wrote:

There were error(s) loading the rules: /tmp/rules.debug:245: rule expands to no valid combination - The line in question reads [245]: pass in log quick on $WAN reply-to ( igb1 <ipv6_ip> ) inet6 proto { tcp udp } from any to <ipv4_ip> port 2455 >< 2459 tracker 1613566521 keep state label "USER_RULE: NAT Access Internet -> VALHEIM" @ 2021-02-20 22:58:49

Could you show this rule in the `/cf/conf/config.xml` file?

It's not the port range or NAT reflection, it's the fact that the rule says inet6 and uses an IPv6 gateway in reply-to but uses an IPv4 address as the destination, so it is invalid.

It would help to see the config.xml entry for the port forward in question and this associated automatic firewall rule.

Jim Pingle wrote:

It's not the port range or NAT reflection, it's the fact that the rule says inet6 and uses an IPv6 gateway in reply-to but uses an IPv4 address as the destination, so it is invalid.

It would help to see the config.xml entry for the port forward in question and this associated automatic firewall rule.

The rule was created via the GUI of version 2.4.5, this is a screenshot of the rules after the upgrade took place.

The conflicting line without redacting the ipv6 and ipv4: There were error(s) loading the rules: /tmp/rules.debug:245: rule expands to no valid combination - The line in question reads [245]: pass in log quick on $WAN reply-to ( igb1 fe80::2621:24ff:fed8:ce3f ) inet6 proto { tcp udp } from any to 172.16.16.12 port 2455 >< 2459 tracker 1613566521 keep state label "USER_RULE: NAT Access Internet -> VALHEIM"
@ 2021-02-20 22:58:49

I had to recreate the NAT rule but this is the current rule cfg:
```
<rule>
<source>
<any></any>
</source>
<destination>
<network>wanip</network>
<port>2456-2458</port>
</destination>
<ipprotocol>inet</ipprotocol>
<protocol>tcp/udp</protocol>
<target>172.16.16.12</target>
<local-port>2456</local-port>
<interface>wan</interface>
<descr><![CDATA[VALHEIM]]></descr>
<associated-rule-id>nat_60319328b3f103.19627776</associated-rule-id>
<updated>
<time>1613861672</time>
<username><![CDATA[user@<ipv4> (Local Database)]]></username>
</updated>
<created>
<time>1613861672</time>
<username><![CDATA[user@<ipv4> (Local Database)]]></username>
</created>
</rule>

```

It could be a case where the invalid rule is generated when the interface doesn't have IPv4 configured yet. I thought I added some safety checks to prevent mixing IPv4 and IPv6 elements in these cases but there may be other edge cases like this around.

At the very least, the code generating the rules should skip the rules in this state. Every element in the rule needs to be the same address family, so if the rule says inet then the src/dst/target must all be IPv4.

It doesn't seem possible for a rule that causes this error to be added in the GUI since input validation would catch mixed address families (also see here ); it may have been possible before related input validation was added years ago. At this point, I'd argue the error is desired since it alerts the user of an (presumably) old mis-configured rule. If the error can still be reproduced on current versions, the bug can be reopened.