[Solved] Syntax error in rules.debug after upgrading to 2.4.3-p1
-
After upgrading my installation from 2.4.2 to 2.4.3-p1 I ran into the bug where filters would fail to load due to a missing gateway netmask in rules generated by filter.inc. The configuration has remained unchanged over multiple version upgrades with no issues.
This is the exact error notification I'm getting (IP redacted):
1:14:12 There were error(s) loading the rules: /tmp/rules.debug:198: syntax error - The line in question reads [198]: pass out route-to ( em1 [WAN IP] ) from to !/ tracker 1000009061 keep state allow-opts label "let out anything from firewall host itself"
I verified that filters.inc has the additional checks proposed here and here. I'm getting the same error with the patch reverted.
I managed to work around the problem by commenting out line 3623 in filter.inc:
$ipfrules .= "pass out {$log['pass']} route-to ( {$ifcfg['if']} {$gw} ) from {$vip['ip']} to !" . gen_subnet($vip['ip'], $vip['sn']) . "/{$vip['sn']} tracker {$increment_tracker($tracker)} keep state allow-opts label "let out anything from firewall host itself"\n";
It appears the value of $vip['sn'] and the output of gen_subnet($vip['ip'], $vip['sn']) come up empty, resulting in an invalid rule with netmask !/.
Unfortunately I'm not very familiar with the inner workings of pfSense, so I'm not quite sure what the actual problem is. Is the correct solution to add checks for empty/invalid values of $vip['sn'] and/or $vip['ip'], or are the empty values of $vip['sn'] or $vip['ip'] the real issue here?
EDIT: Problem solved. I noticed I had a virtual ip (ip alias) configured with no address that caused the invalid filter to be generated. I don't recall creating the ip alias, but it is possible I did it by accident at some point. Either way, I'm happy to have the issue resolved. Sorry for the false alarm, everyone.
EDIT2: Attached a patch to validate virtual ip addresses before rule creation.
-
I experienced the same issue after upgrading from 2.4.3 to 2.4.3-p1. Interestingly, I couldn't find any virtual IP without an IP address. I checked the config.xml as well and everything looked fine.
I have applied the same patch to fix the issue in the meantime.
-
The problem OP hit is unusual but should also be fixed by a commit I pushed a few moments ago. There are others hitting a similar issue as well but it has a much different cause:
See https://forum.pfsense.org/index.php?topic=147879.msg803696#msg803696 and https://redmine.pfsense.org/issues/8518
