Verbindung vom LAN Interface zu WAN Interface

[Matzke]

Hallo,
ich weiß gar nicht so richtig, wie ich das Problem beschreiben soll. Wahrscheinlich finde ich auch deshalb nichts mit der Suche.

Ich habe ein Standard-Setup, mit ein paar offenen Ports auf der WAN-Seite mit Weiterleitung auf interne Server und einen DynDNS Service.

Fall 1: Ich bin außerhalb unseres Netzwerkes, z.B. per Handy oder im öffentlichen HotSpot im Hotel:
Wenn ich die öffentliche IP unseres Routers anspreche (1:1 Weiterleitung zur OPNSense), komme ich von extern wunderbar auf alle freigegebenen Ressourcen.

Fall 2: Ich probiere vom internen Netzwerk aus (LAN-Interface) die selbe URL wie in Fall 1 aufzurufen, erhalte ich jedes Mal ein Timeout. Bei den Firewallstates kann ich kein Problem erkennen.

Habe ich einen Denkfehler oder warum erhalte ich vom internen Netz keine Verbindung zur öffentlichen Seite der OPNSense.

Das einfachste Symptom ist, dass niemand seine Emails am Handy erhält, wenn er bei uns im internen WLAN eingebucht ist. Sobald er LTE aktiviert, läuft es problemlos.

Ich bin momentan ratlos.

[meschmesch]

Automatic outbound NAT for Reflection? Firewall-Settings-Advanced

[Matzke]

klappt leider nicht.

Ich habe aber Hybrid Outbound Rules, an der Automatik-Sektion kann ich keine Unterschiede feststellen, egal ob ich
Automatic outbound NAT for Reflection oder
Reflection for 1:1 oder
Reflection for port forwards

aktiviere oder deaktiviere. Die automatischen Regeln bleiben immer gleich.

[mace]

Wie ist die WAN Anbindung der OPNsense realisiert ?

[Matzke]

Es ist ein Dual-Wan Szenario. WAN2 ist ein Kabelmodem, WAN1 ist ein VDSL-Router, der intern eine private IP-Adresse hält.

Portfreigaben sind auf WAN1.

Momentan gehe ich per Firewallregel ausschließlich über WAN1 ins Internet, WAN2 ist Failover.

[mace]

Bei einigen Provider-Routern werden anfragen vom LAN auf die eigene Public IP blockiert
bzw. auf die intern umgeleitet z.B. kommt das bei einigen Digiboxen der Telekom vor

* das dann am besten über internen DNS lösen

[Matzke]

... das ist ja wild ... 

Werde ich die Tage mal mit meinem LAptop direkt am Telekom-Router ausprobieren. Auf so eine Idee bzgl. Sperre wäre ich nicht wirklich gekommen...
Ich melde mich.
Vielen Dank an alle

[Matzke]

Hallo,
ich habe es gerade getestet. Mein Laptop (parallel zum WAN-Interface der OPNSense) an den Telekom-Router angesteckt und es funktioniert.

Hier nochmal der Aufbau zur Verdeutlichung:

79.13.13.13 -- TelekomRouter --10.28.100.1----A----10.28.100.100 -- WAN-OPNSense -- LAN-OPNSense 10.1.1.1 -- B

Aufruf von https://79.13.13.13 von Stelle A funktioniert, von Stelle B kommt ein Timeout (Dual-Gateway habe ich oben in der Darstellung einfach weggelassen, da unerheblich).

Gibt es noch Ideen, ich weiß einfach nicht, wo ich noch suchen soll.

Wie gesagt, von extern funktioniert auch alles perfekt.
(Telekom-Router macht NAT HTTPS auf 10.28.100.100, OPNSense macht NAT HTTPS auf 10.1.1.5 - Ports jeweils unverändert)

[Matzke]

... nach vielem Probieren habe ich es scheinbar hinbekommen ...

Ich habe 2 Änderungen vorgenommen:

1) DNS-Auflösung des DYNDNS-Hostnamens intern nicht auf öffentliche IP des Telekomrouters auflösen lassen sondern auf WAN-IP der OPNSense

2) Bei den NAT Regeln bei Interface sowohl WAN-Interface (so war es standardmäßig) als auch LAN-Interface hinzugefügt.

Nun scheint es zu funktionieren - ob das aber eine saubere Konfiguration ist, weiß ich nicht. Die Doku gibt hierzu auch nicht viel her.

[osmom]

