Fixed it, but I don't know what I did. Maybe it was the Hendrick's martini... Unplugged it, let it sit, plugged it in, walked away, had a second martini, opened the GUI, voila!
@BigSnicker Pretty sure it's the lightweight SG-1100 calculating and updating the Traffic Graphs. Even on my VM on a quad-core, it pulls around 30% with the Traffic Graph widget updating every second. But low CPU numbers when monitored via SSH with the Dashboard closed.
Correct. It's a Mikrotik CRS328-24P-4S+. I can add the tag using /interface ethernet switch rule add vlan-id=2 ports=<ports> new-vlan-priority=3
As soon as I add that to the corresponding physical ports (on the switch) the VMs are on top of, it all magically starts working again.
@stephenw10 said in APCUPSD - No UPS page:
Could be. My guess would be that the FreeBSD port supports some subset of the data only. But testing against FreeBSD is the only way to know that. Or reading the code...
Steve
I just plugged in an older model APC UPS and it now works. The old model is a " Back-UPS ES 500". So, there is something different in the protocol between old and new that keeps apcupsd and NUT from working with the new UPS. BTW, I had previously used NUT with this old model and it worked fine. As I mentioned, the new UPS works fine with Linux.
@stephenw10 Found the problem. Somehow characters that don't show up got in there. Perhaps when I did a copy/past from the old config? Manually retyping fixed it. But unlike before, the entire path is required.
Resolved!
@Gertjan said in All system logs empty:
@MrSnuggles said in All system logs empty:
pfSense should be on the newest version (v4.0.11).
I advice you to ditch whatever you have and use the real pfSense : https://www.pfsense.org/download/
Oops I quoted the BIOS version (4.0.11) instead of the pfsense version (2.4.4). Should be as official as it gets. Otherwise I would be surprised
@jimp said in All system logs empty:
Go to the settings tab and click the button to reset all your log files.
Thanks! I had the same idea after reading what Steve pointed out about the logs being from 2017. Ran rm -rf /var/log and now the system is logging happily. I don't understand though what the problem was since the permissions look exactly the same now. At least I have logging back Thanks again!
It's old but should work fine. I can only think there must be some rogue configuration going on, something left in the config file from previous settings. But if that was the case the clean install should have resolved it.
The other thing is some low level conflict between the cards but I would expect that to follow the card not the assigned interface.
Steve
thank you, it working.
for archive this my custom rules:
drop tcp $EXTERNAL_NET any -> 1.1.1.2/32 any (msg:"Ignore all traffic"; sid: 1;)
drop udp $EXTERNAL_NET any -> 1.1.1.2/32 any (msg:"Ignore all traffic"; sid: 1;)
Yes, I'm not actually seeing an issue there besides the high RAM usage from Squid. It's not exhausting the RAM certainly.
Are you seeing errors in the system log or Squid log?
Steve
Ok, so I assume A to B is local traffic, not via VPN?
And B to C is also not via the VPN?
What speeds to you see from C to A compared with B to C? Is it the same A to C or C to B.
I would try testing directly between the pfSense firewalls using iperf3 on each both inside and outside the VPN to see if you can pin down the throttle point.
pkg install iperf3
rehash
Steve
@Stewart said in Broken unit won't fully boot:
pkg-static: Warning: Major OS version upgrade detected
That implies it is either running 2.3.X and has pulled in 2.4.X packages or is set the dev channel and is trying to pull in 2.5.X packages. You can probably recover it by doing this:
https://docs.netgate.com/pfsense/en/latest/install/upgrade-troubleshooting.html#upgrade-not-offered-library-errors
But it will be quicker, and cleaner, to just reinstall at this point.
The Suricata package had a bug in it at one point that meant log rotation was not working correctly. You had to go to the log management tab and save the default settings there to activate it. I imagine that's what you hit there.
Steve
You haven't added the address range or server address to the PPPoE server config.
I'm not sure I've ever tried running it on a numbered interface, certainly not WAN. You might need firewall rules to allow the traffic in. Though I don't see any required on my test box here to allow the PPPoE traffic you will need them on the PPPoE server interface to allow traffic inside the connections.
Steve
Alright.
We can do this :)
On for example Forefront TMG you would have created a rule saying that anything going to external is allowed and drop the rest. PFSense however doesn't have an external object so instead we will need two rules per network instead instead
First we need a Block rule that stops the unwanted traffic. Second we need an allow any rule that allows anything we haven't already blocked.
In your case you need a block rule as rule nr2 on LAN:
Source Any
Destination 192.0.0.129/25
You will need a Block rule on OPT1 to (before the allow any-any rule)
Source Any
Destination 192.0.0.1/25
Okay I ran out of ideas so I grabbed a backup of the config file from before I installed HAProxy and ACME and restored it.
Access is again granted to port 443. I will have to assume it was HAProxy but I only had set it up for port 80 and it was working. I was starting to work on 443 but everything for those backends and frontend was disabled. Also I completely disabled HAProxy and no difference.
Oh well. I will just start again with ACME and HAProxy and see what happens
Hi @PiBa
After a good night sleep, and some coffee, I discovered a domain override for https://www.yourdomain.tld/ in my DNS resolver. False alarm.
Thank you for your time.
Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.