"Recent posts
#91
25.7, 25.10 Series / Re: [SOLVED] hostwatch at 100%...
Last post by franco - January 24, 2026, 11:10:53 AM@OPNenthu https://github.com/opnsense/hostwatch/issues/7
@iMx might be room for disabling it on Nano images and adding a wizard option for it. In any case we'll add a migration note. Disabling this manually is not an inconvenience IMO.
Cheers,
Franco
@iMx might be room for disabling it on Nano images and adding a wizard option for it. In any case we'll add a migration note. Disabling this manually is not an inconvenience IMO.
Cheers,
Franco
#92
25.7, 25.10 Series / Re: [SOLVED] hostwatch at 100%...
Last post by OPNenthu - January 24, 2026, 10:42:56 AMQuote from: franco on January 22, 2026, 07:31:32 AMHere's an updated version of hostwatch we're also consider shipping in a hotfix based on user feedback:
# pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/snapshots/misc/hostwatch-1.0.6.pkg
[...]
I rebooted my 25.7.11_2 install that was already running this v1.0.6 patch for the last ~2 days and on startup I noticed this in the console:
Code Select
Starting hostwatch.
Starting acme_http_challenge.
>>> Invoking start script 'syslog'
>>> Invoking start script 'carp'
>>> Invoking start script 'cron'
Starting Cron: OK
>>> Invoking start script 'hostwatch'
hostwatch already running? (pid=56724).
>>> Error in start script '90-hostwatch'
Hostwatch is up and running, though. Looks OK.
And the contents of that file:
Code Select
root@firewall:~ # cat /usr/local/etc/rc.syshook.d/start/90-hostwatch
#!/bin/sh
# work around mysterious first-time-only segfault
/usr/local/etc/rc.d/hostwatch start
#93
25.7, 25.10 Series / Re: New site PPPoE PMTU woes
Last post by meyergru - January 24, 2026, 09:26:09 AMI cannot test this, because I neither have the OpnSense VM on PVE nor an MTU of 1492, sorry.
#94
25.7, 25.10 Series / Re: OPNsense 25.7.10 Ethernet ...
Last post by iMx - January 24, 2026, 09:00:11 AM> Could this be a compatibility issue between FreeBSD and Broadcom network cards?
Always a possibility - did you search for the underlying FreeBSD version and your interface model(s)?
Is it just 1 interface? Or multiple of the same model?
If you have a ZFS snapshot, rolling back and testing again should be easy enough.
Always a possibility - did you search for the underlying FreeBSD version and your interface model(s)?
Is it just 1 interface? Or multiple of the same model?
If you have a ZFS snapshot, rolling back and testing again should be easy enough.
#95
25.7, 25.10 Series / Re: OPNsense 25.7.10 Ethernet ...
Last post by burns1230 - January 24, 2026, 08:39:33 AMASPM state is as follows:
link x0(x2) speed 0.0(8.0) ASPM disabled(L0s/L1)
link x1(x2) speed 5.0(5.0) ASPM disabled(L0s/L1) ClockPM disabled
link x8(x8) speed 8.0(8.0) ASPM disabled(L1)
It doesn't seem to be an ASPM problem.
This phenomenon never happened before, but since upgrading the system to 25.7.10, it has been happening every day.
Could this be a compatibility issue between FreeBSD and Broadcom network cards?
link x0(x2) speed 0.0(8.0) ASPM disabled(L0s/L1)
link x1(x2) speed 5.0(5.0) ASPM disabled(L0s/L1) ClockPM disabled
link x8(x8) speed 8.0(8.0) ASPM disabled(L1)
It doesn't seem to be an ASPM problem.
This phenomenon never happened before, but since upgrading the system to 25.7.10, it has been happening every day.
Could this be a compatibility issue between FreeBSD and Broadcom network cards?
#96
26.1 Series / Re: Firewall rules migration
Last post by Monviech (Cedrik) - January 24, 2026, 07:45:49 AMYou might have to wait for a new RC or the main release since a few bugs have been squashed in the migration.
Regarding the Rules landing page, you can see the interface in the URL. You can bookmark your favorite landing interface.
Regarding the Rules landing page, you can see the interface in the URL. You can bookmark your favorite landing interface.
#97
French - Français / Re: WireGuard entre 2 OpnSense...
Last post by Shefford - January 24, 2026, 04:45:44 AMOn peut tout à fait faire ce que tu veux avec WireGuard + OPNsense, mais il y a plusieurs points à bien aligner : routage, NAT et règles de firewall sur les deux sites.
Je vais appeler :
Site A = celui par lequel le .63 doit sortir sur Internet
Site B = celui où se trouve le périphérique 192.168.B.63 (j'invente un /24 pour l'exemple)
Tunnel WireGuard :
IP côté A : 10.10.10.1
IP côté B : 10.10.10.2
Adapte les IP à ta config réelle, c'est juste pour illustrer.
1. Principe de ce que tu veux faire
Tu veux du policy-based routing :
Sur le site B :
Tout le trafic LAN → Internet sauf pour 192.168.B.63 sort normalement par la WAN de B
Le trafic de 192.168.B.63 → Internet doit être envoyé dans le tunnel WireGuard vers A
Sur le site A :
Le trafic venant de 192.168.B.63 via le tunnel doit :
Être NATé sur l'IP WAN de A
Être autorisé par le firewall A
Être renvoyé dans le tunnel vers B pour les réponses
C'est exactement ce qu'un routeur d'entreprise ferait avec du PBR (Policy Based Routing).
2. Config côté Site B (où se trouve le .63)
2.1. Peers WireGuard
Sur le Site B, dans VPN > WireGuard > Peers, pour le peer « Site A » :
Tunnel Address : 10.10.10.2/32 (par ex)
Endpoint public de A : OK déjà
Allowed IPs (côté B pour le peer A) doit inclure :
Le réseau du site A (par ex 192.168.A.0/24) – pour accéder au LAN de A
Et 0.0.0.0/0 si tu veux envoyer tout le trafic par A pour certaines machines via des règles de firewall (policy routing)
Exemple :
192.168.A.0/24, 10.10.10.1/32, 0.0.0.0/0
Important : mettre 0.0.0.0/0 dans Allowed IPs NE force pas automatiquement tout à passer par A. Ça dit simplement : « ces destinations sont atteignables via ce peer ». Le choix de ce qui passe par ce tunnel se fait après via les règles du firewall (policy routing).
2.2. Règle de firewall LAN pour le .63
Sur le Site B, va dans Firewall > Rules > LAN et ajoute une règle en haut :
Action : Pass
Interface : LAN
Source : 192.168.B.63
Destination : any
Gateway : la gateway WireGuard (créée auto quand tu actives l'interface WG : par ex. WG_SITEA)
Log : activé temporairement pour debug
Cette règle va forcer tout le trafic de 192.168.B.63 à être routé via le tunnel WireGuard vers A, au lieu de la WAN de B.
Ensuite, assure-toi qu'une autre règle LAN générale (sans gateway) existe en dessous pour le reste du LAN, qui continue d'utiliser l'Internet de B normalement.
3. Config côté Site A (sortie Internet)
Deux choses essentielles :
Le NAT pour la source 192.168.B.63 (vue depuis A via le tunnel)
Les règles firewall sur l'interface WireGuard et sur WAN
3.1. S'assurer que Site A connaît le réseau de B
Sur le Site A, dans WireGuard > Peers pour le peer « Site B » :
Allowed IPs doit contenir le réseau du site B :
par ex. 192.168.B.0/24, 10.10.10.2/32
C'est comme ça qu'A sait : « pour atteindre 192.168.B.0/24, je passe par ce peer/tunnel ».
3.2. NAT (Outbound) côté A
Tu dois t'assurer que lorsque 192.168.B.63 arrive par le tunnel sur A et sort sur Internet, il est NATé avec l'IP WAN de A.
Dans OPNsense Site A :
Va dans Firewall > NAT > Outbound
Mode :
Soit « Hybrid outbound NAT rule generation »
Soit « Manual outbound NAT rule generation »
(Évite « Automatic only » pour ce cas précis)
Ajoute une règle :
Interface : WAN
Source : 192.168.B.63/32 (ou 192.168.B.0/24 si tu veux NATer tout le réseau B via A)
Source Port : any
Destination : any
Translation / target : Interface address (WAN A)
Description : NAT pour B.63 via WG
Sauvegarde + appliquer.
3.3. Règles de firewall côté A (interface WireGuard et WAN)
Sur l'interface WireGuard de A (par ex « WG_SITEB » dans Firewall > Rules > [WG_SITEB]) :
Ajoute une règle :
Action : Pass
Interface : WG_SITEB
Source : 192.168.B.0/24 (ou au minimum 192.168.B.63/32)
Destination : any
Protocol : any
Elle autorise le flux venant du réseau B via le tunnel.
Sur WAN de A :
Normalement, pas besoin de règle spéciale si le firewall de A autorise déjà le trafic sortant initié par le LAN/Tunnel. Vérifie que tu as une règle du type :
Interface : WAN
Direction : Outbound / ou IPv4 depuis A vers internet autorisé (selon ta politique)
Dans la majorité des configs « par défaut », c'est déjà OK : c'est l'interface LAN/WG qui décide ce qu'elle laisse sortir.
4. Diagnostic : pourquoi tu as « Destination host unreachable »
Quand tu ping 1.1.1.1 depuis 192.168.B.63 et que tu obtiens « Destination host unreachable », il y a 3 causes classiques :
Le paquet ne part pas dans le tunnel (PBR mal appliqué)
Vérifie sur B : dans Firewall > Log > Live View :
Filtre par source = 192.168.B.63
Tu dois voir la règle LAN avec gateway WG_SITEA matche ce trafic.
Site A ne connaît pas 192.168.B.0/24 comme étant derrière le tunnel
Allowed IPs mal configuré sur le peer côté A, ou interface WG mal montée.
NAT ou firewall côté A bloque
Paquets arrivent bien sur A via WG, mais :
soit pas de NAT Outbound correspondant → trafic sort avec IP privée du réseau B → drop par le FAI
soit firewall sur interface WG ou WAN refuse.
Tu peux confirmer que le trafic arrive sur A via :
Firewall > Log > Live View sur A
Filtrer source 192.168.B.63
Si tu vois des paquets entrants sur interface WG → le routage tunnel est OK
5. Résumé rapide des points clés
Sur B :
Peer vers A : Allowed IPs inclut 0.0.0.0/0
Règle LAN en haut pour 192.168.B.63 → Gateway = WG_SITEA
Sur A :
Peer vers B : Allowed IPs inclut 192.168.B.0/24
Firewall > Rules > [WG_INTERFACE] : autoriser source 192.168.B.0/24 vers any
Firewall > NAT > Outbound sur WAN : NAT source 192.168.B.63/32 (ou B.0/24) vers IP WAN A
j'utilise ca sur mon opnsense mais ca ne ce decrit pas vraiment fait ci fait ca et ca va fonctionner tu dois compprendre un minimum ce que tu fais chauqe reseau est specifique
Je vais appeler :
Site A = celui par lequel le .63 doit sortir sur Internet
Site B = celui où se trouve le périphérique 192.168.B.63 (j'invente un /24 pour l'exemple)
Tunnel WireGuard :
IP côté A : 10.10.10.1
IP côté B : 10.10.10.2
Adapte les IP à ta config réelle, c'est juste pour illustrer.
1. Principe de ce que tu veux faire
Tu veux du policy-based routing :
Sur le site B :
Tout le trafic LAN → Internet sauf pour 192.168.B.63 sort normalement par la WAN de B
Le trafic de 192.168.B.63 → Internet doit être envoyé dans le tunnel WireGuard vers A
Sur le site A :
Le trafic venant de 192.168.B.63 via le tunnel doit :
Être NATé sur l'IP WAN de A
Être autorisé par le firewall A
Être renvoyé dans le tunnel vers B pour les réponses
C'est exactement ce qu'un routeur d'entreprise ferait avec du PBR (Policy Based Routing).
2. Config côté Site B (où se trouve le .63)
2.1. Peers WireGuard
Sur le Site B, dans VPN > WireGuard > Peers, pour le peer « Site A » :
Tunnel Address : 10.10.10.2/32 (par ex)
Endpoint public de A : OK déjà
Allowed IPs (côté B pour le peer A) doit inclure :
Le réseau du site A (par ex 192.168.A.0/24) – pour accéder au LAN de A
Et 0.0.0.0/0 si tu veux envoyer tout le trafic par A pour certaines machines via des règles de firewall (policy routing)
Exemple :
192.168.A.0/24, 10.10.10.1/32, 0.0.0.0/0
Important : mettre 0.0.0.0/0 dans Allowed IPs NE force pas automatiquement tout à passer par A. Ça dit simplement : « ces destinations sont atteignables via ce peer ». Le choix de ce qui passe par ce tunnel se fait après via les règles du firewall (policy routing).
2.2. Règle de firewall LAN pour le .63
Sur le Site B, va dans Firewall > Rules > LAN et ajoute une règle en haut :
Action : Pass
Interface : LAN
Source : 192.168.B.63
Destination : any
Gateway : la gateway WireGuard (créée auto quand tu actives l'interface WG : par ex. WG_SITEA)
Log : activé temporairement pour debug
Cette règle va forcer tout le trafic de 192.168.B.63 à être routé via le tunnel WireGuard vers A, au lieu de la WAN de B.
Ensuite, assure-toi qu'une autre règle LAN générale (sans gateway) existe en dessous pour le reste du LAN, qui continue d'utiliser l'Internet de B normalement.
3. Config côté Site A (sortie Internet)
Deux choses essentielles :
Le NAT pour la source 192.168.B.63 (vue depuis A via le tunnel)
Les règles firewall sur l'interface WireGuard et sur WAN
3.1. S'assurer que Site A connaît le réseau de B
Sur le Site A, dans WireGuard > Peers pour le peer « Site B » :
Allowed IPs doit contenir le réseau du site B :
par ex. 192.168.B.0/24, 10.10.10.2/32
C'est comme ça qu'A sait : « pour atteindre 192.168.B.0/24, je passe par ce peer/tunnel ».
3.2. NAT (Outbound) côté A
Tu dois t'assurer que lorsque 192.168.B.63 arrive par le tunnel sur A et sort sur Internet, il est NATé avec l'IP WAN de A.
Dans OPNsense Site A :
Va dans Firewall > NAT > Outbound
Mode :
Soit « Hybrid outbound NAT rule generation »
Soit « Manual outbound NAT rule generation »
(Évite « Automatic only » pour ce cas précis)
Ajoute une règle :
Interface : WAN
Source : 192.168.B.63/32 (ou 192.168.B.0/24 si tu veux NATer tout le réseau B via A)
Source Port : any
Destination : any
Translation / target : Interface address (WAN A)
Description : NAT pour B.63 via WG
Sauvegarde + appliquer.
3.3. Règles de firewall côté A (interface WireGuard et WAN)
Sur l'interface WireGuard de A (par ex « WG_SITEB » dans Firewall > Rules > [WG_SITEB]) :
Ajoute une règle :
Action : Pass
Interface : WG_SITEB
Source : 192.168.B.0/24 (ou au minimum 192.168.B.63/32)
Destination : any
Protocol : any
Elle autorise le flux venant du réseau B via le tunnel.
Sur WAN de A :
Normalement, pas besoin de règle spéciale si le firewall de A autorise déjà le trafic sortant initié par le LAN/Tunnel. Vérifie que tu as une règle du type :
Interface : WAN
Direction : Outbound / ou IPv4 depuis A vers internet autorisé (selon ta politique)
Dans la majorité des configs « par défaut », c'est déjà OK : c'est l'interface LAN/WG qui décide ce qu'elle laisse sortir.
4. Diagnostic : pourquoi tu as « Destination host unreachable »
Quand tu ping 1.1.1.1 depuis 192.168.B.63 et que tu obtiens « Destination host unreachable », il y a 3 causes classiques :
Le paquet ne part pas dans le tunnel (PBR mal appliqué)
Vérifie sur B : dans Firewall > Log > Live View :
Filtre par source = 192.168.B.63
Tu dois voir la règle LAN avec gateway WG_SITEA matche ce trafic.
Site A ne connaît pas 192.168.B.0/24 comme étant derrière le tunnel
Allowed IPs mal configuré sur le peer côté A, ou interface WG mal montée.
NAT ou firewall côté A bloque
Paquets arrivent bien sur A via WG, mais :
soit pas de NAT Outbound correspondant → trafic sort avec IP privée du réseau B → drop par le FAI
soit firewall sur interface WG ou WAN refuse.
Tu peux confirmer que le trafic arrive sur A via :
Firewall > Log > Live View sur A
Filtrer source 192.168.B.63
Si tu vois des paquets entrants sur interface WG → le routage tunnel est OK
5. Résumé rapide des points clés
Sur B :
Peer vers A : Allowed IPs inclut 0.0.0.0/0
Règle LAN en haut pour 192.168.B.63 → Gateway = WG_SITEA
Sur A :
Peer vers B : Allowed IPs inclut 192.168.B.0/24
Firewall > Rules > [WG_INTERFACE] : autoriser source 192.168.B.0/24 vers any
Firewall > NAT > Outbound sur WAN : NAT source 192.168.B.63/32 (ou B.0/24) vers IP WAN A
j'utilise ca sur mon opnsense mais ca ne ce decrit pas vraiment fait ci fait ca et ca va fonctionner tu dois compprendre un minimum ce que tu fais chauqe reseau est specifique
#98
25.7, 25.10 Series / Re: New site PPPoE PMTU woes
Last post by ToasterPC - January 24, 2026, 02:43:36 AMBump
#99
26.1 Series / Re: Firewall rules migration
Last post by OzziGoblin - January 24, 2026, 02:03:14 AMHi Team
I've tested upgrading successfully 3 times on different lab environments, but I'm confused as to why the fw rules continue to remain greyed out and uneditable once migrated and step 5 is complete, am I missing something to complete the migration of fw rules?
Everything appears to function as expected although mine aren't complicated labs, but my main reason for testing was to see what happens with ISC DHCP and IPv6, which is working.
While I do appreciate all the effort that goes into the software and please I'm not disrespecting anyone, I'm not a fan of the new firewall interface to switch between networks, it's a lot of extra clicking to navigate now. If it was possible to choose a default landing page rather than floating rules, it may help. Happy to hear the reason for the change though.
I've tested upgrading successfully 3 times on different lab environments, but I'm confused as to why the fw rules continue to remain greyed out and uneditable once migrated and step 5 is complete, am I missing something to complete the migration of fw rules?
Everything appears to function as expected although mine aren't complicated labs, but my main reason for testing was to see what happens with ISC DHCP and IPv6, which is working.
While I do appreciate all the effort that goes into the software and please I'm not disrespecting anyone, I'm not a fan of the new firewall interface to switch between networks, it's a lot of extra clicking to navigate now. If it was possible to choose a default landing page rather than floating rules, it may help. Happy to hear the reason for the change though.
#100
26.1 Series / Re: Firewall rules migration
Last post by nero355 - January 24, 2026, 12:28:51 AMQuote from: Monviech (Cedrik) on January 23, 2026, 03:48:54 PMThere is no automatic migration of firewall rules. Both new and old component are fully functional side by side.So eventually this :
So dont worry about upgrading, nothing will change.
After the upgrade there will be a migration assistant you can choose (or not yet choose) to follow. No rush.
Quote from: julsssark on January 22, 2026, 10:57:18 PMAnti-lockout instruction clarity:Will not be needed at all ?!
The instruction text says "Enable the anti-lockout rule" while step 2 says "Deselect anti-lockout in advanced settings".
Given the wording of the control itself ("Disable anti-lockout"), I suggest revising the instruction text to: "To prevent being locked out during the rule migration process, enable automatically generated lock-out rules..." and updating step 2 to: "Uncheck the 'Disable anti-lockout' checkbox."
I have the default Anti-Lockout option disabled and built my own Firewall Rules around it instead so I would like to know if anything will be incompatible with my setup :)
