Problems With WAN Loss Cobnection
-
@dcuadrados said in Problems With WAN Loss Cobnection:
i only have for telegraf and ipsec:
IPSEC is an 'interface' bound process for sure.
So, when an interface gets restarted, process gets restarted.
The watchdog detects that IPSEC is restating (= stopped first), so it restart IPSEC, which will restart IPSEC so it restarts IPSEC so it restart .....You see the problem?
@dcuadrados said in Problems With WAN Loss Cobnection:
What I’ve noticed is that if I stop the service manually, it restarts automatically in less than 20 seconds.
That's the job of watchdog.
But, even that reaction is totally wrong.
If you, as an admin, stops a process like IPSEC, then that's for a - your - reason, for example maintenance.
You don't want it to restart all by itself.
You stopped it.
So ... you start it - when needed.and live will be easier.
-
@Gertjan said in Problems With WAN Loss Cobnection:
IPSEC es sin duda un proceso vinculado a una 'interfaz'.
Entonces, cuando se reinicia una interfaz, se reinicia el proceso.
El organismo de control detecta que IPSEC se está reiniciando (= se detuvo primero), por lo que reinicia IPSEC, que reiniciará IPSEC para que reinicie IPSEC para que se reinicie .....¿Ves el problema?
I’m testing this by completely removing Watchdog, and Snort still restarts on its own—even without an IPsec tunnel, on a freshly installed firewall. When you stop Snort, it automatically starts again.
So during the update process, since Snort is already running after being restarted automatically, the update then tries to start it again—and voilà, you end up with two processes for a single interface and a highly unstable firewall.
-
Also : what's connected to your LAN :
Even if this :@dcuadrados said in Problems With WAN Loss Cobnection:
Jun 29 18:32:58 php-fpm 33297 /rc.linkup: DEVD Ethernet attached event for lan
Jun 29 18:32:58 php-fpm 33297 /rc.linkup: Hotplug event detected for LAN(lan) static IP address (4: 192.168.2.1)isn't wrong per se, but you, as an pfSense admin, you really don't want your pfSense interfaces to get disconnected.
Ok, sometimes, it can happen, or has to happen.
Make it a one per month experience and you'll be way better. -
@Gertjan said in Problems With WAN Loss Cobnection:
no está mal per se, pero usted, como administrador de pfSense, realmente no quiere que sus interfaces de pfSense se desconecten.
Ok, a veces, puede suceder, o tiene que suceder.
Haz que sea una experiencia de uno por mes y estarás mucho mejor.I currently have the update set to every 28 days and I'm running some tests, but I don’t understand why Snort restarts by itself. As you rightly said—as the administrator, if you stop a service, it’s for a reason. It shouldn't start again automatically. That behavior makes no sense at all.
For now, I’ve scheduled it to update every 28 days. The issue is that every time it updates, it always creates a second “interface” and ends up spawning two processes.
-
@dcuadrados said in Problems With WAN Loss Cobnection:
but I don’t understand why Snort restarts by itself
Not just snort, many process (dhcp, unbound, dpinger, the GUI, etc etc etc) get restarted when interfaces disconnected > reconnect.
So, as said above :isn't wrong per se, but you, as an pfSense admin, you really don't want your pfSense interfaces to get disconnected.
as that restarts everything.
-
@Gertjan I think it’s fine for Snort to restart if needed, but an update shouldn’t generate two processes. The issue isn’t just having two processes—it’s the overall instability it causes in the entire system.
-
@dcuadrados said in Problems With WAN Loss Cobnection:
it’s the overall instability it causes in the entire system
Very true.
That's why I monitor it, the same way they do so at the hospital.The best experience will come from a pfSense where you didn't add any 'extra' functionality. A native pfSense can keep on humming without anything noticeable for days, if not weeks.
See my stats, every time it reboorts, it was me typing 'reboot', or updating the system. Sudden freezes or lost WAN. Not that I recall - nothing in 2025.Ask yourself : do you need snort ?
As all, 99,9 % or more, is TLS encrypted, how can snort 'see' the data and scan for rule matches ?
The only thing that snort still can see is the packet header : source and destination IP, source and destination port, and a couple of flags .... that's, imho, not worth it. -
@Gertjan When someone is right, you have to give them credit. I’d give you a Like if I could!
-
When using Inline IPS Mode, the netmap kernel code will "cycle" the underlying physical FreeBSD interface. That causes the pfSense code to think the cable was unplugged and then plugged back in (see the HOTPLUG linkup messages). HOTPLUG detection results in pfSense automatically restarting the packages in case any of them might need to be aware of a potentially new IP address.
For what it's worth, I've not observed the restart problem with Snort that you describe in my testing on virtual machines. If I stop Snort, it says stopped in the GUI. Now, if something makes pfSense itself decide to restart all packages, it's certainly possible for Snort to get restarted by pfSense unless it is disabled on the interface.
This HOTPLUG event is relatively new in FreeBSD with netmap. Back when I first added Inline IPS Mode to Snort I don't recall that happening. It started happening a few years later as the FreeBSD version evolved. Perhaps it has something to do with the migration of the
iflibwrapper in FreeBSD ???But as @Gertjan said: "Ask yourself : do you need snort ? As all, 99,9 % or more, is TLS encrypted, how can snort 'see' the data and scan for rule matches ? The only thing that snort still can see is the packet header : source and destination IP, source and destination port, and a couple of flags"
I maintain the Snort package and created the Suricata package, and I don't run either of them on my home network firewall. No benefit unless you perform MITM SSL interception. Don't want to deal with that hassle for sure. IDS/IPS was a valuable tool back in the day when perimeter network traffic was largely cleartext and easily scanned. That tool is not very effective today when the vast majority of perimeter network traffic is encrypted. It can still sort of work in large enterprise environments where you can tightly control all the devices (including mobile ones) and put the necessary trusted intermediate CA certs on them to allow MITM SSL interception and you have an integrated system from one vendor such as Palo Alto or Cisco, etc. You also must pay them a small fortune in annual licensing fees, though.
-
@bmeeks Since I can't give you a Like (
), I'll do it this way instead!
I’m just one reputation point away from being able to give Likes. -
-
