Probleme beim Zugriff auf Mails aus dem Intranet - Zertifikatsproblem?

[braun]

Liebe Community

Ich bin vor kurzem auf OPNsense umgestiegen. Mein Aufbau ist:
Internet - Modem - OPNsense auf MiniPC - Switch - Colputer, etc
Zuvor hatte ich eine FritzBox statt Modem und OPNsense.

Nun greife ich von aussen auf meine Mails zu, diese liegen auf einem NAS. Mit einer dyn. DNS klappt das wunderbar. Auch das Zertifikat von Let’s Encrypt dafür funktioniert. Leider klappt der Zugriff vom Netzwerk aus nicht auf die Mails.
Also von aussen klappt es und von innen nicht.

Schliesse ich wieder die FritzBox an klappt es auch von innen heraus.

Habe schon wieder Stunden damit zugebracht, aber komme einfach nicht weiter. Ich vermute mal, ich sehe gerade den Wald vor lauter Bäumen nicht.

Vielleicht kann von euch mir nun weiterhelfen oder mir einen Tipp geben.
Schon mal vielen Dank dafür!

[meyergru]

NAT Reflektion im Port Forward eingeschaltet? Es gibt ein systemweites Setting und pro Regel kann man es explizit wählen.

[braun]

Hallo meyergru

Danke für deine schnelle Antwort.

Ich habe nun alle möglichen Einstellungen bei der NAT Reflektion durchprobiert (systemweit und pro Regel). Leider bin ich da  icht weitergekommen. Als ich alle 3 Häkchen bei der NAT-Refletion unter Firewalll>Einstellungen>Ereweitert gestzt habe, konnte ich die Mails lesen, aber dafür ging sonst nichts mehr. Kein Zugriff aufs Internet und das Mai-Programm spuckte auch mehrere Meldungen aus wie:
"Mail kann die Identität des Servers „outlook.office365.com" nicht überprüfen. Das Zertifikat für diesen Server ist ungültig. Möglicherweise wirst du mit einem Server verbunden, der vorgibt, „outlook.office365.com" zu sein, und der deine vertraulichen Daten gefährdet." (Exchange-Server meiner Arbeit) Bei meiner Google-Mail-Adresse kam die gleiche Meldung.

Irgendwie komme ich gerade nicht weiter.

Zur Info:
Weiterleitungen werden die Ports 993 und 995 für IMAP sowi 80 und 443 für HTTP/S

[meyergru]

Dann gehe ich davon aus, dass Du den Port, den Du an Dein NAS durchleitest, noch anderweitig vergeben hast.
Da kommen in Frage: Zenarmor mit Inspektion von HTTPS, OpnSense-Weboberfläche auf Port 443, Transparenter Web-Proxy usw.

Das Problem ist, dass Du erreichen muss, dass der Zugriff auf den externen Namen aus Deinem Netz (der normalerweise auf Deine aktuelle WAN-IP verweist), wieder auf Dein NAS geht. Das geht einmal, indem die Portfreigabe refelktiert wird (dann nur für diesen Port). Leider kann es halt sein, dass andere Regeln den Port wegfangen.

Ich nutze kein Zenarmor, keinen transparenten Proxy und meine OpnSense läuft nicht auf Port 443. Alle Reflection-Flags sind an und ich nutze bei Outbound NAT nur manuelle Regeln.

Du kannst Das Problem auch anders lösen, indem Du in Deinem internen DNS einen Alias auf die externe Domain setzt, der auf die RFC1918-IP des NAS verweist.

[braun]

Hallo meyergru

Vielen Dank für deine ausführliche Antwort. Da mir jetzt der Kopf raucht und ich keinen Nerv mehr habe, werde ich morgen weitermachen. Ich vermute, dass es an der Weboberfläche der OPNsense liegt mit dem Port 443.

Wenn es geht (odr auch nicht) melde ich mich wieder.

