Messages

Die legt er ja auch automatisch an:

Ich hoffe das Bild wird korrekt Eingebunden... Target ist default eben (self) was WAHRSCHEINLICH VIP ignoriert.

- Im unbound stellst du Sicher, dass "Do not register system A/AAAA records" = Aus. -> Dann hat der Unbound für seinen Hostname ebenfalls die LAN IPs gebunden. -> Bug 1) Keine Carp/Alias IPs! Nur Interface IPs!

Dem öffentlichen DNS ist es egal, ob es eine CARP VIP ist oder sonst eine virtuelle oder native IP.

Ich rede vom internen DNS Resolver, öffentlich ist mir das nur soweit egal, dass ich ein gültiges Zertifikat bekomme, welches ein Laptop/Smartphone verifizieren kann.

unbound macht bei mehreren IPs dann sowas, die interne Logik im CP zieht das dann grade, dass du auf jedem CP Interface den Hostname korrekt bekommst, hab die internen IPs und WAN IP mal randomized:

root@node:~ # drill @127.0.0.1 node.example.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 29498
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 17, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; node.example.com. IN      A

;; ANSWER SECTION:
node.example.com.    3600    IN      A       123.123.123.123
node.example.com.    3600    IN      A       10.56.78.2
node.example.com.    3600    IN      A       10.90.12.2
node.example.com.    3600    IN      A       172.20.10.2
node.example.com.    3600    IN      A       192.168.45.2
node.example.com.    3600    IN      A       10.200.150.2
node.example.com.    3600    IN      A       172.25.60.2
node.example.com.    3600    IN      A       192.168.88.2
node.example.com.    3600    IN      A       172.18.200.2
node.example.com.    3600    IN      A       172.22.33.2
node.example.com.    3600    IN      A       172.29.99.2
node.example.com.    3600    IN      A       172.30.10.2
node.example.com.    3600    IN      A       172.19.140.2
node.example.com.    3600    IN      A       172.21.170.2
node.example.com.    3600    IN      A       172.23.210.2
node.example.com.    3600    IN      A       172.24.240.2
node.example.com.    3600    IN      A       10.77.66.2

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 127.0.0.1
;; WHEN: Thu Mar 19 16:20:20 2026
;; MSG SIZE  rcvd: 301
root@node:~ #

-> Interface hat die .2 und CARP die .1, es fehlt in der Liste also alles nochmal mit .1

Hast du auch ein Port Forwarding eingerichtet. Wenn CP nur auf die Interface IP lauscht, wird es anders nicht funktionieren.

DNS Namensauflösung muss am Client natürlich vor Anmeldung möglich sein.

Das Port forwarding legt das CP eigentlich an. Was es für die .2 auch tut, für die .1 eben noch nicht.

was genau hat denn CP mit DHCP zu tun? Abgesehen von der Option 114, mit der der DHCP das CP für "moderne Geräte" bekannt geben sollte.
Verstehe ich hier etwas nicht?

Ich nutze nicht CP zusammen mit HA. Vielleicht fehlt mir hier was. Aber DHCP und CP laufen doch völlig getrennt ab. Erst bekommt der Client vom DCHP Server eine IP, dann bemerkt er erst, dass er sich hinter einem CP befindet und geht auf desen Seite oder wird dahin gezungen.

Der Client muss halt per DHCP seine IP und seinen Gateway/DNS bekommen. Wenn dieser die CARP IP ist, gehts nicht. Wenn diese die Interface IP ist, gehts. Das ist der Bug daran.

Wie oben geschrieben, habe ich in CP einen Hostnamen eingetragen, der auf meine öffentliche IP gemappt ist, und SSL aktiviert. Das könnte ebenso die CARP IP sein. DNS Auflösung geht auch ohne CP Session.
Und wie ebenfalls zuvor geschrieben, könnte man die Anfragen auf diese öffentliche (CARP) IP einfach auf die CP-aktive Interface IP weiterleiten. Dann gehen sie immer dahin, wo sie hin sollen.
In meinem Kopf funktioniert das. In der Praxis nicht?

