@patient0 Got it, will explore 'Shellcmd' package Thank you!

@Codefighter Thanks @Codefighter, you’ve nailed it. I totally agree that for home use, OTP can feel like overkill. But when it comes to small, medium, and large businesses, we’ve got a real responsibility to keep networks and systems secure. We can’t afford to be casual or underestimate the risks out there. Honestly, I’d much rather hear a few grumbles from employees about typing in an OTP every time they hop on the VPN than have to sit in a meeting with the board explaining why we didn’t do enough to prevent and mitigate a cyberattack.

Dass DHCP o.ä. über private IPs vom ISP kommt ist kein Wunder, das ist häufig der Fall. dein lagg0.7 (vlan7 auf lagg0) muss dann wahrscheinlich dein WAN sein auf dem du DHCP aktiv hast? Oder wie ist sonst dein WAN konfiguriert? Der ISP macht also um 2h ggf. ein Renew oder eine Zwangstrennung oder gabs nen Grund warum genau da das WAN ne neue IP bekommen hatte? Der DHclient hat zumindest >24h als Lease Time bekommen und hätte daher erst am nächsten Tag um kurz nach 2h morgens wieder ein Renew gemacht. Der ISP hat aber anscheinend dann vorher schon die Adresse entzogen oder die pfSense hat sie verloren. Die Frage ist da eher, was VOR dem Gateway Alarm kam. Der kam ja dann wohl so kurz nach 12 und dann ging nix mehr. Daraufhin wurden dann auch alle WAN-abhängigen Sachen neu gestartet, aber die Frage ist, was genau vor 12:01:00/01 passiert ist, denn da kam der GW Alarm. Und da würde ich dann auch in den DHCP Logs schauen ob um 12h irgendwas passiert ist. Dass das so GENAU 10h sind, stinkt nämlich ein wenig. Das könnte dann sein, dass nach 10h irgendwas beim ISP expired wenn das nicht erneuert wird und die pfSense macht halt nichts bevor die Lease Time rum ist - warum sollte sie auch, sie hat ja die IP. Wenn der ISP aber irgendwelchen Dummfug veranstaltet und dann immer mal wieder auf irgendwas wartet um die IP "up" zu lassen (ja erzählen können die viel, dass sie NUR DHCP machen würden...), dann klapperts dann trotzdem. Wir hatten das bei seltsamen ISPs schon mit CARP/HA Adressen, die dann einfach "vergessen" wurden auf dem Interface, weil deren MAC Adresse nicht upstream geschickt wurde - da das nur beim setzen der VIP gemacht wird. Die VIP wurde dann vom ISP wegen "inactivity" einfach weggekillt. Wir haben dann ein Script gebaut, was in regelmäßigen Intervallen einen gratuitous ARP von der VIP schickt, dann war plötzlich alles gut. Und das war bei statischen IPs. Angeblich auch der ISP "nix gemacht!!!11elf". Hmm ;) Anderer Fall könnte sein, dass du von einem anderen Device einen DHCPNACK bekommst bzw. einen Release, der aber von ner anderen IP kommt. Dagegen könnte man reinwerfen, dass der DHCP NUR von der IP oben kommen darf - sofern die immer gleich ist. Das wäre dann auch ein Thema.

@stephenw10 said in Syslog service in pfSense v2.8.1 often stop itself: As a workaround you can prevent the syslogd process seeing the connection rejection message from the server by adding firewall walls. You need to pass the syslog traffic outbound with state set to 'none'. And block the incoming icmp rejection if it's not already blocked. It then just keeps sending to the server. Thanks for the tips

@btspce said in Suricata on Pfsense: pulled the updates I did not look for packages at the time but for a short while on Tuesday 25.11 was available to all. https://forum.netgate.com/topic/198787/what-is-it-25.11.a.20250916.0600/

@keyser said in Order of routing: There is a MUCH simpler solution - simply bypass (exclude) that IP from the IPsec policy based route. Wow. Didn't know this as well. Thx.

Still nothing logged at the point the RRD process start to rack up?

Hmm, what sort of tunnel? Is it somehow trying to pass the upgrade traffic across it?

Unless you're somehow tunneling traffic to somewhere else in pfSense then that message is nothing to do with pfSense. It's the server telling you the source IP you're using (the pfSense WAN address) is not allowed to access it. For some reason. Now if you have a VPN setup in pfSense it could be tunnelling your traffic to some remote source IP that's in a completely different region. But where is the VPN server your client VPN connects to that then allow the connection?

@maverick_slo Noop. I said : I can image and gave some examples. Only had a coffee or two this morning. Look at what has changed over the last 10 years. Chances are that things keep on changing. Our VPN needs will change also. Another example : 4096 bits deep CA/certs will do the job nicely today. It's secure enough. Then a major AI / quantum technology breakthrough will make this "4096" encryption way to dangerous. Like : "RSA" will fade away, it must be "ECDSA" or whatever will be invented in a near future. Your bet is : this won't happen in the next 10++ years. And I hope your right, but I won't place any bets on it though. The contrary will probably happen, as this is what the past told me. @maverick_slo said in CA cert renew: Openvpn is being ditched by Netgate? Like this : OpenVPN is open source today. Like MySQL was in the past, and Javascript. Then it get sold to some company - and now it needs to get monetized = you have to pay for it. In that case "OpenVPN" will most probably lose it's place into a product like pfSense. Your 10+ scale is, for me, a huge time scale when you deal with security software. edit : but were getting off topic here. Your question isn't that special actually. I'm pretty sure it has been asked before. Dig (search) into this forum, and you will find equivalent question and more meaning full answers.

