"Recent posts
#1
26.1, 26,4 Series / Re: Virtual IP
Last post by Seimus - Today at 09:17:47 AMQuote from: SenseX on May 19, 2026, 09:48:18 PMI also read that you can use HAProxy, so I was playing around with that and managed to get it working.
That is not the solution you are looking for....
As mentioned by Patrick, you want to configure VRRP.
In FBSD its under CARP, in Linux its under keepalived.
This is an implementation local to the devices you want to co-join to be reachable with a single VIP for active/backup or loadblancing state.
So if its the Pihole you want to have the VIP, you need to configure it on the servers Piholes run. And not on the FW/GW.
Regards,
S.
#2
General Discussion / Re: Updater update?
Last post by franco - Today at 08:50:33 AMThat's the default. Yes there was a small update to opnsense-update, but it doesn't change your mirror.
The core update might at first since it resets the defaults, but the post-update hook should populate the correct mirror.
That's equivalent to running the following command:
# pluginctl firmware_reload
And rechecking your repo config:
# opnsense-update -O
Cheers,
Franco
The core update might at first since it resets the defaults, but the post-update hook should populate the correct mirror.
That's equivalent to running the following command:
# pluginctl firmware_reload
And rechecking your repo config:
# opnsense-update -O
Cheers,
Franco
#3
26.1, 26,4 Series / Re: One of the networks stops ...
Last post by opnseeker - Today at 07:17:27 AMAfter setting bridge-mssnoop to 0 and restarting the host, ip6 addresses are being assigned to devices on the bridge network.
It worked more than 3 times and is likely fixed.
Thanks for the help.
It worked more than 3 times and is likely fixed.
Thanks for the help.
#4
General Discussion / Re: Updater update?
Last post by patient0 - Today at 05:50:25 AMQuote from: borealis67 on Today at 01:19:13 AMPlease bear with me if I am not saying this well.How to you check the mirror it uses, in the web GUI, System: Firmeware > Status? It shows the same URL for me for the mirror '(default)', that is fine for sure.
Yesterday I noticed an update that updated the updater on my opnsense DEC850v1 device. I think it changed the mirror from which I get my updates. It now says https://pkg.opnsense.org/FreeBSD:14:amd64/26.1 is my mirror.
Was this legit?
No update should ever change the mirror.
#5
General Discussion / Re: Cannot get an interface up
Last post by patient0 - Today at 05:43:40 AMQuote from: ati on Today at 01:50:18 AMAny other things I should be looking into?What is the ISP2 device you're connecting to (type/model)?
- Add a small switch between igc1 and the ISP modem/router. The ISP modem/routers are sometimes very picky when it comes to auto negotiate speed
- Or try set the interface speed manually to something you know the ISP modem/router supports
- Or configure it as an additinal LAN(2) interface, connect it to a small switch. That should be enough to see if the link comes up
#6
26.1, 26,4 Series / Re: One of the networks stops ...
Last post by opnseeker - Today at 03:47:40 AMBridge vmbr1 is already VLAN aware. I added bridge-mcsnoop 0 now to vmbr1 configuration. I have to wait until tonight to restart the host.
I will post again after I restart and check.
Thanks for the suggestions.
I will post again after I restart and check.
Thanks for the suggestions.
#7
General Discussion / Cannot get an interface up
Last post by ati - Today at 01:50:18 AMI have a system with a 2 port Intel I225-V 2.5Gb card in it. (Interface igc0 and igc1).
I am currently using igc0 as my WAN interface to my 2.5Gb fiber service and it is working great. I recently got a second ISP and I am trying to connect it to igc1. No matter what I do I cannot get the NIC to even light up.
It feels like the interface is 'administratively down'. The only other explanation is hardware failure, but I find that a bit hard to believe. I've never had one port on a multi port NIC fail personally.
Any other things I should be looking into?
I am currently using igc0 as my WAN interface to my 2.5Gb fiber service and it is working great. I recently got a second ISP and I am trying to connect it to igc1. No matter what I do I cannot get the NIC to even light up.
- I have checked the cable by using it in igc0.
- I have tried several devices and several cables, no luck.
- I know it is not a firmware/driver issue as I am currently using an interface on the same card.
- I have the interface enabled, speed set to 1000 (just to be safe).
It feels like the interface is 'administratively down'. The only other explanation is hardware failure, but I find that a bit hard to believe. I've never had one port on a multi port NIC fail personally.
Any other things I should be looking into?
#8
General Discussion / Updater update?
Last post by borealis67 - Today at 01:19:13 AMPlease bear with me if I am not saying this well.
Yesterday I noticed an update that updated the updater on my opnsense DEC850v1 device. I think it changed the mirror from which I get my updates. It now says https://pkg.opnsense.org/FreeBSD:14:amd64/26.1 is my mirror.
Was this legit?
Thanks.
Yesterday I noticed an update that updated the updater on my opnsense DEC850v1 device. I think it changed the mirror from which I get my updates. It now says https://pkg.opnsense.org/FreeBSD:14:amd64/26.1 is my mirror.
Was this legit?
Thanks.
#9
General Discussion / Re: Kernel panic loading mlx4e...
Last post by Ritzy1506 - May 19, 2026, 11:24:54 PMQuote from: meyergru on May 16, 2026, 09:46:54 AMIs there any specific reason why you want to pass the adapters thru? That lays the burden of driving the adapters to FreeBSD, which traditionally is not particularly good at handling "exotic" hardware, all along on top of a virtualisation layer.
More often than not, people use Proxmox just because they want Linux to handle the hardware, because OpnSense is known to have problems with it, but in order to do that, you would use virtio, not passthru, see https://forum.opnsense.org/index.php?topic=44159.0
Thanks, no specific reason other than that's typically what is done with hardware like GPUs. Switched to virtio and it works with good performance for my needs, so I guess I can consider this solved. I would have expected these NICs to work in FreeBSD, but I suppose there could be something different due to it being passthru. Working solution anyways, so thanks for the help :)
#10
German - Deutsch / Re: LogIn-Seite vor Captive Po...
Last post by NausB - May 19, 2026, 11:21:09 PMKernfrage aus meinen ersten Punkten wäre wohl eher:
**Wie bekommt man unter OPNsense 26.1.2 einen internen Webserver zuverlässig als Walled-Garden-/Pre-Auth-Ziel vor dem Captive-Portal-Login erreichbar?**
Daher danke für die Rückfrage, meine Beschreibung war vermutlich nicht präzise genug.
Sind die **Allowed Addresses** im Captive Portal dafür der richtige Weg, oder braucht es zusätzlich eine andere Konfiguration?
Und gibt es bekannte Besonderheiten, wenn das Ziel in einem anderen internen Netz liegt, also z. B.:
`GUESTNET → Servernetz 100.10.0.0/24`
Mit ,,Weiterleitung" meinte ich nicht den QR-Code selbst, sondern das Verhalten des Captive Portals:
Wenn ein nicht angemeldeter Client den QR-Code scannt und `http://zimmerservice.hotel/` aufruft, wird der Aufruf normalerweise vom Captive Portal abgefangen und auf die Captive-Portal-Loginseite umgeleitet.
Der QR-Code soll idealerweise nur enthalten:
`http://zimmerservice.hotel/`
Der Hostname wird intern per Unbound Host Override auf `100.10.0.5` aufgelöst. Der eigentliche Flask-/Zimmerservice läuft aktuell auf einem Sonderport, im Test zuletzt auf `18060` statt ursprünglich `8060`.
Port `18060` wurde gewählt, weil `8060` im Bereich des Captive-Portal-Logins `8000–10000` liegt und ich diesen möglichen Fehler ausschließen wollte.
Der Port ist also nicht wirklich ,,sicher verschleiert", das war von mir ungenau formuliert. Gemeint war eher: Der Gast soll im Normalfall keine IP-Adresse und keinen Port sehen, sondern nur den lokalen Namen `zimmerservice.hotel`.
Der Hinweis mit dem Reverse Proxy ist vermutlich genau der richtige Punkt. Sauberer wäre wahrscheinlich:
`http://zimmerservice.hotel/`
→ Port 80 auf dem Server / Reverse Proxy
→ intern weiter auf Flask `127.0.0.1:18060` oder `127.0.0.1:8060`
Dann müsste im Captive Portal / in der Firewall vor Login nur noch
`GUESTNET → 100.10.0.5 TCP 80`
erlaubt werden und nicht der Sonderport.
Mein eigentliches Problem ist aktuell:
Der Zugriff auf `100.10.0.5:18060` vor dem Captive-Portal-Login funktioniert geräteabhängig. Bei manchen Geräten klappt es, bei anderen sehe ich im Log `Default Captive Portal block rule (zone 0)` oder teilweise gar keinen passenden Eintrag.
Beispiele:
* Ein altes Samsung A40 öffnet die gewünschte Seite mal ja, mal nein.
* Ein aktuelles PEAQ PET10182 Tablet hat die Seite bei jedem Versuch sauber geöffnet.
* Ein Xiaomi 14 Ultra zeigte im Firewall-Log teilweise gar keine Reaktion, leitete teilweise auf die Standard-Captive-Portal-Loginseite um oder öffnete die gewünschte Seite erst beim dritten oder vierten Versuch.
Daher die Frage, ob der Weg über Sonderport/Walled Garden grundsätzlich ungünstig ist und ob ein Reverse Proxy auf Port 80 die sauberere Lösung wäre.
@viragomann:
Ergänzung zur Klarstellung:
Für die letzten Tests mit Port `18060` habe ich den QR-Code nicht verwendet, weil der gedruckte QR-Code noch auf `http://zimmerservice.hotel/` zeigt.
Ich habe deshalb manuell getestet mit:
`http://zimmerservice.hotel:18060/`
und alternativ direkt mit:
`http://100.10.0.5:18060/`
Der Sonderport war bei diesen Tests also bewusst Teil des Aufrufs. Das Ziel war nur zu prüfen, ob der Zugriff vor Captive-Portal-Login auf einen internen Webserver außerhalb des ursprünglichen Ports `8060` zuverlässiger funktioniert.
Langfristig wäre der gewünschte Zustand weiterhin:
`http://zimmerservice.hotel/`
ohne sichtbaren Port für den Gast, vermutlich dann über Port 80 / Reverse Proxy auf dem Server.
**Wie bekommt man unter OPNsense 26.1.2 einen internen Webserver zuverlässig als Walled-Garden-/Pre-Auth-Ziel vor dem Captive-Portal-Login erreichbar?**
Daher danke für die Rückfrage, meine Beschreibung war vermutlich nicht präzise genug.
Sind die **Allowed Addresses** im Captive Portal dafür der richtige Weg, oder braucht es zusätzlich eine andere Konfiguration?
Und gibt es bekannte Besonderheiten, wenn das Ziel in einem anderen internen Netz liegt, also z. B.:
`GUESTNET → Servernetz 100.10.0.0/24`
Mit ,,Weiterleitung" meinte ich nicht den QR-Code selbst, sondern das Verhalten des Captive Portals:
Wenn ein nicht angemeldeter Client den QR-Code scannt und `http://zimmerservice.hotel/` aufruft, wird der Aufruf normalerweise vom Captive Portal abgefangen und auf die Captive-Portal-Loginseite umgeleitet.
Der QR-Code soll idealerweise nur enthalten:
`http://zimmerservice.hotel/`
Der Hostname wird intern per Unbound Host Override auf `100.10.0.5` aufgelöst. Der eigentliche Flask-/Zimmerservice läuft aktuell auf einem Sonderport, im Test zuletzt auf `18060` statt ursprünglich `8060`.
Port `18060` wurde gewählt, weil `8060` im Bereich des Captive-Portal-Logins `8000–10000` liegt und ich diesen möglichen Fehler ausschließen wollte.
Der Port ist also nicht wirklich ,,sicher verschleiert", das war von mir ungenau formuliert. Gemeint war eher: Der Gast soll im Normalfall keine IP-Adresse und keinen Port sehen, sondern nur den lokalen Namen `zimmerservice.hotel`.
Der Hinweis mit dem Reverse Proxy ist vermutlich genau der richtige Punkt. Sauberer wäre wahrscheinlich:
`http://zimmerservice.hotel/`
→ Port 80 auf dem Server / Reverse Proxy
→ intern weiter auf Flask `127.0.0.1:18060` oder `127.0.0.1:8060`
Dann müsste im Captive Portal / in der Firewall vor Login nur noch
`GUESTNET → 100.10.0.5 TCP 80`
erlaubt werden und nicht der Sonderport.
Mein eigentliches Problem ist aktuell:
Der Zugriff auf `100.10.0.5:18060` vor dem Captive-Portal-Login funktioniert geräteabhängig. Bei manchen Geräten klappt es, bei anderen sehe ich im Log `Default Captive Portal block rule (zone 0)` oder teilweise gar keinen passenden Eintrag.
Beispiele:
* Ein altes Samsung A40 öffnet die gewünschte Seite mal ja, mal nein.
* Ein aktuelles PEAQ PET10182 Tablet hat die Seite bei jedem Versuch sauber geöffnet.
* Ein Xiaomi 14 Ultra zeigte im Firewall-Log teilweise gar keine Reaktion, leitete teilweise auf die Standard-Captive-Portal-Loginseite um oder öffnete die gewünschte Seite erst beim dritten oder vierten Versuch.
Daher die Frage, ob der Weg über Sonderport/Walled Garden grundsätzlich ungünstig ist und ob ein Reverse Proxy auf Port 80 die sauberere Lösung wäre.
@viragomann:
Ergänzung zur Klarstellung:
Für die letzten Tests mit Port `18060` habe ich den QR-Code nicht verwendet, weil der gedruckte QR-Code noch auf `http://zimmerservice.hotel/` zeigt.
Ich habe deshalb manuell getestet mit:
`http://zimmerservice.hotel:18060/`
und alternativ direkt mit:
`http://100.10.0.5:18060/`
Der Sonderport war bei diesen Tests also bewusst Teil des Aufrufs. Das Ziel war nur zu prüfen, ob der Zugriff vor Captive-Portal-Login auf einen internen Webserver außerhalb des ursprünglichen Ports `8060` zuverlässiger funktioniert.
Langfristig wäre der gewünschte Zustand weiterhin:
`http://zimmerservice.hotel/`
ohne sichtbaren Port für den Gast, vermutlich dann über Port 80 / Reverse Proxy auf dem Server.