- Zertifikat holen via ACME auf Öffentliche WAN per HTTP-01 oder bei DNS-01 -> Fein.
- Im unbound stellst du Sicher, dass "Do not register system A/AAAA records" = Aus. -> Dann hat der Unbound für seinen Hostname ebenfalls die LAN IPs gebunden. -> Bug 1) Keine Carp/Alias IPs! Nur Interface IPs!
- DHCP konfigurieren -> KEA -> Subnetz A/B/C -> "Auto collect option data" = AN -> Gateway wäre damit die Interface IP -> Alles geht. Bei "Auto collect option data"=Aus -> Gateway eintragen -> Carp/Alias IP -> Client bekommt diese als Gateway. Bis hier hin funktioniert das auch.
- Dieses Zertifikat im CP Dienst auswählen -> Selben Hostname wie im Zertifikat setzen. -> Fein. Für nicht CARP/Alias IPs funktioniert es hier sofort!
- Im CP Dienst entsprechend das Interface auswählen. Und jetzt entscheidet sich das...

Client bekommt DHCP -> Fall A nicht mit CARP): Ist eine Interface IP -> Gateway ist sagen wir mal die .2 -> Captive Portal wird forciert, weil Firewall Regel alles auf CP Interne IP .2 umbiegt -> CP geht auf, macht sein Ding. Läuft. Im HA Fall -> .2 geht aus. Client hat weiterhin sein Gateway auf die .2, ist defakto offline bis der Client sich entscheidet wieder DHCP refresh zu machen, bekommt die .3 als GW von der zweiten Node, bekommt wieder ein CP, kann sich einloggen. -> Client merkt also nur, dass er offline ist, aber bliebt weiterhin mit dem WLAN verbunden, is halt nur offline. Kunden experience fürn ...

Fall B mit CARP): Ist eine CARP IP -> Gateway ist sagen wir mal die .1 -> Captive Portal wird forciert, wird aber auf die .2 umgeleitet (Weil BUG 2), sollte aber trotzdem aufgehen, würde ja trotzdem auf die .2 gebunden sein, tuts aber nicht. (Vielleicht immer noch BUG 2 oder schon BUG 3)
Sagen wir mal das wäre gefixed an dem Punkt und gehen weiter. HA Fall tritt ein, IP .1 wechselt auf Node2 -> Gateway wäre immer noch identisch. Client bekommt wegen fehlendem Sessions Sync (Potentielles Roadmap Feature) nur ein neues CP angezeigt, logged sich ein und alles geht weiter, weil .1 weiterhin Gateway, DHCP muss nix machen.

In meinem akkuten Fall benötige ich ungefähr ein dutzend CARP Interfaces jeweils einem eigenen VLAN, aber das Problem ist schon bei N=1 existent.

Mit den Sessions/Vouchern war mit bekannt. Aber das sehe ich weniger schlimm. Bei einem HA Switch, wird dem User dann automatisch einfach nur ein neues CP angezeigt, meist auch mit einem Geräusch am Gerät. Aber im aktuellen Modus im HA Sinne bricht es halt vollständig ab ohne Userbenachrichtigung auf dem Gerät (Bist halt einfach ohne Route offline) bis ein User aktiv die Verbindung trennt und neu aufbaut. (Neue DHCP Lease)

Deswegen wäre das mit dem CARP als erster Schritt sinnig. Roadmap Feature wäre dann ein Session/Voucher Sync um es vollständig rund zu machen.

Zertifikate für RFC1918 LAN IPs geht aber trotzdem nicht: Zitat: "And, probably not surprisingly, you can't use the DNS challenge method to prove your control over an IP address; only the http-01 and tls-alpn-01 methods can be used."

Servus Zusammen,

ich habe genau das gleiche Problem mit CARP/HA und Captive Portal.

