Problem with snapshot 3/31 16:19:49

JonathanLee

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.

jimp

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.

jimp

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.

jimp

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.

JonathanLee

@jimp Hello you asked about how the logs looked I still have it running in the faulted condition if you guys needed something.

JonathanLee

@jimp

I have not changed this however it is already disabled

JonathanLee

@jimp said in Problem with snapshot 3/31 16:19:49:

egrep -v '^#|^[[:blank:]]*$' /tmp/rules.debug | sort | uniq -c | grep -v '^ 1 '

jimp

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.debug and 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.

JonathanLee

@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.

JonathanLee

This post is deleted!

JonathanLee

This post is deleted!

JonathanLee

This post is deleted!

jimp

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?

JonathanLee

@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:65535

TFTP 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

JonathanLee

@jimp

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

jimp

Do you have NAT reflection enabled globablly or on those rules? If so, disable it.

JonathanLee

@jimp

Network Address Translation Settings for Firewall

All is disabled

jimp

There is also a per-rule option on the individual port forwards. Is it enabled there?

jimp

Also your port forward target should really be 127.0.0.1 and not 192.168.1.1, assuming 192.168.1.1 is the LAN address of the firewall.

JonathanLee

@jimp

Firewall rules