Can you just swap the LAN/WAN ports in the Interface assignments (and the cables) and see if the problem follows the swap?

Ok, so that's policy based IPSec (tunnel mode) at the pfSense end. I'm not familiar enough with PA to know if that screen confirms route vase there. It does appear to have tunnel interfaces which implies it might. The P2 policy you have configured there is only carrying traffic between the LAN subnet(10.3.93.X) and 192.168.5.0/24. Which means it isn't carrying traffic between 192.168.5.102 and 8.8.8.8 for example. I would confirm the PA is using route based IPSec and then switch pfSense to match. That way you can route whatever traffic you want across the tunnel. Otherwise you have to do this: https://docs.netgate.com/pfsense/en/latest/recipes/ipsec-s2s-route-internet-traffic.html And that can be inconvenient because it often over-matches and pulls traffic over the tunnel you do not want to be. Steve

@stephenw10 said in alias-subnet: It's the default value for a DHCP Alias IPv4 address. It gets saved in the config if you save a change to the WAN but does nothing unless you actually have an alias IP address in there too. [image: 1651758786050-screenshot-from-2022-05-05-14-51-27.png] Steve hello Stephenw10, Thank you very much for the quick reply. I wish you a good day.

@empbilly I don't know if you've tried this yet or not, but in the DHCP Leases page under the Status menu, you can easily (with a couple of clicks) add machines to the WOL list by clicking the little blue plus button in the Action column.

@maddy_in65 From what you've posted it seems like only outbound traffic to port 80 from the problem VLAN is failing. Maybe run grep ' 80 ' /tmp/rules.debug and look for something other than the standard "anti-lockout rule"?

Yes, if both those pfSense instances are running an otherwise default config that will work fine. So if it's not it's because of something you have changed. Firewall rules? Outbound NAT rules? WANs still using DHCP? Steve

Thank you @stephenw10 and @johnpoz this looks like it is working now. I assigned only one pool to NTP and now reach column shows 377 for four servers. So this is golden. Thanks again!

@stephenw10 Thanks, Steve. I reinstalled Snort and turned off blocking. So far, everything appears to be working fine. Bert

Yes I added the lines in the config. The PPP connection was established without problem and there are no errors in the log file. I haven't had outage since than, therefore I couldn't test the reconnect part.

In the end I wrote a very tiny shell script to check the ZFS status and put it into /usr/local/libexec/nagios/check_zfs_status.sh #!/bin/sh cmdzpool="/sbin/zpool" healthcheck=`$cmdzpool status -x | grep -c "all pools are healthy"` if [ $healthcheck -eq 1 ] then echo "ZFS Volumes OK" return 0 else echo "ZFS Volumes error." return 2 fi It's not the ideal solution since the check has to be installed manually but it's better than nothing.

Ah it dawns on me there is one thing I should mention so someone else doesn't get caught. ARP cache played a huge part in this and an accidentally left over rule in one of the firewalls as well. The firewalls were basically competing to be the gateway so things would get weird like a vm would boot up with a gw then a while later change to another. Once ARP cleared up, everything was fine.

Yes that should be fine but neither reached the speeds you were seeing to speedtest so it doesn't really give us any more information. If you can connect the pfSense WAN to something running an iperf server directly and test to that it removes any sort of restriction reaching it so any limitation left much be in one of the pfSense interfaces. As I said I do that sort of test all the time using another pfSense instance on the WAN. That way it hands out DHCP so the test device just works. Steve

@johnpoz I block doubleclick also they have some bad bugs in that system. I am glad to see I am not the only one.

Thanks guys for your answers!

@cool_corona said in What information is Netgate collecting?: @stephenw10 Then why is it uploaded to Netgate in the first place? It's doing that because the user told the firewall they wanted it to do that. It's for secure remote backups, and it's off by default and completely opt-in. Maybe they forgot they enabled it, or another user enabled it, but it was done by choice not by Netgate.

Hmm, you would not expect some minor packet loss to cause TCP connections to fail. You just see retransmissons. Unless all of those failures were happening at the same time so it times out. That would take a while though. This starts to look more like a duplicate IP or a packet loop. You can see that if you have a loop that's prevented by stp and it periodically resets. Removing one link from the lagg entirely might prove that. Steve

You may need to re-trigger it and check specifically then. If there's nothing at all in the DHCP logs it probably didn't try to run the dhclient at all. That usually means the WAN NIC was unlinked at the time (the ONT was booting) but became linked before pfSense finished booting failing trigger the usual linkup script. Steve

The system aliases for each interface (LANnet, WANnet etc) are only the actual interface subnet. So often your ISP will provide your WAN IP and subnet something like 1.2.3.4/29 or maybe only a single IP if it's PPP connection. WAN net is only the IPs in that /29. It's a common mistake with new users because many other firewalls with zone based filtering use the WAN 'zone' to mean the entire internet. Traffic routing from LAN via WAN or OpenVPN would depend on the system routing tables since the LAN rules do nor have any policy based routing on them (a gateway set). The system routing tables are usually updated by the OpenVPN client when it connects based on whatever the server passes it. Most commercial providers will pass a new default route. Often that's undesirable so you can set the OpenVPN client to ignore routes passed to it and use policy based routing instead. That's what I do. Steve

@stephenw10 said in Can't update battery date in NUT: Probably your UPS simply doesn't support it: Seems you might be correct: [2.6.0-RELEASE][admin@pfSense.localdomain]/root: upsrw apcups@localhost [battery.runtime.low] Remaining battery runtime when UPS switches to LB (seconds) Type: STRING Maximum length: 10 Value: 120 [input.sensitivity] Input power sensitivity Type: STRING Maximum length: 10 Value: medium [input.transfer.high] High voltage transfer point (V) Type: STRING Maximum length: 10 Value: 266 [input.transfer.low] Low voltage transfer point (V) Type: STRING Maximum length: 10 Value: 180 [ups.delay.shutdown] Interval to wait after shutdown with delay command (seconds) Type: STRING Maximum length: 10 Value: 20 [ups.delay.start] Interval to wait before (re)starting the load (seconds) Type: STRING Maximum length: 10 Value: 30 [2.6.0-RELEASE][admin@pfSense.localdomain]/root:

Yes, should be good now. Let us know if you see any further issues. Steve