"Recent posts
#1
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?
#2
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.
#3
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 :)
#4
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.
#5
German - Deutsch / Re: IPv6 am PON-Anschluss von ...
Last post by mbr89 - May 19, 2026, 11:10:43 PMQuote from: Patrick M. Hausen on April 28, 2026, 09:47:25 PMUnd dann versuchst du ernsthaft, das trotzdem ans Laufen zu kriegen? Dafür wäre mir meine Zeit zu schade. Providerwechsel oder Lösung über Tunnel.
Providerwechsel ? Vodafone DOCSIS ? NetCom BW VDSL2 mit 35 MBit/s ohne IPv6
Man sollte mal über Auswandern nachdenken ....
#6
26.1, 26,4 Series / Re: DS-Lite (PPPoE|DHCPv6-PD) ...
Last post by franco - May 19, 2026, 09:58:11 PMEventually I'd like to add some from of automatic AFTR setup and now I see that Uwe is offering a testbed :)
It should already be exposed to dhcp6c-script and with minimal plumbing we can add it to ifctl and then we need a good idea for integration into the GIF tunnel which may need some reading of DS-Lite setup and figuring out provider quirks.
Cheers,
Franco
It should already be exposed to dhcp6c-script and with minimal plumbing we can add it to ifctl and then we need a good idea for integration into the GIF tunnel which may need some reading of DS-Lite setup and figuring out provider quirks.
Cheers,
Franco
#7
26.1, 26,4 Series / Re: Virtual IP
Last post by Patrick M. Hausen - May 19, 2026, 09:56:52 PMQuote from: SenseX on May 19, 2026, 09:48:18 PMYes, I have two Pi-holes acting as primary and secondary DNS servers. But instead of using two IPs, I'd like to use a virtual IP.
That's not an OPNsense topic. Just configure CARP on both Pi-holes. Done.
#8
26.1, 26,4 Series / Re: Virtual IP
Last post by SenseX - May 19, 2026, 09:48:18 PMThank you all for the suggestions and for the links, I'm going to check them out as well.
I also read that you can use HAProxy, so I was playing around with that and managed to get it working.
Yes, I have two Pi-holes acting as primary and secondary DNS servers. But instead of using two IPs, I'd like to use a virtual IP.
I also read that you can use HAProxy, so I was playing around with that and managed to get it working.
Yes, I have two Pi-holes acting as primary and secondary DNS servers. But instead of using two IPs, I'd like to use a virtual IP.
#9
26.1, 26,4 Series / Re: DS-Lite (PPPoE|DHCPv6-PD) ...
Last post by meyergru - May 19, 2026, 09:10:57 PMAh, I see. In case anyone stumbles over this again, you not only have to set IPv4 of the WAN interface to "None", but also create a GIF tunnel like this (parameters are shown for M-Net):
You cannot view this attachment.
That also works for my non-DS-Lite account.
You cannot view this attachment.
That also works for my non-DS-Lite account.
#10
German - Deutsch / Re: MTU richtig setzen
Last post by cottec - May 19, 2026, 08:23:20 PMQuote from: eric1905 on May 14, 2026, 03:14:46 PMIch habe jetzt im WAN interface den MSS auf 1492 gesetzt und MSS in meinen VLANS auch. Nach einem Neustart habe ich in Wireshark noch das gleiche Aussehen:
Hast du die Einstellungen nochmal geändert?
Geht es jetzt bei dir?
