OPNsense Forum
International Forums => German - Deutsch => Topic started by: werom-IT on May 01, 2023, 07:33:53 pm
-
Hi!
Bin da eher ratlos und schleife das Thema schon etwas länger mit mir mit:
Wird von extern auf die WAN-IP mittels Port 443 geschaut, kommt man auf den korrekten Port-Forward nach intern (Mailserver).
Ist man im LAN-Net und geht auf die WAN-IP Port 443 kommt man nicht zum Mailserver. OpnSense-Administration ist auf einem anderen Port als 443 und Weiterleitung funktioniert dennoch nicht.
Habe schon versucht zusätzlich eine NAT-Weiterleitung von Lan nach Port443 zu machen zum Mailserver, aber das bleibt erfolglos.
Was muss ich tun oder einstellen, damit man vom internen Netzwerk, wenn man auf die WAN-IP geht (mit der man nach außen geht), dass man auf die Nat-Weiterleitung nach intern kommt?
Nat-Reflection ist es auch nicht, also ich komm nicht dahinter. Möglich sollte es ja sein, weil von Intern zur WAN-IP komm ich zum Admin-Interface und Pingen geht auch. Die OpnSense mag mich nur nicht von intern auf die WAN-IP nach intern weiterleiten.
Vielleicht weiß jemand wie man mein Problem lösen kann.
Danke und liebe Grüße
-
Also mit einer solchen LAN-NAT Rule macht es den Trick, nur einen Verbindungsaufbau krig ich weiterhin nicht.
Am (Windows) Mailserver ist die Firewall deaktiviert und es kommt keine Antwort.
Im Firewall-Log sehe ich 2 Einträge:
lan 2023-05-01T19:51:39 10.15.1.11:58569 10.15.1.13:443 tcp let out anything from firewall host itself
lan 2023-05-01T19:51:39 10.15.1.11:58569 WAN-IP:443 tcp rdr rule
Nur Antwort gibts keine, keine Rückmeldung. Jetzt ist mir nicht ganz klar, ist das noch ein Opnsense-Thema oder Mailserver-Thema? Ich würde fast sagen Mailserver-Thema, nur der hat die Firewall deaktiviert UND im IIS werden alle Anfragen aller Adressen auf Port 443 verarbeitet. Also keine Einschränkung.
Kann es eher sein, dass die Weiterleitung korrekt ist, nur die Antwort darf irgendwie nicht retourniert werden über die Firewall bzw. die Firewall gibts noch nicht zurück zum internen Anfragesteller?
Vielleicht hat sich damit mal jemand befasst. Intern isses ein MS Exchange Server
-
Hab mal das Firewall-Logging am Mailserver eingeschaltet seitens Microsoft.
Auch da gibts keine Zurückweisung oder DROP Anweisung:
01.5.2023 20:16:26 ALLOW TCP 10.15.1.11 10.15.1.13 59366 443 0 - 0 0 0 - - - RECEIVE
Somit wieder zurück zur Firewall, nur da sehe ich nichts, dass es das nicht zulässt oder wieder weiterleitet.
Habe dasselbe auch von einem anderen Client probiert um den einen Client auszuschließen. Selbes Verhalten, alles wird erlaubt aber der Client krigt keine Verbindung.
Irgendwo hab ich doch irgendein kleines Hackerl vergessen zu setzen, hundert pro. Nur wo ist das Hackerl zu setzen, damit es funktioniert?
-
OK, ganz check ichs nicht, aber hier steht die Lösung. Sogar schon mal von mir ;D ;D ;D ;D
https://forum.opnsense.org/index.php?topic=20250.msg93990#msg93990
(https://forum.opnsense.org/index.php?topic=20250.msg93990#msg93990)
(https://i.ibb.co/ns4nTTy/image.png)
Mach ich damit noch irgendwas kaputt eigentlich? Oder gehts da wirklich nur um Anfragen zur WAN-IP intern werden jetzt wie Anfragen wie intern/extern zur WAN-IP behandelt?
Dann dürfte das Thema als SOLVED markiert werden können ;D
-
Also scheinbar ist eben eine NAT-Reflection nötig. Die kann bei der NAT-Rule auch eingestellt werden weiter unten in den Einstellungen. Dort steht DEFAULT und default ist eben nicht eingeschaltet, außer das Hackerl ist in den Advanced-Settings gesetzt.
Das Hackerl kann also auch in der NAT-Rule gesetzt werden.
Das was wirklich gefehlt hat, war die Outbound-NAT-Rule und die kann scheinbar mittels dem 3. Hackerl in den Advancved-Settings gesetzt werden wenn mans nicht selbst setzen kann weil mans nicht weiß oder nicht richtig setzt.
Somit: bei mir ist mal nur das dritte Hackerl für Automatic outbound NAT for Reflection gesetzt, die oberen zwei Einstellungen sind nicht aktiviert. Das wird dann pro NAT-Rule aktiviert.
Lg und Ende von mir