Problems With WAN Loss Cobnection
-
@stephenw10 i only have for telegraf and ipsec:
What I’ve noticed is that if I stop the service manually, it restarts automatically in less than 20 seconds. So the problem seems to be that during the update, it starts a new instance of the service, and then ends up spawning a second one.
Jun 30 09:22:28 SnortStartup 65366 Snort START for LAN(em1)... Jun 30 09:22:28 php-fpm 435 /rc.start_packages: Restarting/Starting all packages. Jun 30 09:22:27 check_reload_status 479 Reloading filter Jun 30 09:22:27 check_reload_status 479 Starting packages Jun 30 09:22:27 php-fpm 8814 /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 192.168.2.1 -> 192.168.2.1 - Restarting packages. Jun 30 09:22:25 php-fpm 8814 /rc.newwanip: Creating rrd update script Jun 30 09:22:25 php-fpm 8814 /rc.newwanip: Resyncing OpenVPN instances for interface LAN. Jun 30 09:22:25 php-fpm 8814 /rc.newwanip: Ignoring IPsec reload since there are no tunnels on interface lan Jun 30 09:22:22 php-fpm 8814 /rc.newwanip: Gateway, NONE AVAILABLE Jun 30 09:22:21 php-fpm 8814 /rc.newwanip: Removing static route for monitor 8.8.8.8 and adding a new route through 192.168.0.1 Jun 30 09:22:09 php-fpm 8814 /rc.newwanip: rc.newwanip: on (IP address: 192.168.2.1) (interface: LAN[lan]) (real interface: em1). Jun 30 09:22:09 php-fpm 8814 /rc.newwanip: rc.newwanip: Info: starting on em1. Jun 30 09:22:08 check_reload_status 479 Reloading filter Jun 30 09:22:08 check_reload_status 479 rc.newwanip starting em1 Jun 30 09:22:08 php-fpm 8814 /rc.linkup: HOTPLUG: Triggering address refresh on lan (em1) Jun 30 09:22:08 php-fpm 8814 /rc.linkup: DEVD Ethernet attached event for lan Jun 30 09:22:08 php-fpm 8814 /rc.linkup: Hotplug event detected for LAN(lan) static IP address (4: 192.168.2.1) Jun 30 09:22:07 kernel em1: link state changed to UP Jun 30 09:22:07 check_reload_status 479 Linkup starting em1 Jun 30 09:22:07 check_reload_status 479 Reloading filter Jun 30 09:22:05 php-fpm 81789 /rc.linkup: DEVD Ethernet detached event for lan Jun 30 09:22:05 php-fpm 81789 /rc.linkup: Hotplug event detected for LAN(lan) static IP address (4: 192.168.2.1) Jun 30 09:22:04 kernel em1: link state changed to DOWN Jun 30 09:22:04 check_reload_status 479 Linkup starting em1 Jun 30 09:22:04 snort 96451 *** Caught Term-Signal Jun 30 09:22:03 SnortStartup 34465 Snort STOP for LAN(em1)... -
@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. -
-