@Uglybrian How does MTU or ICMPv6 help if i want to disable ipv6? Problem is on my operator side. Ipv6 can work many days just fine and then there goes something wrong on my operator side and its broken for few hours. I would like my firewall disable ipv6 when it goes broken and enable it again when its ok. Now i must manually go to wan adapter and disable ipv6 from there and then test again later if its ok and enable it. I would like to do this automatically. I have made a problem ticket to my operator and they are still investigating it, but havent find a solution.

@Randy_T If you have a public ip (static or dynamic?), just create the port forward rule and the associated PASS firewall rule on WAN, this last is crucial because pfSense by default will block unsolecited incoming traffic. Maybe it is better if you post some screenshots just to let us see if everything is ok. Again if your VPN doesn't support port forwarding you cannot use the VPN interface. If the WAN IP changes you need to use a DDNS service to keep your gaming server IP updated.

@SteveITS Yes, same ISP hardware. That is probably a worsening factor. Had it been two separate connection types or ISPs, I don't think it would mind identical DUID (but not entirely sure there) I tried the NPt and two "fake" interfaces that just monitored the prefix; but that did not work as again the other WAN is never going to be assigned anything by the ISP (again, not sure but it's my theory). I have too considered it to be a limitation way down deep, as OPNsense has the exact same problem. The static IPv6 stuff in the manual I did read, and it would work as no DUID is being used to negotiate a static IPv6. I don't believe many people have static IPv6 addresses though. But that makes me think Netgate knows of this issue already, and either it will never work, or just not a priority feature. Thanks for your input and thoughts, I really appreciate it. At least people who run into the same behavior will hopefully find this thread, and not spend 40-60 hours troubleshooting with different router software and what not, as I have :)

Mmm, if this is something more general I'd love to pin it down. Can't find the steps to replicate it again now though. I'll keep trying...

@bmeeks Knew I was asking one of the right guys! Thanks very much for sharing.

you're right, I'm still confused about where to find it. The red flag remains, probably just a minor bug

@keyser Yeah it's worth a shot at least, I'll give this a go. I have seen others online were duplicate SAs will show up, but from everything I've seen that normally doesn't prevent traffic from flowing, maybe I'm remembering wrong though. We do use these VPNs 24/7, we have a night crew, so I don't think it's related to the keep alive. Nonetheless I'll make sure it's enabled (it's not right now, but I am 99% sure I had it enabled in the previous setup when this issue started). Thanks for the tips though, greatly appreciate it.

@patient0 this is the output: [image: 1758737218291-8bfb2302-96f3-4a31-beb9-2eb982e50e8b-afbeelding.png]

@0x44 I'm not quite sure I'm following your problem then. pfSense does not have a "layer 7" user concept on which you can create rules (rules against users/identities). It only does layer 2/3/4 (Ethernet/IP/Protocol) filtering. You mentioned virtual pool, is this because the users are also VPN clients, and you are looking to restrict to which S2S tunnel targets they are allowed to reach? Anyways, the only way you can restrict the access is by doing sourcefiltering in firewall rules, so you need a mechanism to make sure user A and user B always has IP addresses you know and can filter against. For regular LAN users this can be achieved by VLAN segmentation and different subnets if users A and B are each actually a large group of users. If it's just one user, you can do it by fx. DHCP reservation or use of static IPs on some clients. If they are VPN clients themselves, you need to use the "new" IP Pool feature and radius authentication of the VPN clients where you return the "Class" attribute from radius to assign which IP pool the client belongs to. If it's just two local VPN users on the firewall, you can assign their user a static VPN pool IP in the EAP-secret section, or by using Radius to return the framed-IP attribute. In all cases you can then filter access with source rules in the firewall rules.

@revengineer the trick is to figure out where it is coming from. Not sure how to figure out what could of created it. But would assume if it labeled it gateway monitoring - that has to come from somewhere. It could be a bug that creates a block vs what I would think a better idea of an allow rule, to make sure you could always ping what your wanting to monitor.. But it doesn't make a lot of sense to be honest, since there is already a hidden rule that allows pfsense itself to do whatever it wants outbound. Which is where the monitoring would come from - ie dpinger. # let out anything from the firewall host itself and decrypted IPsec traffic pass out inet all keep state allow-opts ridentifier 1000016215 label "let out anything IPv4 from firewall host itself" pass out inet6 all keep state allow-opts ridentifier 1000016216 label "let out anything IPv6 from firewall host itself" Other thing about the rule that you posted that is odd - is why would it be logged? Have you looked in /tmp/rules.debug - this is a full listing of the rules, and shows the rules pfsense creates on its own that are hidden, like when you enable dhcp server, hidden rules are created on the interface you enable dhcp on so it is sure to work, etc.