OpenVPN Site2Site TAP beidseitig mehrere Netzwerke


  • Hallo Forum,

    ich habe zwei pfSense per openVPN TAP Verbindung miteinanander verbunden und das läuft schon geraume Zeit so. TAP muss sein, da gibt es keine Alternative. Die pfSense1 mit der OpenVPN Client Einrichtung ist der primäre Netzwerkstandort mit Servern (DHCP und DNS Server, Dateifreigaben usw.), die hat mehrere Internetanbindungen und neben dem primären LAN(linkeSeite) noch weitere 2 Netzwerke (LANB und LANC). Die pfSense2 mit dem OpenVPN Server ist das untergeordnete Netzwerk, hat nur 1x WAN und neben dem primären LAN(rechte Seite) auch noch ein weiteres Netzwerk (LAND) aber eben keinen DHCP auf LAN. Die Richtung welche pfSense OpenVPN Server und welche OpenVPN Client ist steht auch zwangsweise fest.

    Die Computer in LAN(linkeSeite) und den weiteren Netzwerken (LANB und LANC) hinter der pfSense1 welche OpenVPN Client spielt kommen auf die Computer im LAN(rechteSeite) und dem zweiten Netzwerk (LAND) hinter der pfSense2 welche OpenVPN Server ist. Sprich: LAN(linke Seite) + LANB + LANC kommen zum LAN(rechte Seite) + LAND.

    Die Computer in LAN(rechteSeite) und dem weiteren Netzwerk (LAND) hinter der pfSense2 welche OpenVPN Server spielt kommen nur (vollständig) auf die Computer im LAN(linkeSeite) hinter der pfSense1 welche OpenVPN Client ist. Sprich: LAN(rechte Seite) + LAND kommen nur zum LAN(linke Seite). Die können die Computer in LANB und LANC nur anpingen, 'mehr nicht'.

    Beispiel: TCP-SYN Verbindungsanfragen von QuellComputern aus LAN(rechteSeite) der pfSense2 kommen zum LAN(linkeSeite) der pfSense1, gehen z.B. in LANB zum ZielComputer, Antworten TCP-ACK vom ZielComputer aus LANB kommen durch den OpenVPN Tunnel zurück zur pfSense2 und landen dort in der Firewall der Default Block Rule des Interface OpenVPN als TCP ACK mit Quelle LANB ZielComputer und Ziel LAN(rechteSeite) zum QuellComputer. Kann man schön in deren Log sehen. Ich nehme an weil diese Päckchen vom OpenVPN Client kommen und die Quelle der Päckchen halt ein Netzwerk ist was die pfSense2 mit dem OpenVPN Server nicht kennt, sprich weder deren LAN(rechteSeite) noch LAND. Andersrum geht es ja.

    Hat jemand eine Idee wo mein Fehler ist. Muss ich irgendwas auf der pfSense1 natten so dass die Päckchen von den Quelladdressen LANB oder LANC die nach LAN(rechte Seite) der pfSense2 gehen die Quelladdresse des LAN bekommen?

    Danke schon mal im Voraus für das viele Lesen und die Mühe des Verstehens ;)


  • noch mal visuell damit es vielleicht verständlicher wird:
    ProblemNet.jpg


  • Hat keiner eine passende Idee wie es weitergehn kann?


  • @bon-go
    Hi,
    was sagen denn die Logs der Firewall links, wie sieht die Routing-Tabelle aus.
    Ich tippe mal auf ein Problem in den OpenVPN-Server Einstellungen, wo eventuell die push LANB/C nicht eingetragen ist oder die Firewall-Rules.
    Wobei ein funktionierendes Ping, eigentlich eher für die Firewall-Rules spricht.
    Aber das sagen Dir die Logs und wenn nicht, dann ist ein Paket-Sniffer wie Wireshark von Vorteil und hilft Dir eventuell weiter. Denke an den Paket-Rückweg.
    Wobei die pfSense eigentlich genug Möglichkeiten bietet, das Problem einzugrenzen.
    Gruß orcape


  • @orcape
    Lange Rede kurzer Sinn: es funktioniert seit heute morgen.

    Ja, wireshark ist mein Freund. Das Theme Push Routen, lokale Netzwerke, entfernte Netzwerke, manuelle Gateways und Routen darüber sowie Firewall Regeln mit Zugriffen zu diesen Netzwerken über diese Gateways ist zwar alles gut und schön aber hat nichts Reales gebracht. Ich laboriere schon eine gewisse Zeit an dem Problem und auch einiges eher wie ich hier den ersten Post darüber geschrieben habe.

    Da das gesamte Szenario noch einiges komplexer ist wie schematisch dargestellt und auch sehr stark genutzt wird ist es nicht eben einfach dort am lebenden Objekt zu irgend einer Zeit große Experimente anzusetzen.

    Ich hatte dieses Szenario leicht abgespeckt schon vor längerer Zeit virtualisiert nachgebaut und da funktioniert seit jeher alles was funktionieren muss. Nur halt in der produktiv genutzten Umgebung nicht. Ping geht, sonstiger Traffic nicht. Pakete blieben in der default Block Rule am OpenVPN Interface hängen.

    Ich kann auch nicht mal eben alles neue aufsetzen. Also habe ich wie üblich alles schön gesichert, alle diese VPN Tunnel, Routen, Gateways und Regeln betreffenden Dinge gelöscht und diesen gesamten Teil noch einmal nach Plan mit Zettel und Stift neu eingerichtet. Nach div. Feineinstellungen und Neustarts funktioniert es auf Anhieb wie es soll. Wenn ich mir die Konfiguration vorher und nachher anschaue kann ich allerdings auch nach Stunden des Studiums keinen entscheidenden Unterschied vorher zu nachher erkennen der die Ursache des Problems zeigen würde. Ich müsste mir die vier config.xml sehr genau anschauen und die sind je knapp 300k groß. Ich lass es. Ich habe jetzt alles wieder gesichert, beobachte das und lasse es wie es ist.

    Perversitäten der EDV sage ich nur - aber wer bin ich mich zu beschweren wenn etwas funktioniert.


  • @bon-go Freut mich wenn es läuft. Egal wie man das alles aufsetzt, ein Tunnel und die entsprechenden angebundenen Netze sind nun einmal nicht so ganz trivial. Aber es ist halt auch immer wieder eine Herausforderung und man freut sich, wenn man das Problem gelöst hat. Schönen Abend... Gruß orcape


  • This post is deleted!