Messages

Jeh-mi-neeeee.   :-(

Du hast völlig Recht, die virtuelle IP ist überflüssig. Keine Ahnung, wie ich initial auf DEN Trichter gekommen bin.
In der Rückschau: 5 Klicks und fertig. Stattdessen so ein Aufriss hier. Aber wieder was gelernt...

Nochmals DANKE für die Aufklärung!!!

LG
JBO

Problem gelöst.

Jetzt muß ich allerdings Abbitte leisten, denn das Ganze hat sich als viel Lärm um Nichts herausgestellt...

Ich hatte die ganze Zeit die Virtual IP (1.2.3.4 in meinem Schaubild) auf dem EXTERNEN Interface (und testhalber auch auf EXT und INT parallel, um die Regel als Floating zu erhalten) aufgesetzt. Aber nie exklusiv auf dem INTERNEN Interface...

Heute habe ich nach Euren Anregungen nochmal tabula rasa gemacht und beim Neuaufsetzen kam ich ins Grübeln, ob die VirtualIP nicht eigentlich exklusiv auf die INTERNE Schnittstelle gehört. So, wie ich es (falsch - mea culpa) auch im Schaubild eingezeichnet hatte.

Und siehe da: VirtualIP auf dem KORREKTEN Interface (INT) plus Standard Port Forwarding (schon immer INT) => FUNKTIONIERT

Ganz herzlichen Dank an alle, die mir zugehört haben ;-) bzw. mich mit Ihrem Feedback zum Neuaufsetzen gebracht haben! Es tut mir Leid um Eure Zeit - aber vielleicht hilft es ja jemand anderem (der den ganzen Thread bis zu Ende liest)...

Wenn Ihr mal in Hamburg sein solltet: meldet Euch und ich lade auf einen Drink ein!

LG
JBO

PS: Warum mit meinem falschen Setup das Portforwarding TROTZDEM funktionierte, wenn ich einen Port ungleich 80 (also z.B. Port 81) benutzt habe, erschließt sich mir allerdings immer noch nicht. Können wir dann bei einem Drink vertiefen...   ;-)

Hi JeGr,

leider kann ich ein Split-DNS nicht nutzen - da kämpfe ich noch mit unserer internen IT und sehe quasi keine Erfolgschance...

Warum so kompliziert?

In den Zertifikaten für die RootCA und die IssuingCA kann ich zwar sowohl die externe als auch die interne IP für die Ablage der Certificat Revocation Lists angeben - aber diese werden der Reihe nach abgearbeitet und führen dann zwangsläufig zu Timeouts/Wartezeiten für die jeweilige Nutzerfraktion, die NICHT an erster Stelle steht. Am häufigsten greifen interne Nutzer zu, aber dann würden  die Timeouts bei Kundenpräsentationen auftreten (die immer von extern kommen, weil direkt von iOS-/Android-Devices und niemals z.B. über ein VPN zugegriffen wird)...

Daher das Ziel, an erster Stelle in der CLR einen über das Internet/die PublicIP erreichbaren CRL Distribution Point anzugeben, der sowohl von extern (Portforwarding in der vorgelagerten CheckPoint) als auch von intern (Portforwarding über die opnSense - oder DSTNAT, wie malaclypse vorschlägt (noch nicht zum Testen gekommem)) erreichbar ist.

Mein ursprüngliches Setup sah vor, gar nichts auf der internen opnSense zu machen, aber dann gehen die Pakete an die PublicIP 1.2.3.4 auf der opnSense durchs NAT (SourceIP jetzt nicht mehr 192.168, sondern 10.42, Destination-IP weiterhin 1.2.3.4) und an die externe Firewall. Dort werden sie auf den internen Webserver zurück-"reflektiert". Da der im selben Subnetz steht wie die opnSense, gehen die Pakete dann direkt zur opnSense zurück und nicht mehr über die externe Firewall. Und dann verrecken sie dort an der opnSense.

Ich reime mir zusammen, weil in der NAT-Tabelle der opnSense kein passender Eintrag zu finden ist - denn die Pakete kommen jetzt ja nicht mehr von 1.2.3.4 zurück (dafür müßte es einen Eintrag geben), sondern von 10.42.xx.12 (kein Eintrag in der NAT-Tabelle).

ABER: ich nehme Deine Anregung auf und teste, ob sich etwas ändert, wenn ich das Port Forwarding auf das EXTERNE Interface ändere...

