"Recent posts
#1
General Discussion / Re: Why I am retiring from con...
Last post by trasz@ - Today at 11:11:16 AMQuote from: muchacha_grande on August 26, 2026, 09:45:50 PMUnbelievable... doesn't make any sense.
One thing previous core admitted to on developers@ last year is they didn't always bother with consensus or voting, and ignored / bypassed those who wanted to follow established procedures. So it's no wonder said procedures failed to work - in this case, they failed to unban you.
#2
Intrusion Detection and Prevention / Re: Suricata 8.0.6 — eve.json ...
Last post by runo10 - Today at 11:03:59 AMI didnt check for issue one but I have issue 2. When I enable suricata, a few minutes later all network gone. And later a few minutes it start to work again but it gones again a minutes later. This repeats continuesly.
I have crowdsec and suricata. But it worked before may be latest updates break something.
Also when I check suricata alerts from gui there is no alerts?
I have crowdsec and suricata. But it worked before may be latest updates break something.
Also when I check suricata alerts from gui there is no alerts?
#3
German - Deutsch / Re: OPNSense Anfänger braucht ...
Last post by Chr1sly - Today at 09:58:39 AMDanke nochmals!
Wie viele habe ich auch die typische Admin Krankheit: "Handbücher...? Das ist doch nur was für Noobs".
🤭
Wie viele habe ich auch die typische Admin Krankheit: "Handbücher...? Das ist doch nur was für Noobs".
🤭
#4
German - Deutsch / Re: Routing über falsches gate...
Last post by osmom - Today at 08:38:33 AMHi, das sind momentan zu wenig Informationen.
Gehe bitte die Anleitung https://docs.opnsense.org/manual/how-tos/multiwan.html#multi-wan nochmals Punkt für Punkt durch und mache für jeden Punkt eigene Screenshots. Natürlich müssen beide Leitungen dabei in Betrieb sein. Vielleicht kann dir dann geholfen werden.
PS: Du schreibst: ,,Und ein abgeschaltetes Fallback-Gateway ist nicht ganz der Sinn eines abgeschalteten Fallback-Gateways ..." → Dann muss es aber auch im Bedarfsfall funktionieren. Weil du vorher schreibst, dass PLDT nicht zuverlässig ist.
Gehe bitte die Anleitung https://docs.opnsense.org/manual/how-tos/multiwan.html#multi-wan nochmals Punkt für Punkt durch und mache für jeden Punkt eigene Screenshots. Natürlich müssen beide Leitungen dabei in Betrieb sein. Vielleicht kann dir dann geholfen werden.
PS: Du schreibst: ,,Und ein abgeschaltetes Fallback-Gateway ist nicht ganz der Sinn eines abgeschalteten Fallback-Gateways ..." → Dann muss es aber auch im Bedarfsfall funktionieren. Weil du vorher schreibst, dass PLDT nicht zuverlässig ist.
#5
26.7 Series / Re: chrony port open?
Last post by patient0 - Today at 06:57:38 AMQuote from: Lucid1010 on Today at 01:54:26 AMYes. I'd just like to disable the local port as wellPort 323 is the control port, which is used to make changes by non-root users while chrony runs. E.g. with 'chronyc' from the command line. It can't be disabled.
But as mentioned since it is only accessable from the machine itself, it's no issue.
#6
Hardware and Performance / Re: amd-xgbe ("ax"): interface...
Last post by patient0 - Today at 06:54:38 AMQuote from: nero355 on September 16, 2026, 11:24:11 PMOK, but is it this for exampleI have no idea, I assume it's that but not sure.
The driver is maintained by AMD AFAIK but OPNsense made changes too since their boxes use it.
#7
26.7 Series / Re: chrony port open?
Last post by Lucid1010 - Today at 01:54:26 AMQuote from: Patrick M. Hausen on September 16, 2026, 03:11:23 PM127.0.0.1 is the loopback interface. It is not reachable from anywhere but the firewall itself.
Yes. I'd just like to disable the local port as well.
#8
German - Deutsch / Re: Routing über falsches gate...
Last post by rthoene - Today at 01:34:20 AMVielen Dank, aus dieser Anleitung und einer Hilfestellung aus dem Netz habe ich die OPNsense konfiguriert.
Und: Die OPNsense funktioniert optisch auch entsprechend!
Vorher war PLDT der Hauptzugang (weil Glasfaser), und wenn die PING-Zeiten bei PLDT hoch gingen (2000 ms kommen da schon mal vor...), dann hat OPNsense auch in der Anzeige/Dashboard korrekt umgestellt!
Aber: Mein(e) Rechner wurde trotzdem dann weiterhin über das nun praktisch nicht benutzbare PLDT geroutet.
Hierbei machte es keinen Unterschied, ob Sticky connections aktiv oder nicht aktiv war.
Nun ist Starlink die Hauptverbindung (niedrigere Prio), das wird auch korrekt angezeigt. Trotzdem wird mein Rechner weiter über PLDT geroutet.
Das kann ich nur verhindern, wenn ich PLDT, also das Failback Gateway, gänzlich abschalte (selbst dann dauert es noch einige Zeit, bis OPNsense diesen Port nicht mehr verwendet).
Und ein abgeschaltetes Fallback Gateway ist ja nicht ganz der Sinn eines abgeschalteten Fallback Gateway...
Und: Die OPNsense funktioniert optisch auch entsprechend!
Vorher war PLDT der Hauptzugang (weil Glasfaser), und wenn die PING-Zeiten bei PLDT hoch gingen (2000 ms kommen da schon mal vor...), dann hat OPNsense auch in der Anzeige/Dashboard korrekt umgestellt!
Aber: Mein(e) Rechner wurde trotzdem dann weiterhin über das nun praktisch nicht benutzbare PLDT geroutet.
Hierbei machte es keinen Unterschied, ob Sticky connections aktiv oder nicht aktiv war.
Nun ist Starlink die Hauptverbindung (niedrigere Prio), das wird auch korrekt angezeigt. Trotzdem wird mein Rechner weiter über PLDT geroutet.
Das kann ich nur verhindern, wenn ich PLDT, also das Failback Gateway, gänzlich abschalte (selbst dann dauert es noch einige Zeit, bis OPNsense diesen Port nicht mehr verwendet).
Und ein abgeschaltetes Fallback Gateway ist ja nicht ganz der Sinn eines abgeschalteten Fallback Gateway...
#9
26.7 Series / Re: Crashes, and Kea DHCP Serv...
Last post by computer_freak_8 - Today at 12:32:37 AMQuote from: nero355 on September 16, 2026, 03:03:22 PMPost the output here and I will have a look for you too!
If the output looks good I would do a filesystem check (fsck or ZFS scrub) and the Health Check that OPNsense provides to make sure there is no corruption left behind.
Shoot! So at ~21 hours I bumped the keyboard, "Esc" key got wedged under the monitor, which exited the memtest and rebooted.
So I ran SMART checks (all supported test passed) and swapped the machine back.
If you have recommendations for Linux-y (Ubuntu is my go-to Live distro) commands to do the ZFS checks you can recommend, I'll do that at some point. (Or whatever the health check thing you mentioned is. Or if I can run the commands from the running OPNsense system - attempting to avoid a "Live" BSD though, just from my own comfort level.)
Also, might not be relevant, but at some point overnight (~3am local time), my "temporary" firewall stopped passing traffic, lights on NIC were good but no DHCP received on WANs, not responding to anything on LAN (or any other VLANs). I suspect this was because I YOLO'd it and didn't install os-realtek-re, but I guess we may never know, as I installed the package while troubleshooting the outage (lots of alerts to my phone), rebooted, and went back to bed.
#10
26.7 Series / OPNsense HA + BGP with our own...
Last post by brunorafa - Today at 12:15:38 AM**Title:** OPNsense HA + BGP with our own ASN and /24 — what architecture is recommended?
Hi everyone,
I would like to get some advice on the recommended architecture for using **BGP with OPNsense HA**, with two physical firewalls, our own IPv4 /24 prefix, and **IPsec VPNs that need to work redundantly across both firewalls**.
Our environment has:
- 2 physical OPNsense firewalls;
- HA configured with **CARP + pfsync + configuration synchronization**;
- A **Master/Slave** architecture, where the Master handles normal operations and the Slave takes over in case of failure;
- **Both firewalls need to be able to take over and operate the IPsec VPNs** during a failover;
- Our **own ASN**;
- Our own **IPv4 /24 prefix**, which will be advertised to our ISP;
- Both firewalls have independent physical connections to the same ISP.
So, we have two independent physical links:
```text
ISP 10.52.70.1 <----> OPNsense 01 10.52.70.2
ISP 10.52.70.5 <----> OPNsense 02 10.52.70.6
```
For BGP, we have flexibility with our ISP and can use **either a single BGP session or two independent BGP sessions**, one for each firewall.
### Option 1 — Two BGP sessions
```text
ISP
/ \
BGP BGP
| |
10.52.70.1 10.52.70.5
| |
10.52.70.2 10.52.70.6
OPNsense 01 OPNsense 02
MASTER SLAVE
\ /
---- HA/CARP ---
```
This is the setup we are currently using.
Each physical firewall has its own BGP session with the ISP, using our ASN and advertising the same /24 prefix.
The HA failover itself works: when we put the Master firewall into **maintenance mode**, traffic successfully moves to the Slave firewall.
However, we are seeing a behavior that makes us question the BGP architecture: **even after traffic has moved to the Slave, some flows appear to return through the Master firewall**, resulting in asymmetric routing.
At the same time, we need the Slave to take over not only the normal traffic handled by the Master, but also the **IPsec VPNs**, keeping connectivity during the failover.
This is what led us to question whether using **two independent BGP sessions**, one on each firewall, is actually the recommended approach for an OPNsense HA pair, or whether we should use a single BGP session associated with the active/Master firewall.
### Option 2 — Single BGP session
The other possibility would be to use a single BGP session associated with the Master firewall, with the Slave taking over the BGP session during a failover.
Our main question is **which of these two approaches is considered the more appropriate/recommended architecture for OPNsense in a HA setup with two physical firewalls, our own ASN, our own /24 prefix advertised via BGP, and IPsec VPNs that need to operate redundantly**.
We would especially like to understand how the OPNsense/FRR project recommends structuring this type of setup.
Thank you!
Hi everyone,
I would like to get some advice on the recommended architecture for using **BGP with OPNsense HA**, with two physical firewalls, our own IPv4 /24 prefix, and **IPsec VPNs that need to work redundantly across both firewalls**.
Our environment has:
- 2 physical OPNsense firewalls;
- HA configured with **CARP + pfsync + configuration synchronization**;
- A **Master/Slave** architecture, where the Master handles normal operations and the Slave takes over in case of failure;
- **Both firewalls need to be able to take over and operate the IPsec VPNs** during a failover;
- Our **own ASN**;
- Our own **IPv4 /24 prefix**, which will be advertised to our ISP;
- Both firewalls have independent physical connections to the same ISP.
So, we have two independent physical links:
```text
ISP 10.52.70.1 <----> OPNsense 01 10.52.70.2
ISP 10.52.70.5 <----> OPNsense 02 10.52.70.6
```
For BGP, we have flexibility with our ISP and can use **either a single BGP session or two independent BGP sessions**, one for each firewall.
### Option 1 — Two BGP sessions
```text
ISP
/ \
BGP BGP
| |
10.52.70.1 10.52.70.5
| |
10.52.70.2 10.52.70.6
OPNsense 01 OPNsense 02
MASTER SLAVE
\ /
---- HA/CARP ---
```
This is the setup we are currently using.
Each physical firewall has its own BGP session with the ISP, using our ASN and advertising the same /24 prefix.
The HA failover itself works: when we put the Master firewall into **maintenance mode**, traffic successfully moves to the Slave firewall.
However, we are seeing a behavior that makes us question the BGP architecture: **even after traffic has moved to the Slave, some flows appear to return through the Master firewall**, resulting in asymmetric routing.
At the same time, we need the Slave to take over not only the normal traffic handled by the Master, but also the **IPsec VPNs**, keeping connectivity during the failover.
This is what led us to question whether using **two independent BGP sessions**, one on each firewall, is actually the recommended approach for an OPNsense HA pair, or whether we should use a single BGP session associated with the active/Master firewall.
### Option 2 — Single BGP session
The other possibility would be to use a single BGP session associated with the Master firewall, with the Slave taking over the BGP session during a failover.
Our main question is **which of these two approaches is considered the more appropriate/recommended architecture for OPNsense in a HA setup with two physical firewalls, our own ASN, our own /24 prefix advertised via BGP, and IPsec VPNs that need to operate redundantly**.
We would especially like to understand how the OPNsense/FRR project recommends structuring this type of setup.
Thank you!
