Project

General

Profile

Actions
Copy link

Bug #11548

closed

"rule expands to no valid combination" error from port forward automatic rule mixing IPv4 and IPv6 elements

Added by Jonas Libbrecht about 3 years ago. Updated 8 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Rules / NAT
Target version:
-
Start date:
02/26/2021
Due date:
% Done:

0%

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

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

2021-02-20_23-21.png (94.4 KB) 2021-02-20_23-21.png screenshot NAT rules Jonas Libbrecht, 02/27/2021 03:19 AM
Actions
Copy link
 #2

Updated by Viktor Gurov about 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?

Actions
Copy link
 #3

Updated by Jim Pingle about 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.

Actions
Copy link
 #4

Updated by Jonas Libbrecht about 3 years ago

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@</username>
</updated>
<created>
<time>1613861672</time>
<username><![CDATA[user@</username>
</created>
</rule>

```

Actions
Copy link
 #5

Updated by Jonas Libbrecht about 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.

Actions
Copy link
 #6

Updated by Jonas Libbrecht about 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

Actions
Copy link
 #7

Updated by Viktor Gurov about 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

Actions
Copy link
 #8

Updated by Jim Pingle about 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.

Actions
Copy link
 #9

Updated by Marcos M 8 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.

Actions
Copy link

Also available in: Atom PDF