Bintec-VPN Site-to-Site hinter pfSense

nodau

Bei einer Site-2-Site Verbindung wird der Tunnel wahlweise von einer oder der anderen Seite aufgebaut.

Die beiden Standorte nutzen eigenes Internet. Es soll über den VPN-Tunnel nur der Zugriff auf lokale Ressourcen am jeweiligen Standort ermöglicht werden.

Leider weigert sich die IT (Bequemlichkeit oder Unwissenheit) den Zugriff direkt über die pfSense aufzubauen.

Der Admin ist der Meinung, dass ich den Bintec einfach ins LAN hänge und ne statische Route erstelle. Das funktioniert überall. Habe ihm erklärt, dass ich dann einen Routing loop habe. Hat er nicht verstanden.

tracert 192.168.152.1
-> pfsense
-> bintec
-> pfsense
-> bintec
...

Der Tunnel wird zwar aufgebaut, aber kein Traffic. Wie auch?

Edit: ist Bintec RS123

viragomann

@bahsig said in Bintec-VPN Site-to-Site hinter pfSense:

Der Admin ist der Meinung, dass ich den Bintec einfach ins LAN hänge und ne statische Route erstelle.

Das kann schon funktionieren, wenn dieser Bintec die Verbindung zum Remote-Endpunkt aufbaut. Dann braucht es auch die ganzen Weiterleitungen nicht.

Die statische Route würdest du aber auf jedem Gerät benötigen, das mit der Remoteseite kommunizieren soll. Mit nur einer auf der pfSense funktioniert es nicht.

nodau

@viragomann

Also wenn ich den Bintec ins LAN hänge und auf einem PC ne statische Route mit GW Bintec erstelle, kommt kein Traffic zustande. Heißt also der Bintec ist falsch konfiguriert.

tracert 192.168.152.1
-> bintec
-> pfsense
-> pfsense WAN
->Zeitüberschreitung

Ich teste mal weiter.

viragomann

@bahsig said in Bintec-VPN Site-to-Site hinter pfSense:

tracert 192.168.152.1
-> bintec
-> pfsense

Auf die pfSense sollte es da ja nicht gehen, denke ich.
Ist diese IP im Remote-Netz? Dann ist wohl die VPN nicht aufgebaut.

NOCling

Mutig extern so eine Kiste raus zu geben und eingehend IPsec vorauszusetzen.

Rein ausgehend würde noch Sinn machen.

Würde dafür 2 VLANs verwenden.
Eines für das WAN und den Int Zugriff der Kiste.

Eines für LAN und da kommt die statische Route zu den Remote Netzen drauf.
Dann kannst du schön weiter mit deiner pfSense arbeiten und hast die Kiste in einer internen DMZ, das du steuern kannst was aus dem Tunnel raus kommen darf.
Könnte ja auch was böses dabei sein, so was mag man ja nicht. Die Gegenseite macht das hoffentlich auch.

Viel Glück

nodau

@viragomann

Ich denke ja. Komme leider nicht auf den Bintec. Laut Admin steht der Tunnel zwichen den beiden Bintec Routern. Aber so wie es aussieht, kennt der Bintec das 152er Netz nicht und will es über sein Standardgateway, pfSense in diesem Fall auflösen, was logischerweiser nicht funktionieren kann.

Letzte Frage. Wenn ich auf der pfSense ein GW für das LAN anlege, mit der IP des Bintec, kann ich anschließend die Route auf das Bintec GW setzen. Wäre das generell möglich oder eher nicht?

viragomann

@bahsig said in Bintec-VPN Site-to-Site hinter pfSense:

Aber so wie es aussieht, kennt der Bintec das 152er Netz nicht

Wo liegt dieses Netz?

Wenn ich auf der pfSense ein GW für das LAN anlege, mit der IP des Bintec, kann ich anschließend die Route auf das Bintec GW setzen. Wäre das generell möglich oder eher nicht?

Du meinst in deinem LAN mit den Geräten, die mit der Remoteseite kommunizieren sollen?
Das würde nicht klappen. Es würde zu asymmetrischem Routing führen, weil die Pakete zu deiner Seite direkt auf die Ziel-IP gehen würden, während deine Geräte ihre Antwortpakete auf die pfSense schicken würden. Die pfSense würde das blocken, weil sie nur einen Teil der Pakete sieht.
Das lässt sich zwar mit entsprechenden Regeln umgehen, aber möchtest du die Remoteseite wirklich völlig unkontrolliert im LAN haben?

Grundsätzlich klappt das mit dem Transitnetz. Ich hatte auch mal eine Kiste bekommen, die eine IPSec nachhause aufgebaut hat. Die musste allerdings nur mit einem Server kommunizieren, ansonsten war es dieselbe Situation.
IPSec habe ich weitergeleitet und auf dem Transitnetz konnte ich kontrollieren, wohin das Teil sich verbinden darf.

nodau

@viragomann

Also mal mit Zahlen:

LAN: 172.31.0.0/22
Entferntes LAN: 192.168.152.0/23

@viragomann said in Bintec-VPN Site-to-Site hinter pfSense:

Das lässt sich zwar mit entsprechenden Regeln umgehen, aber möchtest du die Remoteseite wirklich völlig unkontrolliert im LAN haben?

Die Netze sollen untereinander ohne Einschränkung kommunizeren.

Bintec GW hängt im LAN mit 172.31.1.113/22 und hat selber als GW die pfSense.

Wie würden denn die Regeln aussehen, wenns nur mit dem asymmetrischen Routing geht?

Ich kann auch nicht nachvollziehen, warum der Admin der Meinung ist, dass er auf seiner Seite sämtliche Routen zu uns umschreiben muss, wenn der Bintec, der bei uns steht in einem eigenen, separaten Netz hängt und nicht wie aktuell im LAN. Er versteht leider die Logik bei der pfSense nicht. Also wird er den Bintec nicht umkonfigurieren.

NOCling

Wie gesagt zwei Interface und ich würde mit einer NAT IP mit dem Bintec im LAN auf pfSense Seite sprechen.
Dann veraschen wir ihn halt und er antwortet sauber, da er denkt mit einem Client im gleichen Netz zu sprechen.

Denn sonst braucht der Bintec auch Routen zu deiner Sense und deinen Netzen, das will der Admin von dem Ding aber nicht.
Also mit NAT austricksen, fertig und ruhe.

viragomann

@bahsig said in Bintec-VPN Site-to-Site hinter pfSense:

LAN: 172.31.0.0/22
Entferntes LAN: 192.168.152.0/23

Wenn nun der Bintec Paket mit Zieladresse in 192.168.152.0/23 auf die pfSense schickt, dann hat er keine VPN aufgebaut, oder sie ist falsch konfiguriert. Das sollte auch der entfernte Admin verstehen.

Ich kann auch nicht nachvollziehen, warum der Admin der Meinung ist, dass er auf seiner Seite sämtliche Routen zu uns umschreiben muss,

Das einzige, was anders einzurichten wäre, könnte die lokale IP sein. Aber wenn er nur ein klein wenig schlau ist und dir auch was zutraut, dann konfiguriert er die Schnittstelle für DHCP. Dann ist die IP unter deiner Kontrolle, wie es sein sollte.
Ansonsten hat er nur die IPSec einzurichten mit einem Tunnel für die beiden Seiten und die öffentliche IP, mit welcher er sich verbinden soll.

Dann ist es völlig egal, ob er im selben Netz wie die Zielgeräte liegt oder nicht. Ist er es nicht (Transitnetz) routet er dein lokales LAN eben auf das dafault Gateway, das er auch vom DHCP mitgeteilt bekommt.