Removing spurious rules that don't show in the GUI
-
My firewall (Netgate XG-7100 in HA with a second identical device) is complaining a lot about the following:
There were error(s) loading the rules: /tmp/rules.debug:116: syntax error - The line in question reads [116]: nat on lagg0.22 proto tcp from 192.168.100.0/24 to 172.16.1.10 port -> (lagg0.22)
This only started at the beginning of this week and I cannot see any matching NAT or firewall rule so I went to the shell. Under # NAT Inbound Redirects I have the following rules:
nat on lagg0.22 proto tcp from 192.168.100.0/24 to 1.1.1.1 port -> (lagg0.22)
no nat on lagg0.22 proto tcp from (lagg0.22) to 192.168.100.0/24
no nat on lagg0.22 proto tcp from (lagg0.22) to 192.168.100.0/24
block drop in log on ! lagg0.22 inet from 192.168.100.0/24 to any
nat on lagg0.22 proto tcp from 192.168.100.0/24 to 1.1.1.1 port -> (lagg0.22)These are dotted in amongst the port forwarding rules - all the others are listed in the same order as the GUI but these ones are not.
lagg0.22 is the WAN interface so there shouldn't be any nat rules relating to it, even if there was they should be in the NAT section of the rules not the port forward section and those rules refer to them as $WAN not by the VLAN
The WAN interface is set on 192.168.100.1 and there are two rules that I've changed an internal IP address to 1.1.1.1From what I understand there is no point removing the entries from /tmp/rules.debug as that is not the permanent settings location. Easyrules is just for adding rules rather than removing specific ones.
I can't find any reference as to how to remove these spurious rules nor figure out how they got there. Any advice? -
Those would be rules for NAT reflection
-
Thank you for the reply @jimp , actually NAT reflection was turned off.
I spotted that this morning and turned it on because that was an oversight. These rules however are there from before NAT reflection was enabled.
There are no similar rules for other interfaces - I'd have thought the NAT reflection rules would have been on the LAN interface not the WAN? -
You'll only get those rules from NAT reflection, so it must still be on somewhere. Either under System > Advanced on the Firewall/NAT tab or on the rule itself. Also under the NAT reflection options, you must have Enable automatic outbound NAT for Reflection checked.
-
This post is deleted! -
@jimp I posted saying the rules had gone away. I only checked the output of pfctl rather than /tmp/rules.debug -they are still there.
NAT reflection is set to system default in all rules and disabled in advanced. There are no reflection rules for any other rules just these ones and they won't go away.
-
So they only show in
pfctl
or they only show in/tmp/rules.debug
?Is something else causing your ruleset to fail loading? Try
pfctl -f /tmp/rules.debug
and see if it still gives you an error. -
@jimp They only show in /tmp/rules.debug with the exception of one:
block drop in log on ! lagg0.22 inet from 192.168.100.0/24 to any
This shows in the output of pfctl -sr
That rule is likely blocking all of my WAN traffic if I read it correctly.The only other interface that has a similar rule is the HA Sync interface (lagg0.40)
-
No, that's not related. It's an anti-spoofing rule. Basically says drop traffic if it enters another interface but claims to be from your WAN subnet.
-
What exactly is in your
/tmp/rules.debug
file that you are questioning now, and in which sections of that file? -
@jimp ok thanks, I'm not sure why it is on both the WAN and the SYN interfaces though.
It still leaves me with the other rules - two of which have errors because the have the command word "port" without actually specifying a port.
Apologies for all the questions - I've spent so long arguing with OpenVPN and Amazon AWS that I'm probably not spotting the obvious any more when it comes to these routers.
-
So the main issue is that I'm getting errors in the GUI
There were error(s) loading the rules: /tmp/rules.debug:116: syntax error - The line in question reads [116]: nat on lagg0.22 proto tcp from 192.168.100.0/24 to 1.1.1.1 port -> (lagg0.22) @ 2019-03-13 14:14:38
I assume that this is because the actual port value is missing so whatever is adding the rule is adding it wrongly.
The same rule exists further up with the port specified.Assuming all the other rules aren't actually creating any problems despite the fact there is no reflection enabled then there's at least that one.