Messages

Deshalb wird i.d.R. in Firmennetzen ein Split-DNS verwendet oder eine andere Lösung gesucht (multihomed Server usw.).

Da stimme ich Dir voll und ganz zu. Wenn es sich bei mir nicht um einen privaten Anwendungsfall handeln würde, wäre mir reines routing auch lieber. Aber die reine routing Geschichte habe ich irgendwie nicht hinbekommen. Und für zu Hause nur wegen OwnCloud ein Split-DNS aufzubauen erschien mir etwas zu viel des guten (obwohl es meinem IT-Ruf entsprechen würde: Mit Kanonen auf Spatzen zu schiessen  ;D )

Aber die NAT Geschichte funktioniert und meine Familie ist Glücklich endlich von überall mal schnell an Daten zu kommen. (Ist doch schon komisch, wenn die Familie mal einen Nutzen aus meinen "Spinnereien" ziehen konnte ist es auf einmal toll)

Kleines Update

Es geht jetzt, aber ich verstehe noch nicht warum. :(

Ich habe einzig zwei Änderungen in System => Firewall/NAT gemacht (siehe Screenshot):
1. Reflection for port forwards: von Disable auf Enable (Pure NAT) umgestellt
2. Enable automatic outbound NAT for Reflection: Checkbox angehakt

und voila, ich kann jetzt meinen OwnCloud Server unter dem selben FQDN sowohl von extern, wie auch intern erreichen.

Vielleicht kann mir jemand noch die Auswirkung dieser Optionen erklären?

Ok. Soweit so gut.

Aber wie bekomme ich den "DNS Resolver" dazu, bei Anfragen von Clients die unter "Overrides" eingetragene interne IP zurückzugeben und nicht die, die meinem Provider für den A-Eintrag eingetragen ist?

Wobei ich es komisch finde. Mache ich ein ping auf den FQDN meines OwnCloud Servers, dann geht der ping auf die WAN Adresse (Provider Eintrag), mache ich aber ein nslookup/dig bekomme ich vom DNS Server die richtige interne Adresse geliefert. Versteht das einer und kann mir das erklären?

Hallo,

ich habe gerade folgende Situation:
Ich betreibe einen OwnCloud Server im internen LAN (192.168.1.100) mit einem statischen DNS Eintrag owncloud.intern.lan in der OPNsense. Soweit so gut. Bei meinem Provider habe ich ebenfalls einen Hosteintrag erstellt owncloud.domain.tld mit meiner externen IP. Auf der OPNsense ist ein Portforwarding "WAN address" "https" auf die 192.168.1.100 eingerichtet. Auch das funktioniert, allerdings nur von ausserhalb meines internes LANs.

Jetzt zu meinem Problem:
Wie schaffe ich es, dass ich auch vom internen LAN meinen OwnCloud Server über owncloud.domain.tld erreichen kann?

Wenn ich aus dem internen LAN versuche owncloud.domain.tld aufzurufen, dann löst mein Client zwar den DNS Namen mit meiner externen IP Adresse auf, aber es findet ja kein forwarding der Pakete statt, da die ja von der LAN Schnittstelle kommen. Ein generelles https forwarding an der LAN Schnittstelle will ich aber auch nicht, sondern nur für https://owncloud.domain.tld. Bin mir nicht mal sicher ob das überhaupt funktionieren würde.

Habe es auch schon versucht im DNS einen alias einzurichten, aber durch das cachen der Clients dauert das ewig, bis die das mitbekommen würden. Hat jedenfalls nicht geklappt.

Hat noch jemand eine Idee?

Grüße
Ralf

Da weiß ich zu wenig über IPsec um qualifizierte Auskunft zu geben. Ad kennt sich da weitaus besser aus, ich frag ihn morgen dazu. Einen kleinen Bug im Konfigurations-/Firewallcode lässt sich nicht ausschließen. Danke schon mal  für die Analyse des Problems. :)

Konntest Du von Ad schon etwas zu meinem Problem in Erfahrung bringen?

