13
Problem bei Netzwerkverbindung mit Remote Standort
Moin moin,
Ich hänge seit Tagen an einem (einfachen) Problem und weiß einfach nicht mehr weiter. Vielleicht kann mir ja hier der eine andere weiterhelfen.
Zur Übersicht:
Was ich versuche einzurichten ist eine automatische, tägliche Sicherung meiner Daten des Synology NAS von Standort A auf Synology NAS des Standorts B mit der Synology eigenen App 'Synology Hyper Backup'.
Standort A und B sind über ein IPSec-VPN verbunden. Standort B initiiert hierbei die Verbindung (Standort A mit statischer öffentlicher IP Adresse, Standort B DS-Lite).
Zyxel am Standort B Firewall erlaubt sämtlichen Datenverkehr von Lan Interface zu IPsec und umgekehrt. Lancom Firewall wiederum erlaubt sämtlichen Datenverkehr von Subnet 192.168.0.0/24 zu 192.168.10.0/24 und umgekehrt. Pfsense erlaubt ebenfalls alles von 192.168.0.0/24 zu 192.168.10/24. Snort ist auf der Pfsense installiert, läuft aber nur im 'Alert' Modus, mit Snort Subscriber 'Balanced' Regelwerk.
In Pfsense sind mehrere Interfaces angelegt, 'LAN', 'VPN', 'WAN'. Lan Interface -> 192.168.0.0/24, VPN Interface 192.168.1.0/24 und hierbei verbunden mit dem Lancom Router.
Die VPN Verbindung steht und funktioniert soweit auch. Seit längerem verbinden sich hier schon mehrere Clients vom Standort B mit einem TS, welcher sich im selben Netzwerk befindet wie das NAS des Standorts A (192.168.0.0/24).
Im Zyxel sind die Subnetze 192.168.0.0/24 192.168.1.0/24 bei der IPSec Regelwerke hinterlegt.
Im Lancom und in der Pfsense sind statische Routen angelegt für jeweiligen anderen Subnetze.
Zunächst habe ich beide NAS im selben Netzwerk angeschlossen -> Verbindung und Einrichtung des Backup Jobs funktioniert ohne Probleme. Das Synology Backup funktioniert dabei im 'Push' Verfahren: Das NAS, welche die zu sichernden Dateien besitzt, baut eine Verbindung zum remote NAS auf. In diesem Fall also NAS des Standorts A zum NAS des Standorts B.
Anschließend habe ich die NAS an getrennten Standorten aufgebaut und die Verbindung funktioniert nicht mehr.
Sobald ich den Backup Job einrichte, baut das NAS am Standort A eine Verbindung zum Standort B auf. Am Ziel Router Zyxel kann ich dabei einen erfolgreichen Verbindungsaufbau in der Log sehen (ACCESS FORWARD 6281 192.168.0.129 -> 192.168.10.19).
NAS 'lokal' scheint dabei auf das NAS 'remote' zugreifen zu können, die Einrichtung des Backup Jobs schlägt aber fehl (ich gebe Benutzername u. Passwort an, anschließend kann ich mir aber nicht die freigegebenen Ordner anzeigen lassen.
Das Verrückte: vom NAS 'remote' kann ich jedoch erfolgreich einen Backup Job auf dem NAS'lokal' einrichten.
Die Verbindung NAS Standort B -> NAS Standort A funktioniert, die benötigte Verbindung NAS Standort A -> NAS Standort B hingegen nicht.
Ich wollte ausschließen, dass es sich hierbei um einen Konfigurationsfehler der NAS selbst handelt, also habe ich die beiden NAS Geräte getauscht und die dazugehörigen IP Adressen ausgetauscht und es ist immer noch das selbe Muster: NAS Verbindung Standort B -> Standort A klappt; Standort A -> B hingegen nicht.
Ping und Tracert von der NAS des Standorts A zur NAS des Standorts B funktioniert, genauso wie von NAS Standort B zu NAS Standort A
Ich hänge hier schon seit Tagen daran und komme einfach nicht weiter.... irgendeine Idee?
Danke
Traceroute:
Ich hänge seit Tagen an einem (einfachen) Problem und weiß einfach nicht mehr weiter. Vielleicht kann mir ja hier der eine andere weiterhelfen.
Zur Übersicht:
Was ich versuche einzurichten ist eine automatische, tägliche Sicherung meiner Daten des Synology NAS von Standort A auf Synology NAS des Standorts B mit der Synology eigenen App 'Synology Hyper Backup'.
Standort A und B sind über ein IPSec-VPN verbunden. Standort B initiiert hierbei die Verbindung (Standort A mit statischer öffentlicher IP Adresse, Standort B DS-Lite).
Zyxel am Standort B Firewall erlaubt sämtlichen Datenverkehr von Lan Interface zu IPsec und umgekehrt. Lancom Firewall wiederum erlaubt sämtlichen Datenverkehr von Subnet 192.168.0.0/24 zu 192.168.10.0/24 und umgekehrt. Pfsense erlaubt ebenfalls alles von 192.168.0.0/24 zu 192.168.10/24. Snort ist auf der Pfsense installiert, läuft aber nur im 'Alert' Modus, mit Snort Subscriber 'Balanced' Regelwerk.
In Pfsense sind mehrere Interfaces angelegt, 'LAN', 'VPN', 'WAN'. Lan Interface -> 192.168.0.0/24, VPN Interface 192.168.1.0/24 und hierbei verbunden mit dem Lancom Router.
Die VPN Verbindung steht und funktioniert soweit auch. Seit längerem verbinden sich hier schon mehrere Clients vom Standort B mit einem TS, welcher sich im selben Netzwerk befindet wie das NAS des Standorts A (192.168.0.0/24).
Im Zyxel sind die Subnetze 192.168.0.0/24 192.168.1.0/24 bei der IPSec Regelwerke hinterlegt.
Im Lancom und in der Pfsense sind statische Routen angelegt für jeweiligen anderen Subnetze.
Zunächst habe ich beide NAS im selben Netzwerk angeschlossen -> Verbindung und Einrichtung des Backup Jobs funktioniert ohne Probleme. Das Synology Backup funktioniert dabei im 'Push' Verfahren: Das NAS, welche die zu sichernden Dateien besitzt, baut eine Verbindung zum remote NAS auf. In diesem Fall also NAS des Standorts A zum NAS des Standorts B.
Anschließend habe ich die NAS an getrennten Standorten aufgebaut und die Verbindung funktioniert nicht mehr.
Sobald ich den Backup Job einrichte, baut das NAS am Standort A eine Verbindung zum Standort B auf. Am Ziel Router Zyxel kann ich dabei einen erfolgreichen Verbindungsaufbau in der Log sehen (ACCESS FORWARD 6281 192.168.0.129 -> 192.168.10.19).
Das Verrückte: vom NAS 'remote' kann ich jedoch erfolgreich einen Backup Job auf dem NAS'lokal' einrichten.
Die Verbindung NAS Standort B -> NAS Standort A funktioniert, die benötigte Verbindung NAS Standort A -> NAS Standort B hingegen nicht.
Ich wollte ausschließen, dass es sich hierbei um einen Konfigurationsfehler der NAS selbst handelt, also habe ich die beiden NAS Geräte getauscht und die dazugehörigen IP Adressen ausgetauscht und es ist immer noch das selbe Muster: NAS Verbindung Standort B -> Standort A klappt; Standort A -> B hingegen nicht.
Ping und Tracert von der NAS des Standorts A zur NAS des Standorts B funktioniert, genauso wie von NAS Standort B zu NAS Standort A
Ich hänge hier schon seit Tagen daran und komme einfach nicht weiter.... irgendeine Idee?
Danke
Traceroute:
traceroute to 192.168.10.19 (192.168.10.19), 30 hops max, 60 byte packets
1 pfSense.localdomain (192.168.0.1) 0.113 ms 0.089 ms 0.071 ms
2 192.168.1.2 (192.168.1.2) 1.851 ms 1.803 ms 1.805 ms
3 * * *
4 * * *
5 192.168.10.19 (192.168.10.19) 41.014 ms 45.618 ms 45.632 mstraceroute to 192.168.0.129 (192.168.0.129), 30 hops max, 60 byte packets
1 192.168.10.1 (192.168.10.1) 0.385 ms 0.313 ms 0.387 ms
2 * * *
3 192.168.1.2 (192.168.1.2) 33.607 ms 39.411 ms 39.578 ms
4 192.168.1.1 (192.168.1.1) 40.128 ms 39.919 ms 39.707 ms
5 192.168.0.129 (192.168.0.129) 40.559 ms 40.343 ms 40.693 ms
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3090391709
Url: https://administrator.de/contentid/3090391709
Ausgedruckt am: 04.12.2024 um 08:12 Uhr
13 Kommentare
Neuester Kommentar
Im Lancom und in der Pfsense sind statische Routen angelegt für jeweiligen anderen Subnetze.
Nur einmal nebenbei nachgefragt: Warum das??Das bedeutet ja dann das NAT (Adress Translation) am Koppelport dieser Router Kaskade abgeschaltet wurde und du die die Firewall ohne NAT betreibst. Ist dem so?
Andernfalls (mit NAT) wären statische überflüssig und auch gar nicht wirksam bzw. auch kontraproduktiv.
Auf der Zyxel Seite wären statische Routen sogar vollkommen überflüssig und auch kontraproduktiv da er da der einzige Router ist. Wozu sollen statische Routen da also gut sein?
Die Routen in die jeweiligen VPN Netze werden auf beiden Seiten automatisch über die Phase 2 SAs bestimmt und weitere Routen benötigt der Zyxel nicht. (Die pfSense im Falle von aktivem NAT auch nicht)
Das ist also etwas verwirrend und unverständlich an deiner Beschreibung bzw. dem Design.
Es ist zwar, wie gesagt, unverständlich und bedarf einer Klärung aber auch sicher nicht ursächlich, denn wenn du selber sagst das die Verbindung der beiden remoten IP Netze 192.168.0.0 /24 und 192.168.10.0 /24 via VPN fehlerlos klappt, dann ist der o.a. Punkt erstmal irrelevant, da eben nicht ursächlich. Am VPN an sich liegt es dann erstmal nicht.
Auch das die NAS lokal sauber funktionieren schliesst einen NAS Konfig Fehler primär erstmal aus.
Sehr viel sinnvoller wäre es allerdings gewesen diese beiden NAS an Standort A einmal in 2 unterschiedliche IP Netze zu legen und den Test zu wiederholen.
Dann findet er wenigstens in einer gerouteten FW Umgebung statt was deutlich realitätsnaher zur finalen Anwendung über das VPN gewesen wäre. Nundenn...
Es gibt 2 mögliche Fehlerursachen:
- Aktivierung von Jumbo Framing an den Netzwerk Adaptern der NAS. Das klappt lokal, führt aber bei NAS meistens zu einer Fehlfunktion über VPN Links.
- Fehler im Firewall Regelwerk. Dafür spricht das es in eine Richtung klappt in eine andere nicht. Hier solltest also nochmals genau die Regeln prüfen.
Was ebenso interessant wäre, ist die Frage ob ein Zugriff auf das GUI der jeweiligen remoten NAS problemlos möglich ist mit Browser Clients im jeweiligen lokalen LAN. Das würde dann zumindestens die gegenseitige TCP 80/443 Connectivity verifizieren und dann wieder den Fokus auf die NIC MTU legen.
Hallo,
danke für deine Rückmeldung
Ich glaube damals musste ich im Lancom die statische Route 192.168.10.0/24 setzen, obwohl in der IPSec Konfiguration des Lancoms 192.168.10.0/24 als entfernte Netze eingetragen sind. Bin mir da aber tatsächlich nicht 100% sicher. Selbst der Lancom VPN Einrichtungsassistent setzt eine statische Route.
In der Pfsense Firewall hingegen muss ich die statische Route setzen, da der Lancom nicht mein default Gateway ist, sondern lediglich als Interface hinterlegt ist, sodass ich den Zugriff hier über die Firewall regele. Über NAT selber habe ich nichts eingestellt.
Im Zyxel habe ich erst jetzt im Nachhinein die statische Route hinzugefügt, einfach weil mir die Ideen ausgegangen sind....
Tatsächlich kann ich auch nicht auf die web GUI (Port 5001) der remote NAS vom Standort A aus zugreifen. Von Standort B hingegen kann ich auf die web GUI der local NAS am Standort A zugreifen.
Pfsense protokolliert den Verbindungsaufbau und Verbindungsstatus, ebenso zeigt Zyxel den Verbindungsaufbau an.
Also das gleiche Muster.
Es scheint ja so als wenn die Firewall aller beteiligten Router die Verbindung erlauben, gleichzeitig die Verbindung aber nicht zu stande kommt. Das sieht doch fast schon so aus als wenn ein IDS die Verbindung sofort kappen würde? IDS in Lancom ist auf weiterleiten eingestellt, im Zyxel (soweit ich das sehen kann) nicht aktiviert und in der Pfsense ist die IDS auf Alert only eingestellt und erzeugt auch keine Alerts.
danke für deine Rückmeldung
Zitat von @aqui:
Im Lancom und in der Pfsense sind statische Routen angelegt für jeweiligen anderen Subnetze.
Nur einmal nebenbei nachgefragt: Warum das??Ich glaube damals musste ich im Lancom die statische Route 192.168.10.0/24 setzen, obwohl in der IPSec Konfiguration des Lancoms 192.168.10.0/24 als entfernte Netze eingetragen sind. Bin mir da aber tatsächlich nicht 100% sicher. Selbst der Lancom VPN Einrichtungsassistent setzt eine statische Route.
In der Pfsense Firewall hingegen muss ich die statische Route setzen, da der Lancom nicht mein default Gateway ist, sondern lediglich als Interface hinterlegt ist, sodass ich den Zugriff hier über die Firewall regele. Über NAT selber habe ich nichts eingestellt.
Im Zyxel habe ich erst jetzt im Nachhinein die statische Route hinzugefügt, einfach weil mir die Ideen ausgegangen sind....
Sehr viel sinnvoller wäre es allerdings gewesen diese beiden NAS an Standort A einmal in 2 unterschiedliche IP Netze zu legen und den Test zu wiederholen.
Dann findet er wenigstens in einer gerouteten FW Umgebung statt was deutlich realitätsnaher zur finalen Anwendung über das VPN gewesen wäre. Nundenn...
Stimme ich dir zu. Ich wollte das remote NAS Gerät noch einmal an den Lancom und anschließend Pfsense Firewall anschließen, um das Problem noch weiter eingrenzen zu können.Dann findet er wenigstens in einer gerouteten FW Umgebung statt was deutlich realitätsnaher zur finalen Anwendung über das VPN gewesen wäre. Nundenn...
Es gibt 2 mögliche Fehlerursachen:
Mit Jumbo Framing kenne ich mich jetzt noch gar nicht aus. Da müsste ich mich erst einmal einlesen.- Aktivierung von Jumbo Framing an den Netzwerk Adaptern der NAS. Das klappt lokal, führt aber bei NAS meistens zu einer Fehlfunktion über VPN Links.
* Fehler im Firewall Regelwerk. Dafür spricht das es in eine Richtung klappt in eine andere nicht. Hier solltest also nochmals genau die Regeln prüfen.
Was ebenso interessant wäre, ist die Frage ob ein Zugriff auf das GUI der jeweiligen remoten NAS problemlos möglich ist mit Browser Clients im jeweiligen lokalen LAN. Das würde dann zumindestens die gegenseitige TCP 80/443 Connectivity verifizieren und dann wieder den Fokus auf die NIC MTU legen.
Was ebenso interessant wäre, ist die Frage ob ein Zugriff auf das GUI der jeweiligen remoten NAS problemlos möglich ist mit Browser Clients im jeweiligen lokalen LAN. Das würde dann zumindestens die gegenseitige TCP 80/443 Connectivity verifizieren und dann wieder den Fokus auf die NIC MTU legen.
Tatsächlich kann ich auch nicht auf die web GUI (Port 5001) der remote NAS vom Standort A aus zugreifen. Von Standort B hingegen kann ich auf die web GUI der local NAS am Standort A zugreifen.
Pfsense protokolliert den Verbindungsaufbau und Verbindungsstatus, ebenso zeigt Zyxel den Verbindungsaufbau an.
Also das gleiche Muster.
Es scheint ja so als wenn die Firewall aller beteiligten Router die Verbindung erlauben, gleichzeitig die Verbindung aber nicht zu stande kommt. Das sieht doch fast schon so aus als wenn ein IDS die Verbindung sofort kappen würde? IDS in Lancom ist auf weiterleiten eingestellt, im Zyxel (soweit ich das sehen kann) nicht aktiviert und in der Pfsense ist die IDS auf Alert only eingestellt und erzeugt auch keine Alerts.
Pfsense mit der Protokollierung des Verbindungsstatus, sobald ich die web GUI aufrufe.
In der Pfsense Firewall hingegen muss ich die statische Route setzen, da der Lancom nicht mein default Gateway ist,
Ahh, OK, dann terminierst du das VPN auf dem Lancom und nicht auf der pfSense, richtig?Das war auch leider aus deiner o.a. Beschreibung nicht klar ersichtlich. Wenn dann zusätzlich auch noch dein pfSense Default Gateway nicht auf dem Lancom liegt, dann sind die Routen natürlich erforderlich, keine Frage. Sorry, aber das war durch die o.a. Schilderung nicht so ganz klar zumal es auch in der Zeichnung fehlte.
Mit Jumbo Framing kenne ich mich jetzt noch gar nicht aus.
Ooops...how come? Solche Basics sollte man aber als Netzwerk Admin kennen. 
Ist aber vielleicht auch besser, denn dann hast du die NIC MTUs an den NAS NICs sicher im Default (1500) belassen. So das (vermutlich) dieser Punkt dann entfällt.
Tatsächlich kann ich auch nicht auf die web GUI (Port 5001) der remote NAS vom Standort A aus zugreifen.
Was dann noch mehr für falsche bzw. fehlerhafte Firewall Regeln spricht. Irgendwas verhindert den Sessionaufbau. Du solltest mal einen Wireshark nehmen und dir den Verbindungsaufbau bei HTTP oder HTTPS genau ansehen und warum der scheitert. Zu 98% liegt der Fehler im IDS oder FW.Zitat von @aqui:
Ja genau, Lancom dient als Modem, VPN Gateway und Bereitstellung von einigen VLANs für Gastnetze, Telefonanlage etc.In der Pfsense Firewall hingegen muss ich die statische Route setzen, da der Lancom nicht mein default Gateway ist,
Ahh, OK, dann terminierst du das VPN auf dem Lancom und nicht auf der pfSense, richtig?Ooops...how come? Solche Basics sollte man aber als Netzwerk Admin kennen.
Ich mache das (zum Glück) nur für mich selbst, also nicht im Dienste eines KundenIst aber vielleicht auch besser, denn dann hast du die NIC MTUs an den NAS NICs sicher im Default (1500) belassen. So das (vermutlich) dieser Punkt dann entfällt.
Ja genau MTU 1500 ist überall eingestellt.Was dann noch mehr für falsche bzw. fehlerhafte Firewall Regeln spricht. Irgendwas verhindert den Sessionaufbau.
Wie könnten denn fehlerhafte Firewall Regeln zu dem Verhalten führen? Zyxel ist ja die letzte Firewall, die durchlaufen wird und leitet die Anfrage ja erfolgreich weiter. IDS verstehe ich aber sieht das mit allgemeinen Firewallregeln aus?
Hallo zusammen,
also so wie das sehe ist am Standort A das Problem vorhanden. Normalerweise, ich meine so wie das kenne
und auch von andere gehört habe, baut man so etwas wie an Standort A auf damit hinter der pfSense alles
sicher ist und dort niemand ran kommt. Und vor der pfSense ist alles was man aus dem LAN und von
außerhalb (Internet) gut erreichen soll! Ich würde einfach das NAS zwischen Lancom und pfSense
setzen wollen. Wenn alle Ports dicht sind kommt dort keiner ran und via VPN ist das dann auch
sicher und schneller erledigt als sich die pfSense "aufzubohren".
Zweitens was mir noch aufgefallen ist, der Standort B stellt aufgrund der DSlight Verbindung die VPN
Verbindung her, aber warum sollte dann der Synolgy Client das Backup machen? Nach hergestellter
VPN Verbindung würde ich dann lieber vom QNAP auf das Synology sichern und nicht umgekehrt.
Einfach mittels RSync versuchen.
Dobby
also so wie das sehe ist am Standort A das Problem vorhanden. Normalerweise, ich meine so wie das kenne
und auch von andere gehört habe, baut man so etwas wie an Standort A auf damit hinter der pfSense alles
sicher ist und dort niemand ran kommt. Und vor der pfSense ist alles was man aus dem LAN und von
außerhalb (Internet) gut erreichen soll! Ich würde einfach das NAS zwischen Lancom und pfSense
setzen wollen. Wenn alle Ports dicht sind kommt dort keiner ran und via VPN ist das dann auch
sicher und schneller erledigt als sich die pfSense "aufzubohren".
Zweitens was mir noch aufgefallen ist, der Standort B stellt aufgrund der DSlight Verbindung die VPN
Verbindung her, aber warum sollte dann der Synolgy Client das Backup machen? Nach hergestellter
VPN Verbindung würde ich dann lieber vom QNAP auf das Synology sichern und nicht umgekehrt.
Einfach mittels RSync versuchen.
Dobby
Zitat von @108012:
also so wie das sehe ist am Standort A das Problem vorhanden. Normalerweise, ich meine so wie das kenne
und auch von andere gehört habe, baut man so etwas wie an Standort A auf damit hinter der pfSense alles
sicher ist und dort niemand ran kommt. Und vor der pfSense ist alles was man aus dem LAN und von
außerhalb (Internet) gut erreichen soll!
So ist es, jaalso so wie das sehe ist am Standort A das Problem vorhanden. Normalerweise, ich meine so wie das kenne
und auch von andere gehört habe, baut man so etwas wie an Standort A auf damit hinter der pfSense alles
sicher ist und dort niemand ran kommt. Und vor der pfSense ist alles was man aus dem LAN und von
außerhalb (Internet) gut erreichen soll!
Ich würde einfach das NAS zwischen Lancom und pfSense
setzen wollen. Wenn alle Ports dicht sind kommt dort keiner ran und via VPN ist das dann auch
sicher und schneller erledigt als sich die pfSense "aufzubohren".
momentan 'bohre' ich ja nur von LAN(hinter pfSense) in Richtung VPN. Das NAS könnte ich theoretisch vor die pfSense setzen, vor allem weil die Backups dort verschlüsselt abgelegt werden, andererseits würde ich dann ja immer noch die pfSense 'aufboren', weil dann der Server, welcher auf das NAS sichert, nach draußen kommuniziert.setzen wollen. Wenn alle Ports dicht sind kommt dort keiner ran und via VPN ist das dann auch
sicher und schneller erledigt als sich die pfSense "aufzubohren".
Einfach mittels RSync versuchen.
Tatsächlich kann ich den Rsync Backup Job erstellen ohne Probleme, aber er hat beim Sichern Verbindungsabbrüche bzw kann keine Verbindung aufbauen. D.h ich hatte bereits am 3. Tag ein korruptes Backup...Mir ist es ebenfalls nicht möglich auf die Zyxel Oberfläche zu verbinden.
Ich werde jetzt das NAS testweise vor die pfSense setzen und schauen ob die Verbindung klappt. Falls es damit klappen sollte, ist wahrscheinlich Snort schuld, obwohl ich beide auf Whitelist habe.
Wenn die pfSense NAT (IP Adress Translation) macht an ihrem WAN Port, also dem Koppelport zum Lancom hast du dann bedacht das du dann nur mit Port Forwarding arbeiten kannst um das NAT überwinden zu können? Ohne Port Forwarding kommst du bei aktiviertem NAT nicht über den WAN Port ins die lokalen IP Netze der pfSense. Auch muss die Default Blocking Regel für RFC1918 IP Netze dort am WAN Port deaktviert sein.
Es lauern dort also 2 Hürden:
Mit NAT hast du logischerweise nur einseitiges Routing weil du in die andere Richtung die NAT Firewall ohne Port Forwarding NICHT überwinden kannst.
Das erklärt ggf. deine einseitige Connectivity!
Das kannst du übrigens sehr einfach und schnell über die Paket Capture Option im Diagnostics Menü der Firewall checken.
Es lauern dort also 2 Hürden:
- Firewall Regelwerk für inbound Connections
- NAT Gateway was ohne PFW nicht überwindbar ist.
Mit NAT hast du logischerweise nur einseitiges Routing weil du in die andere Richtung die NAT Firewall ohne Port Forwarding NICHT überwinden kannst.
Das erklärt ggf. deine einseitige Connectivity!
Das kannst du übrigens sehr einfach und schnell über die Paket Capture Option im Diagnostics Menü der Firewall checken.
Zitat von @aqui:
Wenn die pfSense NAT (IP Adress Translation) macht an ihrem WAN Port, also dem Koppelport zum Lancom hast du dann bedacht das du dann nur mit Port Forwarding arbeiten kannst um das NAT überwinden zu können? Ohne Port Forwarding kommst du bei aktiviertem NAT nicht über den WAN Port ins die lokalen IP Netze der pfSense. Auch muss die Default Blocking Regel für RFC1918 IP Netze dort am WAN Port deaktviert sein.
Es lauern dort also 2 Hürden:
Mit NAT hast du logischerweise nur einseitiges Routing weil du in die andere Richtung die NAT Firewall ohne Port Forwarding NICHT überwinden kannst.
Das erklärt ggf. deine einseitige Connectivity!
Das kannst du übrigens sehr einfach und schnell über die Paket Capture Option im Diagnostics Menü der Firewall checken.
Wenn die pfSense NAT (IP Adress Translation) macht an ihrem WAN Port, also dem Koppelport zum Lancom hast du dann bedacht das du dann nur mit Port Forwarding arbeiten kannst um das NAT überwinden zu können? Ohne Port Forwarding kommst du bei aktiviertem NAT nicht über den WAN Port ins die lokalen IP Netze der pfSense. Auch muss die Default Blocking Regel für RFC1918 IP Netze dort am WAN Port deaktviert sein.
Es lauern dort also 2 Hürden:
- Firewall Regelwerk für inbound Connections
- NAT Gateway was ohne PFW nicht überwindbar ist.
Mit NAT hast du logischerweise nur einseitiges Routing weil du in die andere Richtung die NAT Firewall ohne Port Forwarding NICHT überwinden kannst.
Das erklärt ggf. deine einseitige Connectivity!
Das kannst du übrigens sehr einfach und schnell über die Paket Capture Option im Diagnostics Menü der Firewall checken.
Die Verbindung der pfSense zum Lancom ist nicht als WAN Interface eingerichtet, sondern als normales LAN Interface.
Ich habe jetzt testweise die Diskstation vor die pfSense gepackt, also direkt an den Lancom angeschlossen.
Leider habe ich nach wie vor das gleiche Problem, eine Verbindung der NAS A zu NAS B ist nicht möglich, bzw die Verbindung wird direkt abgebrochen(z.B konnte ich einmalig das Verzeichnis der remote NAS auswählen, in das ich bei der Einrichtung des Backups hin sichern will, abschließen konnte ich die Einrichtung jedoch nicht).
Testweise habe ich die Firewall des Zyxel Routers und des Lancoms abgeschaltet, ohne Veränderung...
Kann es sein dass etwas an meiner VPN Einrichtung fehlerhaft und zu diesem Verhalten führt?
Ich bin echt am Ende mit meinem Latein...
Kann VLAN vlt. eine Begründung sein? Am Lancom habe ich das VLAN Localnet mit der VLAN ID 1 -> 192.168.1.0/24 PID1 vorliegen, welches dann wiederum per untagged port mit der pfSense verbunden ist.
sondern als normales LAN Interface.
Aha...dann ist das OK und auch das Routing verständlich. Aber alles Dinge die du leider in deiner Beschreibung unterschlagen hast und uns hier so ins offene Messer hast laufen lassen. Kein guter Stil... 
Leider habe ich nach wie vor das gleiche Problem
Spricht klar dafür das das Filter/Regel Problem schon davor besteht. Dann primär Lancom oder Zyxel. Die pfSense ist dann als Fehlerursache komplett raus.Kann es sein dass etwas an meiner VPN Einrichtung fehlerhaft und zu diesem Verhalten führt?
Nein, ganz sicher nicht wenn du sicherstellen kannst das die LAN zu LAN VPN Verbindung der 2 Netze gegeben ist. Sprich also ein Ping zwischen 2 Stationen dieser LANs fehlerlos klappt.Der Verdacht liegt dann am Regelwerk, da es wohl nur TCP Sessions betrifft.
Kann VLAN vlt. eine Begründung sein?
Nein, das ist ausgeschlossen. Jedenfalls nicht mit dem Fehlerbild. UNtagged Ports könnten ja niemals mit Tagged Ports kommunizieren. In der Beziehung gäbe es bei einem Tagging Mismatch generell keinerlei Kommunikation was bei dir ja nicht der Fall ist.Du taggst dein VLAN 1 ja auch nicht wenn die PVID 1 ist. Also ist das untagged auf untagged und damit richtig.
Außerdem kannst du das ja auch kinderleicht selber mit einem Ping über das Diagnostics Menü der pfSense checken wenn du dort die Source IP auf ihre IP in dem VLAN legst und den Lancom pingst. Klappt der Ping hast du kein Tagging Problem.
Abgesehen davon tritt der Fehler ja auch direkt am Lancom Interface auf was die pfSense als mögliche Ursache ja dann sofort rausnimmt.
Zitat von @aqui:
Im meinem ersten Beitrag hatte ich vergessen es korrekt zu beschreiben, in meiner ersten Antwort auf deinen Beitrag habe ich dies aber korrigiertsondern als normales LAN Interface.
Aha...dann ist das OK und auch das Routing verständlich. Aber alles Dinge die du leider in deiner Beschreibung unterschlagen hast und uns hier so ins offene Messer hast laufen lassen. Kein guter Stil... In der Pfsense Firewall hingegen muss ich die statische Route setzen, da der Lancom nicht mein default Gateway ist, sondern lediglich als Interface hinterlegt ist, sodass ich den Zugriff hier über die Firewall regele. Über NAT selber habe ich nichts eingestellt.
Ich konnte das Problem jetzt doch beheben. Ursächlich war die zu hoch eingestellte MTU von 1500, ggf. in Kombination mit der DS-Lite Verbindung an meinem Zyxel Router.
Obwohl in der IKEv2 Einstellung vorgegeben war, dass die MTU automatisch gesetzt werden sollte (und Lancom dies eig auch unterstützen müsste?), war dies nicht der Fall.
Eine Reduzierung der MSS auf <1362 hat schlußendlich mein Problem gelöst.
Trotzdem vielen Dank, insbesondere @aqui
Ursächlich war die zu hoch eingestellte MTU von 1500, ggf. in Kombination mit der DS-Lite Verbindung an meinem Zyxel Router.
Wie schon vermutet... dass die MTU automatisch gesetzt werden sollte (und Lancom dies eig auch unterstützen müsste?),
Das ist auch richtig und sollte auch so sein. MTU betrifft aber immer beide Seiten und wenn der Lancom das macht, der Zyxel aber nicht geht das natürlich trotzdem in die Hose... Aber gut wenn es nun rennt wie es soll, dann können wir entspannt ins Wochenende... 😎