[Patrick M. Hausen]

Weshalb heißt dein NAS outlook.office365.com?

[meyergru]

Der heißt nicht so, die NAT-Reflection leitet vermutlich jetzt nur alles, was per 443 rausgeht, auf sein NAS um. Und dann meckert natürlich die Zertifikatsprüfung.

[braun]

Ich habe nun wieder einige Zeit rumprobiert und es ist für mich ganz schön kompliziert - mir fehlt einfach einiges an Know-How - vor allem diese NAT-Reflection macht mich fertig.

Du kannst Das Problem auch anders lösen, indem Du in Deinem internen DNS einen Alias auf die externe Domain setzt, der auf die RFC1918-IP des NAS verweist.

Logischer für mich erscheint mir gerade der Weg über den DNS-Alias. Wenn ich das richtig verstehe, dann wird eine Anfrage aus dem LAN (die eigentlich ans LAN, besser gesagt ans NAS, soll) ans WAN gesendet und von da an wie eine normale Anfrage aus dem Internet behandelt und landet dann über diesen Weg im LAN bzw. am NAS.

Meine Frage ist nun, wo genau muss ich denn diese Einstellung / Regel machen?

[Monviech (Cedrik)]

Hier ist ein komplettes Tutorial wie man das richtig einstellt:

https://docs.opnsense.org/manual/how-tos/nat_reflection.html

[meyergru]

Das Hairpin/Reflection Tutorial geht auf jeden Fall - solange man nur ein LAN hat und das Ziel-System auch darin liegt, muss man allerdings nicht nur Reflektion, sondern immer auch Hairpinning konfigurieren. Nebenbei bemerkt ist natürlich die WAN-IP der OpnSense meist dynamisch, also würde man stattdessen "WAN Address" einstellen. Unabhängig davon muss man natürlich dafür sorgen, dass nicht zufällig der Port auf der OpnSense schon gebunden ist, z.B. 443 für das Web-GUI sollte nicht mit "Listen Interfaces" auf das WAN-Interface gebunden sein (oder an "alle").

Die DNS-Alias-Variante ist simpler, dabei wird einfach ein interner Override für den fraglichen DNS-Namen auf die interne IP gemacht. In Unbound also unter "Host Override". Somit werden die Anfragen im intenern Netz einfach sofort auf die interne IP geleitet.

[braun]

Die DNS-Alias-Variante ist simpler, dabei wird einfach ein interner Override für den fraglichen DNS-Namen auf die interne IP gemacht. In Unbound also unter "Host Override". Somit werden die Anfragen im intenern Netz einfach sofort auf die interne IP geleitet.

Genauso! Hat wunderbar geklappt und total einfach, wenn man wieder klar denken kann. Danke vielmal.

Ein Gedanke kam mir dann doch noch, den ich selbst zur Zeit nicht weiter verfolgen werde, aber evtl. macht das jemand anderer:
Es gibt ja die Möglichkeit bei der Portweiterleitung einen anderen internen Port anzugeben. (WAN z.B. 10443 -> 443 auf Server mit LAN-IP ...). Das muss man doch dann sicher auch irgendwo abbilden, wenn man einen DNS-Alias verwendet. Ist das richtig? Und wenn ja, wo?

[meyergru]

Das geht per DNS nicht. Und auch sonst ist das nicht ratsam.

Port-Weiterleitung ist m.E. tendenziell "old school". Ich habe dazu ja schon etwas hier geschrieben:

Bei IPv6 gibt es keine NAT, deshalb muss man da sowieso den selben Port bei "öffentlichen" und "privaten" IPv6 nehmen, weil das eben die selbe IP ist und somit auch keine Port-Translation stattfinden kann.

