You are seeing that cert error in Windows when trying to access the other firewall GUI across the VPN? Are you accessing by IP directly or hostname? Steve

@edgerouter I have the computer described in my sig. Works well.

You could remove them but they are only used as a fallback by default. And they look to be responding fine. If you check the DNS settings in System > General Setup there is a field for 'DNS Resolution Behavior'. By defailt that is set to use local (Unbound on the firewall) and fallback to remote. The remote servers there are 1.1.1.1 and 8.8.8.8, it doesn't appear to be pulling any additional servers on the WAN via DHCP. I would upgrade to 2.5.2. There are a number of big fixes there over 2.5.1. Steve

@duja You could try suppressing them in the arpwatch gui [image: 1634157041744-suppress.jpg] But that won't remove your kernel arp entries.

Removing the 'block private networks' would not have been what solved that. That rule blocks incoming connections which are sourced from private subnets. It's applied on the WAN directly because you would usually never see traffic from private subnets there. The only time you would, and might want to pass it, would be from a client connecetd to the ISP router directly. Importantly though that rule, on WAN, never blocks outgoing connections or replies to them. Steve

https://docs.netgate.com/pfsense/en/latest/general/sell-pfsense.html

Yeah I would also try enabling DHCP on OPT1 and setting a client to use it. That will prove you have a good layer 2. DHCP traffic is always allowed. If it then pings correctly the static client setup was probably incorrect somewhere. Steve

Nice.

@deanfourie said in pfSense constantly crashing: Could this really cause something so catastrophic like a kernel panic? I adivse you to make this a priority task : Have a look at what's been said about 'realtek' for 'serious' applications like routers. I've no solid proof, but their is this common knowledge that you should stay away from this brand, just to be on the safe side. Realtek over USB ? That's like playing russish roulette with 5 bullets in the 6 chambres, instead of one bullet. Ethernet over USB : that's just a big nono in your situation. If it works, ok, good for you. But that kind of hardware should be removed if you suspect issues. So : first go native, classic bare bone : a device with two (or more) real NIC's. test drive that. If still issues, then you know the device (drive or motherboard or power) has an issue. Don't do tests with realtek or USB NICs nearby.

@denverdesktopssupport You can simply set up a second VPN and enable or disable them whenever you want.

@stephenw10 I actually just updated to 2.5.2, but the notification for the crash report was still there so I decided to post it here. Should I clear it and hope for the best?

@stephenw10 @stephenw10 said in FreeRADIUS 3.0.22 has a bug.: That was lucky. It could easily have not worked with 2.5.2. Well, between me and you, it did not work the first time because I had forced a package repository update: pkg update -f Doing that undid the modification I had done to the pfSense.conf file. So I edited the file a second time and it worked.

@deanfourie said in Interface Timer Suggestion?: should I still use relative paths in cron? Yes, use the full path. That's the most common reason custom cron jobs fail. The cron user does not have the same paths as root which is what the command prompt runs as. Steve

@jhparizona Google "free computer". I was surprised at the result. You may find what you need. Ted

What I can say, while I am not a "fan" of breaking the L2 barrier with such discovery. There have been some recent mdns questions. And easy way for me to test that mdns via avahi is working is just my iphone using airprint. Which printer and client are being on different vlans. Can tell you it works - I setup avahi, my iphone can discovery and print to the printer.. If I also allow communication on the vlan to actually talk to the printer. As @stephenw10 mentions.

With an apparent bandwidth reduction that high the first thing I would do is check the port status in Status > Interfaces to make sure both are linked at the expected 1G full duplex. You should upgrade to the current version, 21.05.1, when you can. 2.4.4p3 is very old. You may wish to re-install clean to be sure. Open a ticket with us to get the recovery image: https://go.netgate.com/ Steve

Other than an update of pfsense actual version, there should never be a reason to have to reboot pfsense. Common issue where people believe this is the case in change in firewall rules, and not working as they think... This is most likely related to existing "state" for whatever trying your trying to change what happens with. And the reboot clears all this. But if you do have an existing state causing a rule not to function as you believe - you can either kill that specific state, kill all the states or just wait for them to time out on their own, etc.

@stephenw10 Hello ! Information on status. So far, in case of power failure, I want the UPS to start and the initiation of new back-up tasks to become impermissible, Upon a combination of time and remaining charge of the UPS' battery; a proper shut down of the mac; and, if possible, Shut-down of the UPS. So Far, On my pfSense firewall SG-1000, there is a pre-installed NUT package, It works already and can trigger termination of NUT clients. For macOS, (version 10.13 High Sierra, the package manager Homebrew does not work any more, but the package manager MacPorts does), so I would (1) Install or update xCode on the mac; (2) install or update MacPorts, (3) configure and set instructions to slave on pfSense SG-1000, and (4) complete on pfSense the remainder of NUT configuration. This is my current plan, which seems feasible so far.

Hmm, that is interesting. I assume the WAN IP is not changed when you restart dpinger? I.e. it's not somehow restarting the connection? (it shouldn't).

Since you are using a correctly configured policy routing rule for LAN traffic you do not have to do anything. Anything not caught by that policy rule, such as traffic from the firewall itself, will use the default gateway. Just be aware that with that set to the load-balancing group as it is traffic will use one of the two PPPoE WANs that are in tier 1. It will not use both and there is no way to specify which one it will use. It will simply switch to the other one if one goes down or to the LTE if both go down. That setup is probably fine for your use. Steve