Aber wozu hast Du denn die Bridge gemacht? Mit einer Bridge verbindest Du schliesslich 2 Teilnetze zu einem Netz zusammen, wobei die Bridge selber lernt welche Ziel-MAC Adressen in welchem Netz sind, und dem entsprechend die Pakete weiterleitet.

Ist denn eines der beiden GW's ein 'default' Gateway für das 10.100er Netz, wo bis auf Ausnahmen, alles drüber geschickt werden kann? Mir scheint es eher Du brauchst einen Router und keine Brigade, also die Entscheidung eine Ebene höher.

Meine Vorstellung einer Lösung sähe so aus:
1. Regel auf dem LAN Interface alles was ins 10.100er Netz an Port 12345 geht über Gateway 193
2. Regel auf dem LAN Interface alles was ins 10.100er Netz will über Gateway 192

Aufgrund der Reihenfolge der Regeln wird kein Traffic zum Port 12345 über das Gateway 192 gehen.

Gruß
Ralf

Hi,

ausprobiert noch nicht, da ich in erster Linie nach einer reinen IPSec Verbindung gesucht habe.

Aber ich bin immer noch davon überzeugt, das die Antwort Pakete innerhalb der Firewall "verloren" gehen. Der Tunnel an sich steht ja, aber von Seiten der Firewall scheint nichts in den Tunnel hinzugelangen. Und das Verhalten ist vom Gerät am Ende des Tunnels unabhängig.

Gruß
Ralf

Okay, ich verstehe, aber mit Kriterien wie Video oder File wirst Du es wohl nicht schaffen. Wenn Du eine definierte Ziel-Adresse und/oder Port hast, kannst Du das mit entsprechenden Regeln auf dem LAN Interface erreichen, wo Du das Gateway definierst. Dann würden z.B. Pakete zur Adresse 10.100.50.50 und Port 12345 ans Gateway 192 geleitet und Pakete an die selbe Adresse aber Port 54321 ans Gateway 193. (Siehe Screenshot)

Kommt das Deiner Vorstellung schon näher?

Also lässt GW1 nur Port 80 durch und GW2 nur Port 443, oder wie meinst du das mit den verschiedenen Firewall Ports?


Gesendet von iPhone mit Tapatalk

Hi,

meinst Du hinter jedem Deiner GW's hängt ein identisches 10er Netz? Wie soll man dann Entscheiden können in welches der beiden 10er Netze das jeweilige Paket gerostet werden muss? Oder ist es nur EIN 10er Netz, das über beide GW's erreicht wird? Dann sollte es doch egal sein über welches der beiden GW's du die Pakete schickst.

Ralf

Hat den keiner mehr eine Idee? [emoji22]


Gesendet von iPhone mit Tapatalk

Tja, so ist das halt mit einer richtigen Firewall. Da ist alles etwas komplexer wie bei einer FritzBox, die schliesslich für "normale" Endkunden gedacht ist.  ;)

Aber freut mich, das ich helfen konnte.

Viel Spass noch.

Hallo Maik,

wenn ich alles bisher richtig verstanden haben, dann müsste Du am besten einen Alias für den Tomcat Port 8080 anlegen (siehe Screenshot), und danach eine Port forwarding Regel, wo Du als Destination Deine Public IP (WAN Adresse?) und als Port den angelegten Alias angibst und als Redirect die IP vom Tomcat und wieder den Port Alias. Den Rest kannst Du in den default Einstellungen lassen (siehe Screenshots).

Damit sollte es gehen.

Gruß
Ralf

Hallo Maik,

die Block private Networks Option solltest Du drin lassen, da dies nicht mit dem Port forwarding zu tun.
Ich habe bei mir ein Port forwarding für FTP eingerichtet (siehe Bilder). Mehr ist nicht von Nöten.

Vielleicht kannst Du ja mal Deine Forwarding Regel posten, dann sieht man vielleicht das Problem bei Dir?!

Gruß
Ralf

Ja das mag sein, aber es erklärt nicht, warum die Antwort Pakete zwar am LAN-Interface ankommen, aber nicht am IPSec-Interface wieder rauskommen. Das hat -meiner Meinung nach- noch nichts mit dem Endgerät zu tun.