[GELÖST] Portforwarding für interne Hosts auf Public IP des DMZ-Servers

[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

[jbo]

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

[Patrick M. Hausen]

Es gibt diese automatische Anti-Lockout Regel, mach die mal aus. Nachdem du sichergestellt hast, dass du von intern eine allow Regel hast, mit der du an die UI kommst.

Diese Anti-Lockout Regel macht komische Dinge mit Port Forwarding, die Chance ist groß, dass es daran liegt. Ich hab die überall aus.

Firewall > Settings > Advanced >  Disable anti-lockout

[malaclypse]

Ich denke fuer diesen Fall waere eine DST-NAT Regel geeignet, also einfach anfragen an die PublicIP port 80 an die interne IP des Webservers masken.

[jbo]

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...

[Patrick M. Hausen]

@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...

Testest du von innen oder definitiv von außen?

[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...

[JeGr]

Hi,

nachdem ich gerade nur kurz das Bild angeschaut habe:

Du versuchst vom Client mit der xxx.5 den Webserver darüber zu erreichen aber über seine Domain? Seine externe IP?
Wenn über die Domain: Warum die Domain nicht schlicht im DNS umschreiben auf die interne IP in der DMZ Zone?

Wenn es über die IP sein soll: ich verstehe nicht ganz, warum du die externe IP auf der internen Firewall noch zusätzlich mit aufs Interface als Alias geklebt hast? Die interne Firewall soll doch überhaupt nichts mit der IP anstellen?

Entweder brauchst du dafür schlichtweg eine Port Forwarding Regel auf dem WAN Interface der internen Sense oder eben ein DNS Rewrite, das wären die einfachsten Möglichkeiten dafür?

Bitte korrigiere mich gern, wenn ich was übersehen habe, aber das war gerade zu viel nachzulesen und das Bild mit der IP (1.2.3.4) innen zugewiesen hat mich direkt angesprungen als "hö? warum?"

Cheers

[jbo]

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

[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...   ;-)

[JeGr]

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

Kannst du die IP einfach mal komplett entfernen?

Denn eigentlich solltest du die VIP gar nicht brauchen. Extern vielleicht wenn die IP nicht auf das WAN geroutet wird - was aber wohl der Fall ist sonst bräuchtest du die VIP extern - aber intern ist sie eigentlich unnötig, denn die Sense muss selbst mit der IP gar nichts machen können, was eine Bindung an ein Interface erforderlich machen würde
Erst wenn die Sense selbst die IP nutzen soll - ODER wenn sie sonst gar nicht bei der Sense ankommt (von extern/WAN wenn nicht geroutet sondern nur aufgelegt als zusätzliche IP) - musst du die IP binden. Andernfalls kommen die Pakete ja so oder so an der Sense "vorbei" und du kannst sie einfach umschreiben (PFW Regel) bzw. redirecten

Cheers
\jens

[jbo]

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

[JeGr]

> In der Rückschau: 5 Klicks und fertig. Stattdessen so ein Aufriss hier. Aber wieder was gelernt...

Kommt vor, kein Problem Ich hab das oft gesehen auch in den Workshops oder in Fragerunden kommt das immer wieder hoch, weil es vielfach einfach nicht klar ist, wie durch Routing die Pakete geschoben werden. Allerdings ist es von intern ja relativ einfach -> ans default GW und das ist ja im ersten Step schon die Sense und daher braucht die die VIP nicht weil die Pakete eh alle bei ihr vorbeitrödeln

Andersrum von extern ist eben vielfach ebenfalls nicht klar, was der unterschied zwischen aufgelegten und gerouteten IPs ist.

Aufgelegt: Provider/ISP hat selbst nen Gateway im Netz und weist dir eine/mehrere einzelne IPs zu -> die muss man aber auf seinem Gerät "auflegen" also konfigurieren, denn sonst kommen die am Gerät nicht an.
Post Analogie: Die Firewall ist quasi eine Person die mit anderen in einem großen Abfertigungszentrum wartet bis der "Router" des Providers sagt: "Ich hab hier was für Schmidt! Und das hier für Müller!" damit man die Hand heben kann und das Paket bekommt.

Geroutet: Meist hat man da schon eine statische IP oder ein Transfernetz mit einem Provider was aufgelegt wurde (/30er oder /29er für nen Cluster bspw.) und bekommt dann noch ein Netz mit /xy Adressen dazu. Mit Glück bekommt man die aber geroutet. Andere Post Analgie dafür: Firewall hebt im Zentrallager für alles die Hand, was die Transfernetz-IP(s) betrifft, denn die sind aufgelegt. Der Router hat aber gesagt bekommen: alles was an <neuesNetz>/xy geht gibst du automatisch dem Fahrer für die Transfernetz IPs mit. Die Pakete für das geroutete Netz werden also automatisch schon aufs Netz an die vorhandene IP der Sense geschickt und kommen somit an egal ob sie die Hand dafür hebt oder nicht. Quasi ne Art automatischer Nachsendeauftrag

Solche gerouteten IPs muss man nicht ans Interface binden, wenn man nichts über einen Service auf der Sense damit machen möchte (bspw. IPsec Tunnel - dafür müsste man die IP binden). Für alles was simple PF Aktionen des Filters sind, ist kein IP binding notwendig, das wird einfach quasi advanced geroutet und ich kann die Pakete hinbiegen wo ich möchte

Das war jetzt nicht so sehr dein spezielle Fall aber wenns jemand nachliest, ist das vielleicht ein wenig Augenöffnend was was ist