Bug #11548
closed"rule expands to no valid combination" error from port forward automatic rule mixing IPv4 and IPv6 elements
0%
Description
After a upgrade from 2.4.5 (pfsense FE) to 21.02 (the new pfsense+), the router (Netgate SG-4860) goes on all networks in DEFAULT DENY ALL and ignores all the configured firewall rules.
- I had to connect to the console and disable the firewall via pfctl d After trying to connect to the gui on the configured network, it did not work and I had to visit the gui via the LAN network.
- The following messages popped up on the gui, it appears to be that after the upgrade, pfsense cannot read 1 NAT rule due to a parsing error:
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
- I removed the conflicting line in question and everything worked again.
I think it had something to do with the port range being specified in the NAT rule, because I had several others configured but this was the only one that was giving issues.
Files
Updated by Jonas Libbrecht over 3 years ago
Updated by Viktor Gurov over 3 years ago
- Status changed from New to Feedback
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?
Updated by Jim Pingle over 3 years ago
- Project changed from pfSense Plus to pfSense
- Subject changed from Pfsense goes in deny-all after upgrade from from 2.4.5 to 21.02 (pfsense+) due to parsing error in NAT table to "rule expands to no valid combination" error from port forward automatic rule mixing IPv4 and IPv6 elements
- Category changed from NAT Reflection to Rules / NAT
- Target version changed from 21.02 to CE-Next
- Affected Plus Version deleted (
21.02) - Affected Version set to 2.5.0
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.
Updated by Jonas Libbrecht over 3 years ago
- File 2021-02-20_23-21.png 2021-02-20_23-21.png added
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@
</updated>
<created>
<time>1613861672</time>
<username><![CDATA[user@
</created>
</rule>
```
Updated by Jonas Libbrecht over 3 years ago
When I look at the /tmp/rules.debug at this moment. I see the (recreated) rule in question has been assigned a private pppoe ipv4 address.
pass in quick on $WAN reply-to ( pppoe0 <ipv4> ) inet proto { tcp udp } from any to 172.16.16.12 port 2455 >< 2459 tracker 1613861672 keep state label "USER_RULE: NAT VALHEIM"
As I do not tinker with the config in place, and only perform changes via the GUI, I can only assume the GUI has pushed a mistake somewhere.
Updated by Jonas Libbrecht over 3 years ago
Jonas Libbrecht wrote:
When I look at the /tmp/rules.debug at this moment. I see the (recreated) rule in question has been assigned a private pppoe ipv4 address.
pass in quick on $WAN reply-to ( pppoe0 <ipv4> ) inet proto { tcp udp } from any to 172.16.16.12 port 2455 >< 2459 tracker 1613861672 keep state label "USER_RULE: NAT VALHEIM"
As I do not tinker with the config in place, and only perform changes via the GUI, I can only assume the GUI has pushed a mistake somewhere.
FYI pppoe0 is igb1
Updated by Viktor Gurov over 3 years ago
still unable to reproduce, works fine for me (pppoe0 is vtnet2 with DHCP6):
pass in quick on $SYNC reply-to ( pppoe0 10.34.5.6 ) inet proto { tcp udp } from any to 172.16.16.12 port 2455 >< 2459 tracker 1614420623 keep state label "USER_RULE: NAT VALHEIM"
Please provide more information on the configuration of your WAN interface
Updated by Jim Pingle over 3 years ago
- Status changed from Feedback to New
- Priority changed from High to Normal
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.
Updated by Marcos M 12 months ago
- Status changed from New to Closed
- Target version deleted (
CE-Next) - Affected Architecture deleted (
amd64)
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.