Problem with snapshot 3/31 16:19:49
-
@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.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.
-
@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?
-
Also your port forward target should really be
127.0.0.1
and not192.168.1.1
, assuming192.168.1.1
is the LAN address of the firewall. -
Firewall rules
-
@jimp said in Problem with snapshot 3/31 16:19:49:
127.0.0.1
correct to loopback address
filter reload failed at same point as before with loopback address
-
Did you reboot after making that change? Once you get the error you have to reboot to know if it's fixed. Also check and see if those
no nat on
rules are still present. -
I have to wait for 2 hours to do a reboot I am at work and the firewall must be up for 2 hours. I have changed the NTP and DNS to use the loopback 127, the no nat rules still show in debug if you delete them they return. Thanks I will reboot at 11:10am
-
OK, I see the real source of your duplicate rules now and I can replicate it here. Your destination on those port forwards is Any and it should not be set to that. You should set that to ! LAN address (so check the Invert Match box for the destination and then set the destination to LAN Address)
As described in the docs:
https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html