Zur angefragten Begründung: Weil es einfach Sinn macht.
Genauer:

In einem Normalen und einem HA Setup kann ein Client ja nur eine Default GW Route haben. In einem Normalen Setup kann sich diese ja nicht ändern, gibt ja nur eine IP. Bei 2+ Nodes und der Implementation von HA von OPNsense (In dem IPs von Interfaces nicht repliziert werden wenn ein Failover passiert) müssen die Nodes also auf eine geteilte IP zurückgreifen um dem Client einen immer verfügbaren Gateway zu stellen. Wenn das nicht so wäre und ein Schwenk passiert, macht ein Client ja nicht einen erneuten DHCP request und bekommt dadurch einen anderen Gateway sondern läuft in eine nicht mehr verfügbare IP und hat dementsprechend keine Verbindung mehr. Kein erneutes CP weil die Session auf dem zweiten Node fehlt (Nächstes Problem!). Aber für den User ist das einfach nur ein Totalausfall der Verbindung. Also das genaue Gegenteil von HA.

Was ich im Source bisher finden konnte, ist, dass im CP Dienst (Template Generierung) und im Unbound beim registrieren der system A/AAAA records ausschließlich die Interface IP genommen wird und nicht alle IPs (CARP/Alias) eines Interfaces.

Für ein funktionierendes CP mit moderner Hardware ist ja ein gültiges Zertifikat gesetzt. Das bekommste auch nicht für IPs. Im OPNsense single Node Normalfall, macht der Dienst das alles selbst (CP+DNS) und funktioniert sehr gut. Im HA/CARP Setup geht aktuell gar nichts.

Please Help anyone?

Firewall zwischen öffentlichen IPs seh ich jetzt eher als nieschendasein als die Regel im Business Umfeld, wo macht man denn das so häufig?

In einem RZ im Hosting-Umfeld? Ich muss ja die Bleche der einzelnen Kunden, die alle öffentliche IP-Adressen haben - sonst stünden sie nicht in meinem RZ - irgendwie voneinander isolieren.

Verstanden danke für das Beispiel. Wenn man ne Firewall als "Dienstleistung" anbietet macht das natürlich Sinn.

Die Frage ist nur, wie oft wird eine OPNsense als Router oder VPN Gateway für Firmennetze eingesetzt vs. wie oft ist sie "nur" eine Firewall in einem öffentlichen Umfeld und warum würde man es in einem Router Umfeld dem jeweiligen Admin es extra schwer tun sein System sicher zu konfigurieren?

Egal. Ich würde vorschlagen wir schließen die Diskusion hier. Ich danke vor allem dir, Patrick. Auch Dank an meyergru.

Dann erklär das mal den üblichen Verdächtigen mit OpnSense hinter einer Fritzbox ;-)

WAN Interface = ISP = routebare IP ist eben nur für den Heimanwender der Standardfall, nicht im Business-Umfeld. Und wie viele Heimanwender nutzen schon OpnSense?

Irgendwie wiedersprichst du dir damit selbst, ich kapiers leider nicht. Sorry. Könntest du das nochmal überarbeiten was du genau aussagen willst?

OPNsense ist für mich entweder das Business Produkt oder für den Interressierten, dem halt ne FritzBox nicht langt, diese dann in den Modem Status setzt und dann halt einfach alles über einen Server, MiniPC oder VM etc. löst. Ich glaube auch nicht daran, dass im Produkt OPNsense alles für jeden DAU einfach sein MUSS. Aber zumindest Sicher sollte es doch per default sein UND man sollte nach Möglichkeit die Notwendigkeit eines Support Tickets oder Hilfe ersuchens niedrig halten. Die machen Arbeit und das will man ja eigentlich in seiner Freizeit nicht. Weil ich das so sehe und keinem unnötige Arbeit machen will, verhalte ich mich halt entsprechend. Wenn man dann noch die Gatekeeping Keule bekommt fühlt man sich halt eher bestätigt und welchselt lieber das Produkt als am Ball zu bleiben.