Falls Dir noch ein Fehler in meinem Setup auffällt bin ich für jeden Hinweis dankbar!

LG
JBO

Von innen. Der Zugriff aus dem Internet über die PublicIP funktionierte von Anfang an - dieser hat mit der opnSense auch erstmal nichts zu tun, sondern wird über eine vorgelagerte CheckPoint geforwarded.

Ich bemerke gerade, daß der Thread-Titel etwas unglücklich gewählt ist. Ich versuche wie oben beschrieben, die Pakete aus meinem internen 192.168er Netz NICHT über die PublicIP der vorgelagerten Firewall laufen zu lassen.

Denn nachdem ein 192.168er Paket von intern durch die opnSense geht, wird ja bereits ein NAT auf eine 10.42er Adresse durchgeführt. Wenn die vorgelagerte Firewall das Paket nun an den Webserver zurückleitet (NAT Reflection), dann sendet dieser es wiederum DIREKT zu opnSense. Dort wird es dann aber verworfen, weil es ja nicht mehr zu den Einträgen der NAT-Tabelle der opnSense paßt, wo Absender = PublicIP erwartet wird und nicht Absender = Webserver.
So zumindest mein Verständnis...

Danke für Eure Rückmeldungen!

@pmhausen - das Deaktivieren der Anti-Lockout-Regel ändert leider nichts am Verhalten. Port 80 landet weiter auf der opnSense-UI, Port 81 dagegen wird ordentlich an den Zielrechner (Port 80) weitergeleitet...

@malaclypse - mit Destination NAT meinst Du Outbound im opnSense-Speak? Dann stelle ich auf "Hybrid - erst manuelle, dann automatische Regeln" um? Werde ich ausprobieren...

Nocheinmal Hallo!

Hat niemand einen Tipp, wo mein Fehler liegen könnte?
Bzw. eine Erklärung, warum das Setup mit beliebigem anderen Port (z.B. Portforward 81->80) funktioniert, aber nicht direkt mit Port 80?

Dankbar für jeden Denkanstoß...

LG
JBO

Hallo!

Ich setze gerade eine neue PKI auf und veröffentliche die CRLs auf einem Webserver, der in einer Art DMZ steht.
Der Zugriff von beliebigen IPs aus dem Internet klappt einwandfrei. Nun sollen aber auch meine internen Hosts die CRL über die Public-IP erreichen, um unnötige Timeouts zu vermeiden.

Ich habe schon einige Artikel gelesen, aber a) kann ich momentan nicht auf Split DNS zurückgreifen und b) ist mein Setup und das Ergebnis einen Tick anders...

Die Public IP liegt nicht an der WAN-Schnittstelle der opnSense an, sondern an einer vorgelagerten Firewall. Auf diese habe ich keinen Zugriff, aber hier wird Port 80 erfolgreich auf meinen internen Webserver weitergeleitet.

Meine opnSense steht hinter dieser vorgelagerten Firewall, im selben Netz (WAN) wie der Webserver.
Meine eigentlichen internen Hosts stehen wiederun hinter der opnSense (LAN) und nutzen diese als Default Gateway.

Ich habe nun versucht, die Public IP (an der externen FW) zusätzlich als Virtual IP auf der opnSense anzulegen und dann den Port 80 für meine LAN-Clients per Port Forward so umzubiegen, daß der Traffic gar nicht erst zur externen FW geht, sondern direkt an den Webserver...

Wenn ich den Webserver von intern (LAN) aufrufe, lande ich auf der Anmeldemaske der opnSense, aus http ist https geworden und aus Port 80 der Custom-Port der opnSense-WebUI.

!?

Die VirtualIP ist auf dem LAN-Interface konfiguriert. Reflection ist global für alle 3 Varianten (PortForward, 1:1, Outbound) eingeschaltet. Beim Port Forwarding habe ich als Destination IP die Public IP/Virtual IP eingetragen und als Redirect IP die echte IP des Webservers (in WAN). Das Ganze mit der aktuellen Version 22.1.10.

Ich hab das Setup im angehängten Bildchen dargestellt.

Lustig: Wenn ich Destination Port auf 81 setze, können meine internen Hosts ohne Probleme über http://PublicIP:81 auf den Webserver in WAN zugreifen........

Was mache ich falsch, wieso drängelt sich die opnSense-WebGUI bei Port 80 dazwischen, bei Port 81 aber nicht?

LG
JBO