Problem mit NAT für Webserver

Started by joelue, September 21, 2020, 03:01:10 PM

Previous topic - Next topic
Hallo,
ich habe OPNsense auf einem Hetzner Root-Server innerhalb einer Proxmox-Installation laufen. Vom Host werden alle Requests auf die OPNsense-VM genattet (außer der Proxmox WebUI).

Netzwerkaufbau:
Public IP wird auf den Proxmox Host geroutet, dort sind zwei Netzwerkbrücken eingerichtet:
- vmbr1 10.0.0.0 --> in OPNsense als WAN (10.0.0.2)
- vmbr2 192.168.1.0 --> in OPNsense als LAN. OPNsense vergibt per DHCP IPs an weitere VM.

OPNsense und dahinter liegende VM haben Internetzugriff. Port-Forwarding via NAT innerhalb der OPNsense funktioniert für RDP auf eine Windows-VM wunderbar.

Ich scheitere allerdings daran, einen Webserver ins Internet weiterzuleiten. Ports 80 und 443 sollten eigentlich via NAT an die VM weitergeleitet werden, hier meine NAT-Tabelle:











InterfaceProtoSource AddressSource PortsDestination AddressDestination PortsNAT IPNAT PortsDescription
LANTCP**LAN address80, 443**Anti-Lockout Rule
WAN TCP***80 (HTTP) 192.168.1.104 80 (HTTP) HTTP
WAN TCP ***443 (HTTPS) 192.168.1.104 443 (HTTPS) HTTP
WAN TCP/UDP ***3389 (MS RDP) 192.168.1.100 3389 (MS RDP) Windows RDP

Dabei macht mich die Anti-Lockout-Rule stutzig, die auch auf den Ports 80 und 443 reagiert - aber doch eigentlich nur auf der LAN-Adresse der OPnsense (192.168.1.1). Ich habe Schiss, das WebUI gar nicht mehr erreichen zu können, wenn ich die Regel deaktiviere... Bei Aufruf im Browser sowohl über die public IP als auch über die Domain wird aber weder das WebUI noch der gewünschte Webserver geladen. Was mache ich falsch? :(

Wenn du 80/443 weiterleiten willst, würde ich sicherheitshalber die Sense auf einen anderen Port legen. 4443, 8443, was dir passt. Und das Redirecting ausschalten, dass sie wirklich nur auf den Port hört und andere nicht darauf umgeleitet werden.

Dann sollte man deine Redirects auch besser greifen und debuggen können :) ohne dass du dir dabei den Ast absägst ;)
"It doesn't work!" is no valid error description! - Don't forget to [applaud] those offering time & brainpower to help you!
Better have some *sense as no(n)sense! ;)

If you're interested in german-speaking business support, feel free to reach out via PM.

Danke dir!
Ich habe das WebUI auf Port 8443 geändert und den Redirect von Port 80 rausgenommen. "Lokal" (innerhalb des VM-Netztes) komme ich immer noch auf die Sense, das hat schon einmal geklappt :)

Wenn ich jetzt eine Verbindung zum Webserver herstellen möchte, wird die eingehende Verbindung über den WAN-Port erlaubt (HTTP-Regel), ebenso die Antwort über den LAN-Port (let out anything from firewall host itself). Der Browser versucht wohl, auf die lokale IP 192.168.1.104 zu connecten, was natürlich nicht funktioniert - und gibt dann einen Timeout-Fehler aus.

Im Apache-Log auf der VM wird der Aufruf auch mit meiner externen IP gelistet.

> Wenn ich jetzt eine Verbindung zum Webserver herstellen möchte, wird die eingehende Verbindung über den WAN-Port erlaubt (HTTP-Regel), ebenso die Antwort über den LAN-Port (let out anything from firewall host itself). Der Browser versucht wohl, auf die lokale IP 192.168.1.104 zu connecten, was natürlich nicht funktioniert - und gibt dann einen Timeout-Fehler aus

Wenn du von wo die Verbindung herstellen möchtest? Vom WAN? Vom Internet?

Wenn du eine Antwort siehst, dann hat der Server doch die Verbindung bekommen oder nicht? Ich würde da auf dem Server selbst mal nen tcpdump laufen lassen, ob die Pakete durch die Firewall bei ihm ankommen und wieder rausgehen. Dann suchst du nämlich ggf. an der falschen Stelle und es liegt eher an der Virtualisierung oder an deinem Netzkonstrukt aber nicht an der Firewall per se :)
"It doesn't work!" is no valid error description! - Don't forget to [applaud] those offering time & brainpower to help you!
Better have some *sense as no(n)sense! ;)

If you're interested in german-speaking business support, feel free to reach out via PM.

Verbindungsversuch übers Internet wird umgeleitet. Innerhalb des VM-Netzes funktioniert der Zugriff.

"Ich würde da auf dem Server selbst mal nen tcpdump laufen lassen" - also auf dem Host? Oder auf dem virtualisierten Webserver?

> Verbindungsversuch übers Internet wird umgeleitet. Innerhalb des VM-Netzes funktioniert der Zugriff.

Was heißt umgeleitet? Bitte einfach mal mehr als eine Zeile Text. Gib mir doch Details mit denen man helfen kann ;)
Was passiert konkret wenn du vom Internet drauf zugreifst. Was taucht im Browser auf oder nicht, was sieht man etc. etc.
Was sieht man bspw. mit tcpdump auf der Sense?
Was auf dem Server selbst - also dem Webserver?

Wenn die NAT Regel korrekt ist und es eine Firewall Regel gibt, die das modifizierte Paket dann rein lässt aufm WAN, dann sollte das der TCPDump auf der Sense zeigen, dass

a) auf WAN das Paket ankommt
b) auf dem XY Interface es in Richtung Server rausgeht.

Das kann man ja leicht über die Diagnose Funktion der Sense checken :)
"It doesn't work!" is no valid error description! - Don't forget to [applaud] those offering time & brainpower to help you!
Better have some *sense as no(n)sense! ;)

If you're interested in german-speaking business support, feel free to reach out via PM.

Entschuldige, ich versuche mich eigentlich möglichst kurz zu fassen ;)

Nach Eingabe der DNS-Adresse oder IP in die Adresszeile des Browsers sprang die Adresse auf die lokale VM-IP und der Browser gab eine Timeout-Fehlermeldung aus. Habe sowohl die Sense als auch den Apache-Container jetzt mal komplett neu aufgesetzt, WebUI-Port geändert, Redirect von Port 80 ausgeschaltet und die NAT-Regeln neu eingetragen, jetzt funktioniert es. War wohl irgendwo was verkehrt konfiguriert.

> War wohl irgendwo was verkehrt konfiguriert.

Ah, dann hat wahrscheinlich die VM intern irgendwie ihre IP als Redirect angegeben, das klappt dann von außen natürlich nicht.
"It doesn't work!" is no valid error description! - Don't forget to [applaud] those offering time & brainpower to help you!
Better have some *sense as no(n)sense! ;)

If you're interested in german-speaking business support, feel free to reach out via PM.