@ Patrick
Firewall zwischen öffentlichen IPs seh ich jetzt eher als nieschendasein als die Regel im Business Umfeld, wo macht man denn das so häufig?

Typisch für IPv4 würde ich finden:
Öffentliche IP -> WAN -> DMZ Netz RFC1918 -> WAN 2. FW RFC1918 -> LAN RFC1918
Oder:
Öffentliche IP -> WAN -> LAN RFC1918
Oder ggf  noch:
Öffentliche IP -> MODEM -> WAN RFC1918 -> LAN RFC1918

Bei V6 vielleicht eher mit öffentlichen. Mal gucken wann. ;-)

@michael.seidel der Ton ist verbesserungsfähig, aber einen validen Punkt hat Bob - wenn du das für einen Bug hältst, ist der einzige Weg, das sinnvoll zu kanalisieren, ein Issue auf Github. Hier ist User-Forum. Die Entwickler schauen zwar ab und zu mal rein, aber wie gesagt, Bug Reports --> Github. Sonst passiert mit Sicherheit nichts.

Ich hoffe, wir haben dich nicht gleich ganz vergrault :-)

Gruß
Patrick

Vielen Dank dass du das so siehst, Patrick. Ich werde wohl einen offiziellen Feature Request schreiben, da ich eine dedizierte Liste für die richtige Lösung halte und es keine per default gibt. Ich habe zuerst hier nachgefragt warum denn das nicht geht, weil ich nur die offizielle Liste im PKG Repo gefunden habe und dann erst im laufenden Gespräch gelernt habe, dass das Update Script aus seiner offiziellen Liste Einträge entfernt. Mit einem lapidaren Kommentar im Source, dass es wo anders eine Option dafür gibt, welche es eigentlich nicht gibt. Für die Richtung "Internet -> WAN" gibt es ja den Block via GUI Option. Dies ist halt nur der halbe Kuchen.

RFC1918 Traffic hat auf einem WAN interface ausgehend per Default nichts zu suchen. Wenn jemand eine OPNsense hinter seiner FritzBox im Homelab betreibt und eine RFC1918 Adresse dafür braucht, sollte dieser dafür eine Opt-In GUI Option bekommen. Die typischen Provider blocken dir die halt einfach in ihren Systemen weg und ignorieren dies. Manche tun dies halt nicht und schreiben dir für jeden "Missbrauch" einer Bogons IP ein Abuse Ticket.

Mein einfacher Vorschlag hierfür wäre "bogon networks (internal)" umzubenennen in sowas wie "bogon networks w/o RFC1918 (internal)" und ein weiteres default alias anzulegen welches einfach nur "RFC1918 (internal) heisst und die User mal machen zu lassen.

Alternativ eben Bogons im korrekt definierten Bereich lassen und eine Option einzufügen, welche alle RFC1918 AUSSER das anliegende WAN net ausgehend blockiert.

Mal gucken, vielleicht wirds ja auch einfach abgelehnt und anders gesehen. Will doch nur die Welt ein kleines bisschen verbessern. ;-P

Dann mach doch einen ordentlichen Bug-Report auf Github... aber mit ganzen vier Posts im Forum sollte man doch eher Abstand davon nehmen. Zur eigentlichen Fragestellung, Bogons und private IP-Adressen sind aufgesplittet, weil man ggf. das eine erlauben und das andere verbieten will. Du regelst selbst, was Du möchtest. Und wenn Du es nicht gebacken bekommst, einen Host bei dir unter Kontrolle zu bringen, dann kreierst Du dir halt eine Regel in der Art wie im zweiten Beitrag gezeigt.   

Herzlichen Dank, dass man mir Unfähigkeit unterstellt nur weil ich mich vorher nie in diesem Forum angemeldet habe und Dinge besprochen habe. Ich habe immer alles alleine lösen können. Gatekeeping vom feinsten. Vielen Dank für das Augenöffnen Bob.Dig!