Früher hat man Port-Weiterleitung bei IPv4 meist gemacht, weil man extern ja den selben Port nicht mehrfach nutzen konnte. Das hat aber den Nachteil, dass man z.B. für zwei Server im internen Netz dann "https://x.dyn.org:444" und "https://x.dyn.org:4445" nehmen muss. Selbst wenn man x.dyn.org und z.B. y.dyn.org dafür nimmt, zeigen ja beide auf die selbe IPv4.



Die bessere, moderne Alternative ist HAproxy für HTTP und HTTPS, dabei lauscht die OpnSense auf IPv4 und IPv6 - es braucht keine Port-Weiterleitung oder Gezauber mit NAT-Reflektion und keine internen DNS-Tricks. Außerdem benötigt man nur einen Eintrag im Dyndns, der IPv4 und IPv6 mappt. Dazu einen Wildcard-DNS-Eintrag, der *.xyz.org auf den Dyndns-Eintrag richtet. Damit kann man beliebige DNS-Namen nutzen und muss gar keinen Port mehr angeben. Stattdessen wird dann http(s)://server1.xyz.org, http(s)://server2.xyz.org usw. verwendet. Weiterer Vorteil: Da der Traffic am HAproxy terminiert wird, muss der interne Server auch kein IPv6 können und man braucht dafür keine Firewall-Regeln. Die Verwaltung von Zertifikaten übernimmt die OpnSense per ACME.SH.

Für Nicht-HTTP(S) geht das auch, sogar mit TLS-Terminierung, z.B. für SMTP(S) oder IMAP(S), dann aber nicht namensbasiert. Deswegen würde ich dafür auch immer Nicht-Standard-Ports verwenden (wegen Portscans), zusätzlich ASN- oder GeoIP-Blocking, obwohl Port-Translation und Protokoll-Wandlung IPv6/IPv4 wegen der Terminierung im HA-Proxy natürlich möglich ist.

Voraussetzungen sind allerdings:

1. Ein Dyndns, der die IPv4 (und IPv6) auf den selben DNS-Namen (z.B. abc.dyn.org) abbilden kann.
2. Eine Wildcard (Sub-)Domain, die auf diesen Eintrag zeigt (z.B. *.abc.dyn.org oder *.xyz.org).
3. Im Idealfall eben die Möglichkeit, für die Wildcard-Domain auch Zertifikate zu bekommen (das geht nur per DNS-01 Validierung oder bei manchen Dyndns-Providern per API).

[Patrick M. Hausen]

Ergänzend zum letzen Beitrag von @meyegru:

HAproxy kann alles und Geschirr spülen, dafür ist das Plugin aber auch ziemlich komplex. Für die meisten Anwendungsfälle reicht dieses hier auf der Basis von Caddy - das macht die "Ver-SSL-ung" mit Letsencrypt dann auch gleich automatisch:

https://forum.opnsense.org/index.php?topic=36806.0

Gruß
Patrick

[braun]

Die DNS-Alias-Variante ist simpler, dabei wird einfach ein interner Override für den fraglichen DNS-Namen auf die interne IP gemacht. In Unbound also unter "Host Override". Somit werden die Anfragen im intenern Netz einfach sofort auf die interne IP geleitet.

Genauso! Hat wunderbar geklappt und total einfach, wenn man wieder klar denken kann. Danke vielmal.

Ein Problem ist mir aber nun doch aufgefallen und ich bin mir nicht sicher, ob das hierher gehört:
Die App Bitwarden auf dem iPhone findet die Internetverbindung zu meinem Server nicht, wenn ich im LAN bin. Erst aus dem WAN klappt es.
Es könnte aber auch ein Bitwarden-App-Problem sein, da ich via Browser vom iPhone auf die Weboberfläche komme. Auch vom MacBook aus kann ich via Bitwarden auf meinen Server zugreifen. Nur eben vom iPhone aus geht es nicht.
Zur Info: Damit ich vom LAN aus auf meinen Server zugreifen kann habe ich einen Host Override eingerichtet.

Schon mal herzlichen Dank an das Forum für eure Hilfe!