VLANS über 1 VPN Tunnel (Bintec - UTM)
Hallo,
ich habe mich hier registriert um eventuell nach stundenlangem, erfolglosem Ausprobieren und Suchen eine Lösung zu finden.
Folgendes Szenario:
SOPHOS UTM (10.100.0.10) (SERVER)
Bintec be.ip plus (10.200.0.10) (CLIENTS)
Zwischen den Geräten besteht eine VPN Verbindung ins Netz der Bintec 10.200.0.0/24
Nun habe ich im Bintec im br0 Modus mehrere VLANs eingerichtet - um das ganze hier abzukürzen belasse ich es bei dem VLAN 10.
Wenn der Client sich im normalen Lan befindet (10.200.0.0/24) kann natürlich eine VPN Verbindung aufgebaut werden.
Versucht man es jedoch von einem Client aus dem VLAN 10 (10.200.10.0/24) scheitert es.
Ist natürlich klar. In der Firewall im BINTEC habe ich die Verbindung erlaubt.
Wie kann ich im BINTEC nun eine Route der Schnittstellen einrichten, dass die Anfragen an die 10.100.0.0/24 (UTM) über die VPN Verbindung von 10.200.0.0 (normales Lan) vom 10.200.10.0/24(VLAN10) Adressbereich möglich ist?
Was ich nicht möchte bzw. umgehen will:
In der UTM jedes einzelne Subnetz als "Entferntes Netz" anlegen, weil dann in jedes Subnetz eine eigene VPN Verbindung aufgebaut wird und mir das zu fehleranfällig ist.
Ich hoffe das ist einigermaßen verständlich.
Vielen vielen Dank im Voraus!
Trickme
ich habe mich hier registriert um eventuell nach stundenlangem, erfolglosem Ausprobieren und Suchen eine Lösung zu finden.
Folgendes Szenario:
SOPHOS UTM (10.100.0.10) (SERVER)
Bintec be.ip plus (10.200.0.10) (CLIENTS)
Zwischen den Geräten besteht eine VPN Verbindung ins Netz der Bintec 10.200.0.0/24
Nun habe ich im Bintec im br0 Modus mehrere VLANs eingerichtet - um das ganze hier abzukürzen belasse ich es bei dem VLAN 10.
Wenn der Client sich im normalen Lan befindet (10.200.0.0/24) kann natürlich eine VPN Verbindung aufgebaut werden.
Versucht man es jedoch von einem Client aus dem VLAN 10 (10.200.10.0/24) scheitert es.
Ist natürlich klar. In der Firewall im BINTEC habe ich die Verbindung erlaubt.
Wie kann ich im BINTEC nun eine Route der Schnittstellen einrichten, dass die Anfragen an die 10.100.0.0/24 (UTM) über die VPN Verbindung von 10.200.0.0 (normales Lan) vom 10.200.10.0/24(VLAN10) Adressbereich möglich ist?
Was ich nicht möchte bzw. umgehen will:
In der UTM jedes einzelne Subnetz als "Entferntes Netz" anlegen, weil dann in jedes Subnetz eine eigene VPN Verbindung aufgebaut wird und mir das zu fehleranfällig ist.
Ich hoffe das ist einigermaßen verständlich.
Vielen vielen Dank im Voraus!
Trickme
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 516639
Url: https://administrator.de/forum/vlans-ueber-1-vpn-tunnel-bintec-utm-516639.html
Ausgedruckt am: 27.04.2025 um 20:04 Uhr
5 Kommentare
Neuester Kommentar
Hallo Trickme,
das ist schon normal ein ziemliches gewurstel, zwischen Bintec und Sophos dürfte das zu dem problematischer werden, weil du dann noch mit unterschiedlichem Handling konfrontiert bist (wenn es überhaupt geht). Am zielführendsten dürfte daher der einzelne Schritt sein, oder du gehst direkt über die RED Funktion der Sophos. Damit sparst du dir eine Menge Zeit und hast eine solide Umsetzung.
VG
das ist schon normal ein ziemliches gewurstel, zwischen Bintec und Sophos dürfte das zu dem problematischer werden, weil du dann noch mit unterschiedlichem Handling konfrontiert bist (wenn es überhaupt geht). Am zielführendsten dürfte daher der einzelne Schritt sein, oder du gehst direkt über die RED Funktion der Sophos. Damit sparst du dir eine Menge Zeit und hast eine solide Umsetzung.
VG
Vielen Dank für die schnelle Antwort!
Das dachte ich mir fast schon. Die VPN Verbindung zwischen einer UTM und der BINTEC ist ja leider auch nicht die stabilste Konstellation.
Auf die UTM im RZ greifen eine handvoll Bintecs (Zweigstellen) per VPN drauf zu. Fast monatlich muss ich gefühlt der Reihe nach alle IPSEC Verbindungen in der UTM neustarten, weil aus unerklärlichen Gründen keine Verbindung mehr möglich ist obwohl die VPN Verbindung steht, zumindest wird dies so angezeigt in der UTM und im Bintec.
Das Problem haben scheinbar jedoch einige.
- Wenn das dann nun auch noch pro VLAN zukünftig passiert muss ich wohl erstmal die ganze VLAN Geschichte aufgeben und wieder zurück ins einfache Lan Netz...
Normalerweise habe ich die UTM als "Nur antworten" konfiguriert, doch dies musste ich nun auch schon auf "initiieren" umstellen, da sich sonst z.B. der Drucker im anderen VLAN nicht übers VPN ansteuern lässt, da der Ping ja nicht vom Drucker kommt.
In den Zweigstellen z.B. eine RED15 zu stellen ist zur Zeit leider zu teuer (vor allem wegen den jährlichen Lizenzen), da die Bintecs alle erst 1-3 Jahre alt sind und oft nur 3-5 Arbeitsplätze dahinter stecken - auch wenn das wohl die beste Lösung wäre.
VG
Das dachte ich mir fast schon. Die VPN Verbindung zwischen einer UTM und der BINTEC ist ja leider auch nicht die stabilste Konstellation.
Auf die UTM im RZ greifen eine handvoll Bintecs (Zweigstellen) per VPN drauf zu. Fast monatlich muss ich gefühlt der Reihe nach alle IPSEC Verbindungen in der UTM neustarten, weil aus unerklärlichen Gründen keine Verbindung mehr möglich ist obwohl die VPN Verbindung steht, zumindest wird dies so angezeigt in der UTM und im Bintec.
Das Problem haben scheinbar jedoch einige.
- Wenn das dann nun auch noch pro VLAN zukünftig passiert muss ich wohl erstmal die ganze VLAN Geschichte aufgeben und wieder zurück ins einfache Lan Netz...
Normalerweise habe ich die UTM als "Nur antworten" konfiguriert, doch dies musste ich nun auch schon auf "initiieren" umstellen, da sich sonst z.B. der Drucker im anderen VLAN nicht übers VPN ansteuern lässt, da der Ping ja nicht vom Drucker kommt.
In den Zweigstellen z.B. eine RED15 zu stellen ist zur Zeit leider zu teuer (vor allem wegen den jährlichen Lizenzen), da die Bintecs alle erst 1-3 Jahre alt sind und oft nur 3-5 Arbeitsplätze dahinter stecken - auch wenn das wohl die beste Lösung wäre.
VG
Das dachte ich mir fast schon. Die VPN Verbindung zwischen einer UTM und der BINTEC ist ja leider auch nicht die stabilste Konstellation.
Generell sind bintec, naja... hab da vor 15 Jahren mal den Sec Expert gemacht, war an sich schon ein Witz.
Normalerweise habe ich die UTM als "Nur antworten" konfiguriert, doch dies musste ich nun auch schon auf "initiieren" umstellen, da sich sonst z.B. der Drucker im anderen VLAN nicht übers VPN ansteuern lässt, da der Ping ja nicht vom Drucker kommt.
Wenn die VPN steht macht das keinen Unterschied
In den Zweigstellen z.B. eine RED15 zu stellen ist zur Zeit leider zu teuer (vor allem wegen den jährlichen Lizenzen), da die Bintecs alle erst 1-3 Jahre alt sind und oft nur 3-5 Arbeitsplätze dahinter stecken - auch wenn das wohl die beste Lösung wäre.
Lass uns das gerne mal durchkalkulieren. Nehme an, du bist die interne IT?
Schreib mir gerne direkt eine Email.
VG
Moin.
Also grundsätzlich: wenn das ein S2S-Tunnel ist, kennen beide Router ja das jeweils andere Netz.
Du musst
a) nur auf beiden Firewalls die richtigen Regeln setzen (vermutlich jeweils ein alles 10.xxx.0.0/16?)
b) das mit einem traceroute testen
c) beim Ping gegen einen Windows-Client die Firewall dessen auch für das „fremde“ Netz zulassen
Gruß
em-pie
Also grundsätzlich: wenn das ein S2S-Tunnel ist, kennen beide Router ja das jeweils andere Netz.
Du musst
a) nur auf beiden Firewalls die richtigen Regeln setzen (vermutlich jeweils ein alles 10.xxx.0.0/16?)
b) das mit einem traceroute testen
c) beim Ping gegen einen Windows-Client die Firewall dessen auch für das „fremde“ Netz zulassen
Gruß
em-pie
Das Problem hat, wie immer, nichts mit "Routen" zu tun. Wäre ja auch Blödsinn, denn beide Router an beiden Enden des VPN Tunnels "kennen" ja logischerweise alle an sie direkt an angeschlossenen IP Netze ! Sie sind ja direkt dran...
IP Routen wären da also völlig sinnfrei und überflüssig.
Der Fehler liegt zu 98% in einer falschen oder fehlerhaften VPN Konfiguration bei den SAs der lokalen bzw. remoten Seite.
Leider war der TO nicht in der Lage die Art bzw. das Protokoll seines verwendeten VPNs zu spezifizieren aber nehmen wir mal an das es vermutlich IPsec ist.
Hier wäre die spezifische Konfig der beiden Seiten hilfreich und zielführend gewesen aber leider fehlt diese wichtige Information.
Zu 98% wurde hier vergessen ALLE remoten IP Netze oder alle die die geroutet werden sollen über den Tunnel zu spezifizieren. Kollege @em-pie hat es oben schon richtigerweise angesprochen.
Es gibt vermutlich nur eine SA Definition der Netze 10.100.0.0/24 und 10.200.0.0/24 NICHT aber der zusätzlichen VLAN Segmente. Ohne diese IPsec Definition werden diese aber dann logischerweise niemals in den Tunnel geroutet. Da helfen dann auch noch so viele Firewall Regeln oder Routen nicht.
Aber wie gesagt alles erstmal geraten, weil die Infos des TO hier leider etwas oberflächlich zum Thema IPsec VPN Konfig sind !
Grundlagen dazu wie immer hier:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
IP Routen wären da also völlig sinnfrei und überflüssig.
Der Fehler liegt zu 98% in einer falschen oder fehlerhaften VPN Konfiguration bei den SAs der lokalen bzw. remoten Seite.
Leider war der TO nicht in der Lage die Art bzw. das Protokoll seines verwendeten VPNs zu spezifizieren aber nehmen wir mal an das es vermutlich IPsec ist.
Hier wäre die spezifische Konfig der beiden Seiten hilfreich und zielführend gewesen aber leider fehlt diese wichtige Information.
Zu 98% wurde hier vergessen ALLE remoten IP Netze oder alle die die geroutet werden sollen über den Tunnel zu spezifizieren. Kollege @em-pie hat es oben schon richtigerweise angesprochen.
Es gibt vermutlich nur eine SA Definition der Netze 10.100.0.0/24 und 10.200.0.0/24 NICHT aber der zusätzlichen VLAN Segmente. Ohne diese IPsec Definition werden diese aber dann logischerweise niemals in den Tunnel geroutet. Da helfen dann auch noch so viele Firewall Regeln oder Routen nicht.
Aber wie gesagt alles erstmal geraten, weil die Infos des TO hier leider etwas oberflächlich zum Thema IPsec VPN Konfig sind !
Grundlagen dazu wie immer hier:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
