@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

@marinsnb said in CGNAT and pfSense: but my WAN gets a 100.xxx.xx.x IP according to my pfSense. Yeah 100.64/10 or 100.64-127.x.x is cgnat range. If that is what your isp is using there not much you can do about that other than contacting to see if they can give you a actual public IP, possible more $$.. Do you also get a IPv6 - that should be a global address and public, I would hope they would do a prefix delegation of /56 or /48 even which would allow for not natting when doing IPv6. Problem with cgnat, is even getting say a hurricane electric IPv6 tunnel isn't going to work.

Yes probably should be the CGNAT space, 100.64.0.0/10.

@cool_corona Thank you -- can you point me to any online discussion/thread where this is discussed so I can follow along?

@bassit said in Any ideas? dns gone rouge.: I hadn't changed anything in resolver or forwarder. Well pfsense was just resolving - that is how it is out of the box. I resolve for like 10 some years now, never an issue. What stopped working is your blocking it via your IPS is most likely.. Or you had an issue resolving "something" and noticed the log entries and went down a rabbit hole that has nothing to do with anything ;) If your just in IDS mode and monitoring and not blocking. DNS (resolving) can fail when you can not talk to a ns in the path to getting to the authoritative NS for the domain your wanting to lookup.. Or can not talk to the authoritative ns for some reason, or dnssec fails, etc. and you have that enabled (its enabled out of the box).. But if yoru going to forward you should uncheck that. When something fails to resolve, and your resolving - you need to figure out why.. dig +trace is good start to see what your having an issue talking too.. If your forwarding, and something fails - your at the mercy of why you didn't get an answer to where you forwarded too.

@johnpoz Done. Thanks for your help!

@st6 said in Connection Dropped After Gateway Down: I asked here and people told me that this feature will only clear states of the link that becomes down don't affecting other links connection. That's not true. It will kill states on all gateways when any gateway goes down. It's not enabled by default because it's very disruptive but can be helpful in some situations. When that feature was added it was not possible to kill states by gateway so it was all or nothing. Steve

@johnpoz wow thanks very much, i am new to pfsense so im not realy sure at what i am seeing, it seemed odd that something pre programmed would contain syntax that is wrong.

@stephenw10 - Your assumption is probably correct, the original install would have been done 5 years ago with whatever version was current at the time. And, I have not connected a monitor to it since. I also re-installed using the UEFI option and that's what it is in now. Still does not explain why it never booted after being shutdown. Guess we will never know, but thanks again for all your input and time. Greg

If it isn't running the ure(4) driver you may need to load the module. That may pass at full speed.

@stephenw10 said in NUT Question: It might be better to prevent the OMV shutting down until it really has to. This sounds like the best solution. Rather then shutdown the OMV (NUT Client) in 15 minutes set it to low battery, like the NUT Server, then both will shutdown together and hopefully both come back on when power is restored.

Looks like some things may have been missing from that post. But same question; what states do you see when you run these tests? @joeschmoe said in TLS pr_end_of_file_error (non proxy related): pr_end_of_file_error message in squid appears Where are you actually seeing that? In the Squid logs? Connections from the pfSense CLI should not go via Squid. If they are being redirected somehow that would show in the states created. Do you still see this issue if you disable Squid? Steve

Thanks a lot!

Mmm, the same port version though? 5.0.1? From what I can see that fix should be in 5.0.1_1 and that hasn't arrived in FreeBSD yet. How are you querying the agent?

@admintkh said in Hugh CPU Load after Upgrade to 2.6.0: https://redmine.pfsense.org/issues/12045 You mean these commits? b5d787d93b3d83f28e87e1f8cc740cb160f8f0ac 0020c845a086766b3315372f006363f8ad76ac54 d97753b5c8f1d32fbcdcbb0d129b49f808245865 3bea7b5b05f200df4cabee12e405b8feade16f0e 89d5cbb82294c8624e66f920d50353057ccab14b That's shouldn't be necessary or even possible in 2.6. Steve