Wenn man nur einmal eine Sache nicht verstanden hat, weil:
1) eine öffentliche Liste da ist (1)
2) die Offizielle Quelle dies vorsieht (der Eintrag ist ja da!)
3) welche dann nicht vollständig umgesetzt wird (Siehe /usr/local/etc/bogons )
4) obwohl die Definition des Begriffes klar ist (2)
5) nur anscheinend das Update Script in Zeile 61 das wieder raus nimmt.

Top. Mach ich halt auf jeder Kiste ne eigene Liste mit genau diesen rausgenommenen IP Ranges. Da geht ja wenigstens JSON Import/Export.

OPNsense verwendet die Datei /usr/local/etc/bogons. Da stehen bei mir keine privaten Adressbereiche drin. Schon mal das Häkchen bei Interfaces: [WAN]: Block private networks probiert?

Das blockt leider nur von AUSSEN nach INNEN. Das funktioniert aber, habe ich getestet.

Sehe ich ich. Bogons <> RFC1918. Wenn Du letztere auch blocken willst, brauchst Du auch eine Regel dafür.

Warum gibt es denn dann die "Update" Datei im PKG Repo mit genau diesem Eintrag? Das macht doch auch keinen Sinn warum das dann nicht zurück zum System kommt. Auch die Definiton der RIPE sieht vor, dass RFC1918 inkludiert sein soll.

Siehe: https://www.ripe.net/publications/docs/ripe-431/

4.3. Other filters: bogon prefix filtering
4.3.1. What are bogon prefixes?

A bogon prefix as defined by Cymru [1] is "a route that should never appear in the Internet routing table. A packet routed over the public Internet (not including over VPN or other tunnels) should never have a source address in a bogon range. These are commonly found as the source addresses of DDoS attacks".

For the purpose of this how-to, a packet received on an interface of a router is considered bogon if it's source address should not be routable through that interface. This definition of bogon includes "martian" addresses (as listed in RFC 1918 and RFC 3330) and unallocated addresses as explained in the next subsection. Also included are addresses from networks that are always connected to other interfaces of the router.

Also für mich ist das ein Bug, welcher die aktuelle Bogons Liste nicht runterläd/aktualisiert.

Vollständige Liste siehe: https://pkg.opnsense.org/bogons/fullbogons-ipv4.txt

*snip aus der Datei*

192.156.142.0/24
192.156.152.0/23
192.160.29.0/24
192.168.0.0/16
192.172.245.0/24
192.172.246.0/24
192.188.80.0/24

Sorry für den "Late Reply".

Wie ich ursprünglich schrieb, wird die vorgeschlagene OUT Rule Eiskalt ignoriert.

Habe da mal zwei Screenshots angehängt.

Noch jemand einen Tipp?

Hallo Zusammen!

Ich habe das akute Problem, dass ich beim großen Cloud Anbieter H. andauernd Abuse bekomme, weil ein Client eine BOGONS IP "scannt".

Meine Frage ist, warum geht die Firewall Regel mit WAN/BLOCK/IPV4*/OUT/Destination Gruppe "Bogons" nicht?

Es wird immer die Standard Regel "let out anything from firewall host itself (force gw)" dafür verwendet, wenn er seine Default Route nutzt um eben die Bogons von der Richtung LAN->WAN->Internet zu erreichen.

Irgendwo habe ich noch gefunden, man muss dafür eine Floating Regel benutzen. Greift auch nicht.

Ich habe es auch mal versucht über eine manuelle NAT Regel den gewünschten Effekt zu erreichen:

Interface WAN / Source LAN net / Source * / Dst !Bogons / Dst Port * / NAT IF add / Nat Port * / Static NO

Ging auch net. Sah aber Zielführender aus.

Könnte mir bitte jemand erklären warum das nicht geht? Oder noch besser, wie es denn geht? ;-)

Vielen Herzlichen Dank für die Zeit!