Hallo Matzke,

wenn du intern einen eigenen DNS betreibst,  warum schickst du die Datenpakete dann 2* über die FW? Du könntest deinen Dienst gleich im Netz von Stelle B ansprechen.

[mace]

Aufruf von https://79.13.13.13 von Stelle A funktioniert, von Stelle B kommt ein Timeout (Dual-Gateway habe ich oben in der Darstellung einfach weggelassen, da unerheblich).

* ok, bei dem oben erwähnten Verhalten sollte das von Stelle A auch nicht funktionieren
  von Stelle B doppeltes NAT der Telekom Router sieht halt ausgehende Verbindung von
  10.28.100.100 die er dann aber auf die gleiche IP eingehend weiterleiten soll

1) DNS-Auflösung des DYNDNS-Hostnamens intern nicht auf öffentliche IP des Telekomrouters auflösen lassen sondern auf WAN-IP der OPNsense

dyndns auf die WAN IP bzw. wenn die Portweiterleitungen nicht auf unterschiedliche Hosts gehen besser gleich auf die IP vom Host

2) Bei den NAT Regeln bei Interface sowohl WAN-Interface (so war es standardmäßig) als auch LAN-Interface hinzugefügt.

Automatic outbound NAT rule generation sollte reichen

Nun scheint es zu funktionieren - ob das aber eine saubere Konfiguration ist, weiß ich nicht. Die Doku gibt hierzu auch nicht viel her.

Optimal ist doppeltes NAT nicht besser wäre ein vernünftiges Routing oder WAN-Anbindung über Modem .. wenn das mit dem Telekom Router machbar ist

[Matzke]

* ok, bei dem oben erwähnten Verhalten sollte das von Stelle A auch nicht funktionieren
  von Stelle B doppeltes NAT der Telekom Router sieht halt ausgehende Verbindung von
  10.28.100.100 die er dann aber auf die gleiche IP eingehend weiterleiten soll

Ich weiß, dass doppeltes NAT sehr ungünstig ist - an dieser Stelle geht es aber leider nicht anders. Von Stelle A funktioniert es aber ganz probemlos, ich denke nicht, dass der Speedport das Problem ist. Ich habe im Bild nun auch einmal das zweite WAN-Interface eingezeichnet. Dort gibt es ausschließlich ein Modem und kein doppeltes NAT. Die OPNSense verhält sich aber genau gleich - ein Aufruf von https://10.4.4.4 funktioniert nicht vom LAN-Segment, sondern ausschließlich vom WAN-Segment aus (bitte nicht daran stören, dass es eine 10.4.4.4 Adresse ist - es gibt noch vorgelagerte Technik des Kabelanbieters, auf die ich keinen Einfluss habe. Das Prinzip ist jedoch das selbe (ich kann mich von einem Bekannten, der ebenfalls ein Kabelmodem hat (IP 10.4.4.200) problemlos auf https://10.4.4.4:443 verbinden.

dyndns auf die WAN IP bzw. wenn die Portweiterleitungen nicht auf unterschiedliche Hosts gehen besser gleich auf die IP vom Host

IP direkt auf den internen Host zeigen zu lassen geht nicht, da ich mehrere Hosts von verschiedenen Ports anspreche - wie bereits von Euch vermutet.

Automatic outbound NAT rule generation sollte reichen

Nein, genügt leider definitiv nicht. Ich muss meine Änderung (siehe oben) durchführen, dass es funktioniert. Ich bin mir nur unsicher, ob das so richtig ist - funktionieren tut es jedenfalls (gleiches Prinzip auch auf dem Kabelmodem, dort ohne Doppelnat).

Optimal ist doppeltes NAT nicht besser wäre ein vernünftiges Routing oder WAN-Anbindung über Modem .. wenn das mit dem Telekom Router machbar ist

siehe oben - leider technisch nicht möglich, aber da WAN2 kein doppeltes NAT hat, ist es auch unerheblich, da das Problem nicht daher rührt (bzw. doppeltes NAT ist dann irgendwo beim Kabelprovider - auf dem Segment Modem meines Bekannten zu mir findet aber gar kein NAT statt, da es das selbe 10.4.0.0/255.255.0.0 Segment ist)

Ich würde mich freuen, wenn andere ein solches Verhalten einmal prüfen könnten bzw. mir bestätigen, dass ich es so richtig oder falsch konfiguriert habe.

Dankeschön und allen einen schönen 3. Advent.