Problem with snapshot 3/31 16:19:49
-
Getteing there were error(s) loading rules: pf to: pfctl_rules -The line in question reads [0]: @ 2022-03-31 17:39:19
-
-
This update killed the packet filter also. It's just a router until its fixed for me. My uptime is 0.00000001% right now lol. It's because I test out every update, so mine is rebooting all the time. You win some you lose some. The stable version is probably a tank now with 99.99999 percent uptime. Mine running just the proxy till next try.
-
I'm on the same snapshot here but have no problems loading rules.
What is in
/tmp/rules.debug?What happens if you try a filter reload from Status > Filter Reload?
What shows up if you go to a shell prompt and try
pfctl -f /tmp/rules.debug?Anything in the system log?
You might try disabling or uninstalling packages temporarily to see if it's coming from a specific package.
-
I found one VM where I can reproduce this and there may be a temporary workaround.
The problem appears to be https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262971 which is a new issue with multiple identical rules in the ruleset.
The easiest way for that to happen on pfSense is from NAT reflection. Thus, if you disable NAT reflection and reboot, that may be sufficient to get the rules to load until we get a proper fix in today.
-
If disabling NAT reflection doesn't help, check for other completely identical rules in your ruleset:
# egrep -v '^#|^[[:blank:]]*$' /tmp/rules.debug | sort | uniq -c | grep -v '^ 1 'That should output only 100% duplicate lines. In my case they were from NAT reflection. If you have some other source, you may need to address it there (e.g. pfBlocker), though most firewall rules won't be identical since they have unique tracking IDs. So most likely this will come from an internally generated rule like NAT reflection or perhaps from a package.
-
@jimp Hello you asked about how the logs looked I still have it running in the faulted condition if you guys needed something.
-
I have not changed this however it is already disabled
-
@jimp said in Problem with snapshot 3/31 16:19:49:
egrep -v '^#|^[[:blank:]]*$' /tmp/rules.debug | sort | uniq -c | grep -v '^ 1 '
-
Is that
no nat on [...]rule a manual outbound NAT rule you have?If so, you have two of them, remove one.
Look in
/tmp/rules.debugand find the line(s) for those rules and see what section they are in.Also, once pf is in that bad state you have to reboot to recover. So fix the NAT rule(s) and then reboot.
-
@jimp I uninstalled all packages and reinstalled them all the same issue so far, the filter reload would fail. I originally had nat disabled I am turning on one to one to see if that changes anything. I don't remember it set to all disabled before this update.
-
This post is deleted! -
This post is deleted! -
This post is deleted! -
Please post the text and not screenshots. It's making it unnecessarily hard to follow.
Looking at the code it looks like it's from NAT reflection not outbound NAT. Is that a port forward for NTP you have? Is NAT reflection enabled globally or perhaps on just that rule?
-
@jimp You got it thanks for the help
here is your request this was the original settings, I have tried to delete the one line however it re adds
Outbound NAT rules (automatic)
Subnets to NAT
tonatsubnets = "{ 127.0.0.0/8 ::1/128 192.168.0.0/16 }"
nat on $WAN inet from $tonatsubnets to any port 500 -> 64.113.111.129/32 static-port
nat on $WAN inet6 from $tonatsubnets to any port 500 -> (mvneta0) static-port
nat on $WAN inet from $tonatsubnets to any -> 64.113.111.129/32 port 1024:65535
nat on $WAN inet6 from $tonatsubnets to any -> (mvneta0) port 1024:65535TFTP proxy
rdr-anchor "tftp-proxy/*"
NAT Inbound Redirects
rdr on mvneta1 inet proto { tcp udp } from 192.168.0.0/16 to any port $DNS -> 192.168.1.1
no nat on mvneta1 inet proto tcp from (mvneta1) to 192.168.0.0/16
nat on mvneta1 inet proto tcp from 192.168.0.0/16 to 192.168.1.1 port $DNS -> (mvneta1)rdr on mvneta1 inet6 proto { tcp udp } from any to any port $DNS -> ::1
rdr on mvneta1 inet proto udp from 192.168.0.0/16 to any port 123 -> 192.168.1.1
no nat on mvneta1 inet proto tcp from (mvneta1) to 192.168.0.0/16
nat on mvneta1 inet proto tcp from 192.168.0.0/16 to 192.168.1.1 port 123 -> (mvneta1)rdr on mvneta1 inet6 proto udp from any to any port 123 -> ::1
Setup Squid proxy redirect
rdr pass on mvneta1 inet proto tcp from any to !(mvneta1) port 80 -> 127.0.0.1 port 3128
rdr pass on mvneta1 inet proto tcp from any to !(mvneta1) port 443 -> 127.0.0.1 port 3129 -
This is my NAT for DNS and NTP
I force them to use the firewall
This setting has worked for some time now I get time from the firewall no matter what wan ip address a device requests for NTP. I had issues with time being jumped 15-20 mins without this nat setting for NTP, no clue why so I added a rule that let the firewall handle all NTP requests, after that no issues with time jumps
-
Do you have NAT reflection enabled globablly or on those rules? If so, disable it.
-
-
There is also a per-rule option on the individual port forwards. Is it enabled there?