31
VPN (Site to Site) zwischen Mikrotik und Sophos
Hallo und Nabend in die Runde ...
ich habe ein paar Probleme bei dem mir nicht klar wird, wo ich die Fehler (den Fehler) suchen soll.
Wir haben eine bestehende IPSEC-Verbindung zwischen einer Sophos-Firewall und einem Mikrotik CCR für zwei Netzwerke "gespannt".
Verbunden werden sollen ein /24 Netz /192.168.99.0 (Arbeitsplätze) und das entfernte Netz 10.255.204.0/24 .
Die Geräte in diesen Netz sind IP-Gateway (TCS) mit einem Admin Port(80) und einem Dataport (3543) zur Anbindung an einen TCS-Server.
Die beiden Peers sind sauber verbunden. Ich kann vom PC aus (z.B. PC mit 192.168.99.69) den IP-Gateway 10.255.204.4 anpingen und auch das WEB-Interface öffnen.
Nun gibt es aber noch den TCS-Server . Dieser ist auch im Netz 192.168.99.0/24 mit der IP 192.168.99.6 angesiedelt.
Wenn ich nun die Zentralen(also die TCS-Gateway aus dem 10.255.204.0/24 - Netz) in die Liste des Servers einfüge, dann kann diese sie leider nicht finden.
Jedenfalls kommt es nicht zum Abgleich der Datenbanken zwischen den beiden Geräten. Sie stehen immer als Offline drin. Ab und an steht im Loggin auch mal ..."mit Server verbunden"
Jedoch kommt es nicht zum auflisten mit "Online"
Ich habe in der Sophos-Firewall die Route zum Netz 10.255.204.0/24 an das Interface (Port2) mit der externen IP (erhalten über PPPOE) gelegt.
Andersherum habe ich im CCR das remote Netzwerk (also das 192.168.99.0/24 - Netz) auf die lokale externe IP gelegt. Denn ein Interface wie bei L2TP habe ich ja nicht.
In der Firewall habe ich dann über NAT beide erlaubt Forward zu machen. Jeweils in beide Richtungen. Auch die Sophos hat die Filter selbst erzeugt.
Habe ich noch etwas vergessen oder liegt der Fehler wo anders ?
Muss ich vielleicht doch die Route auf das Interface legen, welche von mir die externe IP bekommen hat oder kann ich gar drauf verzichten?
Liegt es vielleicht auch daran, dass das 204er Netz bzw. Interface Mitglied in einer Bridge ist ?
Muss ich vielleicht auch hier dann innerhalb der Bridge NAT Regeln erstellen ?
Bin ein wenig verunsichert ...
Wäre super, wenn ihr mir den Weg den ich gehen muss ... ein wenig vorgebt !
Danke schon einmal .... und wenn noch Informationen fehlen ... , diese gebe ich gern.
...bis später
ich habe ein paar Probleme bei dem mir nicht klar wird, wo ich die Fehler (den Fehler) suchen soll.
Wir haben eine bestehende IPSEC-Verbindung zwischen einer Sophos-Firewall und einem Mikrotik CCR für zwei Netzwerke "gespannt".
Verbunden werden sollen ein /24 Netz /192.168.99.0 (Arbeitsplätze) und das entfernte Netz 10.255.204.0/24 .
Die Geräte in diesen Netz sind IP-Gateway (TCS) mit einem Admin Port(80) und einem Dataport (3543) zur Anbindung an einen TCS-Server.
Die beiden Peers sind sauber verbunden. Ich kann vom PC aus (z.B. PC mit 192.168.99.69) den IP-Gateway 10.255.204.4 anpingen und auch das WEB-Interface öffnen.
Nun gibt es aber noch den TCS-Server . Dieser ist auch im Netz 192.168.99.0/24 mit der IP 192.168.99.6 angesiedelt.
Wenn ich nun die Zentralen(also die TCS-Gateway aus dem 10.255.204.0/24 - Netz) in die Liste des Servers einfüge, dann kann diese sie leider nicht finden.
Jedenfalls kommt es nicht zum Abgleich der Datenbanken zwischen den beiden Geräten. Sie stehen immer als Offline drin. Ab und an steht im Loggin auch mal ..."mit Server verbunden"
Jedoch kommt es nicht zum auflisten mit "Online"
Ich habe in der Sophos-Firewall die Route zum Netz 10.255.204.0/24 an das Interface (Port2) mit der externen IP (erhalten über PPPOE) gelegt.
Andersherum habe ich im CCR das remote Netzwerk (also das 192.168.99.0/24 - Netz) auf die lokale externe IP gelegt. Denn ein Interface wie bei L2TP habe ich ja nicht.
In der Firewall habe ich dann über NAT beide erlaubt Forward zu machen. Jeweils in beide Richtungen. Auch die Sophos hat die Filter selbst erzeugt.
Habe ich noch etwas vergessen oder liegt der Fehler wo anders ?
Muss ich vielleicht doch die Route auf das Interface legen, welche von mir die externe IP bekommen hat oder kann ich gar drauf verzichten?
Liegt es vielleicht auch daran, dass das 204er Netz bzw. Interface Mitglied in einer Bridge ist ?
Muss ich vielleicht auch hier dann innerhalb der Bridge NAT Regeln erstellen ?
Bin ein wenig verunsichert ...
Wäre super, wenn ihr mir den Weg den ich gehen muss ... ein wenig vorgebt !
Danke schon einmal .... und wenn noch Informationen fehlen ... , diese gebe ich gern.
...bis später
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: 621501
Url: https://administrator.de/forum/vpn-site-to-site-zwischen-mikrotik-und-sophos-621501.html
Ausgedruckt am: 23.12.2024 um 00:12 Uhr
31 Kommentare
Neuester Kommentar
Kannst Du deinen Text noch Mal aufmerksam lesen? Auch das Bild noch Mal prüfen?
guten Morgen ! So, Text nochmals gelesen ... und Suche beendet. Finde aber nicht das, was du siehst . Gern nehme ich deinen Hinweis auf ?
... klarer Hinweis auf einen Schreibfehler ... den ich nicht gesehen habe . Danke !
Es geht um "TETRA Connectivity Server"
Die können sich pingen aber nicht ihre Dienste miteinander verbinden?
Die können sich pingen aber nicht ihre Dienste miteinander verbinden?
Ich bin kein Sophos Profi, aber Routen zusätzlich eintragen ist bei den Mikrotik und vermutlich bei den Sophos nicht zwingend nötig, weil man das im Phase 2 des IPSec mitgeben kann.
Das NAT ist grundsätzlich gewollt?
Auf Port 80 ist mein Webserver. Auf Port 3543 läuft was und werden dynamische Ports weiter oben aufgemacht und das klappt nicht?
Das NAT ist grundsätzlich gewollt?
Auf Port 80 ist mein Webserver. Auf Port 3543 läuft was und werden dynamische Ports weiter oben aufgemacht und das klappt nicht?
... es geht um einen sogn. TCS-Server ( von der Firma TCS - Türsprechkommunikation) . Nennt sich auch BCM-Server !
Um nicht jedes unserer remoten Gateways in den einzelnen Liegenschaften einzeln ansprechen zu müssen, gibt es einen Server. Der verwaltet halt alle unter einen Hut. Also z.B. Transponder dem richtigen Schloss zuzuordnen oder Namen an den Klingeltableau ändern.
Um nicht jedes unserer remoten Gateways in den einzelnen Liegenschaften einzeln ansprechen zu müssen, gibt es einen Server. Der verwaltet halt alle unter einen Hut. Also z.B. Transponder dem richtigen Schloss zuzuordnen oder Namen an den Klingeltableau ändern.
... der Port 3543 ist der Dst-Port ... und dient zum Abgleich mit dem Server !
Ich habe nur den Hinweis bekommen, dass Forward an diesen Port eingerichtet werden muss.
Ich habe nur den Hinweis bekommen, dass Forward an diesen Port eingerichtet werden muss.
Zitat von @IP-PUPPI:
... es geht um einen sogn. TCS-Server ( von der Firma TCS - Türsprechkommunikation) . Nennt sich auch BCM-Server !
Um nicht jedes unserer remoten Gateways in den einzelnen Liegenschaften einzeln ansprechen zu müssen, gibt es einen Server. Der verwaltet halt alle unter einen Hut. Also z.B. Transponder dem richtigen Schloss zuzuordnen oder Namen an den Klingeltableau ändern.
... es geht um einen sogn. TCS-Server ( von der Firma TCS - Türsprechkommunikation) . Nennt sich auch BCM-Server !
Um nicht jedes unserer remoten Gateways in den einzelnen Liegenschaften einzeln ansprechen zu müssen, gibt es einen Server. Der verwaltet halt alle unter einen Hut. Also z.B. Transponder dem richtigen Schloss zuzuordnen oder Namen an den Klingeltableau ändern.
Ist das Handbuch für die Anwendung online? Das hört sich nach einem Standardszenario an.
Mein Bauchgefühl sagt mir, es geht Richtung NAT, dynamische Ports usw, Firewall...
Ich weiß es aber nicht, kenne die Software nicht.
Es kann sein dass Port 3543 ein Steuerungsport ist, dann dynamische Ports geöffnet werden sollen und das scheitert.
Das kann sowohl am NAT liegen als auch an der Firewall.
Ich weiß es aber nicht, kenne die Software nicht.
Es kann sein dass Port 3543 ein Steuerungsport ist, dann dynamische Ports geöffnet werden sollen und das scheitert.
Das kann sowohl am NAT liegen als auch an der Firewall.
... die Software ist eine Eigenentwicklung von TCS, basiert auf Linux. In einem lokalen Netz überhaupt kein Thema .... läuft sofort. Selbst über eine Client to Host IPSEC-Verbindung (also mit Userdaten, einem Interface mit festerIP) funktioniert das. Ich vermute den Fehler auch wie du in der NAT bzw. Firewall. Leider kenn ich die Sophos nicht so gut.
... das Handbuch ist auf deutsch,... aber sagt nicht spezielles zum Datentransfer aus.
... das Handbuch ist auf deutsch,... aber sagt nicht spezielles zum Datentransfer aus.
Und für deine Standortverbindung soll überhaupt ein NAT arbeiten?
... NAT habe ich nur jetzt mit diesem Thema auf dem Tisch. Sonst benötige ich sie nicht !
Zitat von @IP-PUPPI:
... NAT habe ich nur jetzt mit diesem Thema auf dem Tisch. Sonst benötige ich sie nicht !
... NAT habe ich nur jetzt mit diesem Thema auf dem Tisch. Sonst benötige ich sie nicht !
Ist auch ungewöhnlich, seine Standorte nicht einfach zu routen.
Dann die Port-Themen auch vom Tisch und man kann die Firewall untersuchen.
... am Mikrotik Server habe ich Forward wie auch Input und Output passend zu den Netzen bzw. Interfacen erlaubt ...! Hab auch mal alle Filter ausgeschaltet ...
Bei der Sophos hab ich nicht so die Erfahrung. Aber die IPSEC-Filtergegeln sind vorhanden ... wurde ja bei der Konfiguration von Host to Host erzeugt und abgelegt.
Bei der Sophos hab ich nicht so die Erfahrung. Aber die IPSEC-Filtergegeln sind vorhanden ... wurde ja bei der Konfiguration von Host to Host erzeugt und abgelegt.
was könnte am Router-Switch (10.255.200.11/24) noch falsch sein,... den die IP´s von den Gateways sind ja in einem anderen Netz. Die haben ja eine 10.255.204.er IP und Netzanbindung !
Loggen doch Mal an beiden Routern den gesamten Traffic für alle Status.
Der Mikrotik kann dir zum Wireshark streamen. Für drauf, dass nur das Geschäft der beiden Hosts im Capturing ist und die Sophos hat bestimmt auch ein Export in ein Cap-format.
Dann kannst Du genau sehen, was passiert oder nicht oder geschlossen wird.
Der Mikrotik kann dir zum Wireshark streamen. Für drauf, dass nur das Geschäft der beiden Hosts im Capturing ist und die Sophos hat bestimmt auch ein Export in ein Cap-format.
Dann kannst Du genau sehen, was passiert oder nicht oder geschlossen wird.
Zitat von @IP-PUPPI:
was könnte am Router-Switch (10.255.200.11/24) noch falsch sein,... den die IP´s von den Gateways sind ja in einem anderen Netz. Die haben ja eine 10.255.204.er IP und Netzanbindung !
was könnte am Router-Switch (10.255.200.11/24) noch falsch sein,... den die IP´s von den Gateways sind ja in einem anderen Netz. Die haben ja eine 10.255.204.er IP und Netzanbindung !
Deshalb fragte ich ob das alles richtig ist.
Ich habe das so gelesen, dass die Switches "Router Switches" über die IPs im Bild gemanaged werden und noch weitere Netze routen
grundlegend habe ich noch an jeden RouterSwitch 2 weitere Netze für Heizungstechnik und Internet.
Die Interface nutzen den SwitchChip nicht ... also Hardware ist off. Die Routen sind alle fest und funktionieren auch.
Internet läuft über PPPOE ... also L2, und die Heizungstechnik nutzt Port 80 bzw 443.
Ich habe aber auch das schon ausgeschlossen. Denn selbst wenn ich den Gateway von TCS mit einer IP aus dem 10.255.200.er Netz versorge, komm ich nur auf das Webinterface ... aber der BCM-Server findet sie nicht !
Die Interface nutzen den SwitchChip nicht ... also Hardware ist off. Die Routen sind alle fest und funktionieren auch.
Internet läuft über PPPOE ... also L2, und die Heizungstechnik nutzt Port 80 bzw 443.
Ich habe aber auch das schon ausgeschlossen. Denn selbst wenn ich den Gateway von TCS mit einer IP aus dem 10.255.200.er Netz versorge, komm ich nur auf das Webinterface ... aber der BCM-Server findet sie nicht !
Zitat von @IP-PUPPI:
grundlegend habe ich noch an jeden RouterSwitch 2 weitere Netze für Heizungstechnik und Internet.
Die Interface nutzen den SwitchChip nicht ... also Hardware ist off. Die Routen sind alle fest und funktionieren auch.
Internet läuft über PPPOE ... also L2, und die Heizungstechnik nutzt Port 80 bzw 443.
Ich habe aber auch das schon ausgeschlossen. Denn selbst wenn ich den Gateway von TCS mit einer IP aus dem 10.255.200.er Netz versorge, komm ich nur auf das Webinterface ... aber der BCM-Server findet sie nicht !
grundlegend habe ich noch an jeden RouterSwitch 2 weitere Netze für Heizungstechnik und Internet.
Die Interface nutzen den SwitchChip nicht ... also Hardware ist off. Die Routen sind alle fest und funktionieren auch.
Internet läuft über PPPOE ... also L2, und die Heizungstechnik nutzt Port 80 bzw 443.
Ich habe aber auch das schon ausgeschlossen. Denn selbst wenn ich den Gateway von TCS mit einer IP aus dem 10.255.200.er Netz versorge, komm ich nur auf das Webinterface ... aber der BCM-Server findet sie nicht !
Ich habe keinen Zweifel dass das L2/L3 grundsätzlich funktioniert.
Wie gesagt, meine Vermutung kennst Du.
Viel mehr können wir ohne Detailkenntnisse nicht machen. Du scheinst das aber zu beherrschen. Nun empfehle ich nach dem Ausschlussprinzip großzügig Störschweine auszuschließen und zu sniffen.
... ich werde mal mit nen Switch an den BCM-Server gehen .Einen TCS-Gateway und über meinem PC das Ohr dran halten. Schein mir auf vernünftiger zu sein ... als zu viel zu suchen.
Danke erstmal für deine Zeit !
Danke erstmal für deine Zeit !
Ich habe in der Sophos-Firewall die Route zum Netz 10.255.204.0/24 an das Interface (Port2) mit der externen IP (erhalten über PPPOE) gelegt.
Das ist sinnfrei und auch kontraproduktiv, denn das macht IPsec über die SA Negotiation immer automatisch. Statische Routen sind da also überflüssig und führen eher zu Fehlern.Ebenso sind keinerlei NAT Regeln oder sowas erforderlich.
Du hast ja immer einen ganz einfachen Test: Wenn du in allen lokalen Netzen jeweils das Gegenüber pingen kannst hast du Infrastruktur technisch alles richtig gemacht.
Ein paar Fragen bleiben aber bei deinem Design:
- Auf der Mikrotik Seite hast du ja 2 lokale Subnetze .200.0 /24 und .204.0 /24 ! Hier ist vermutlich die Zeichnung fehlerhaft, denn die TCS Server hängen mit gleicher IP .204er IP Adresse jeweils in den unterschiedlichen IP Netzen, was so ja niemals sein kann !
- Daran schliesst sich die Frage an WIE diese beiden lokalen Subnetze im IPsec VPN bzw. dessen Phase 2 SAs definiert sind ?? Du hast ja hier die Option mit einem SA und entsprechend großer CIDR Maske zu arbeiten oder mit 2 separaten SAs pro Netzwerk.
Eine einzige P2 SA (Policy) CIDR Maske = 21 Bit (255.255.248.0) was dann die IP Netze 10.255.200.0 bis 10.255.207.254 inkludiert in den Tunnel.
Das wäre die einfachste und auch sinnvollste Konfig hier !
Option 2:
Zwei separate P2 SAs (Policy) mit der 24er Maske und separat für die Netze .200.0 und .204.0
Wenn du mit diesen 2 SAs auf dem Mikrotik gearbeitet hast musst du zwingend im IPsec Setup des MT in den Policies den Level auf "unique" (statt require) setzen.
Leider machst du in deinem Thread keinerlei Angaben wie das konfigtechnisch auf MT und Sophos umgesetzt ist bei dir. Die scheinbar falsche IP Adressierung in der ansonsten hilfreichen Skizze macht es da zusätzlich nicht einfacher für uns.
Eine Mikrotik IPsec Beispiel Basiskonfig für IPsec findest du zu Orientierung hier:
IPsec-Site2Site-Tunnel zwischen zwei MikroTik-Routern, beide MikroTik-Router hinter NAT
( Die davor kaskadierten Router kannst du dir natürlich wegdenken)
Hallo .... die Routen habe ich schon entfernt. Durch den Tunnel kennen beide die gegenüberliegenden Netze. Danke für die Info.
Zum Thema Option bzw. Optionen ...
Zum Thema Option bzw. Optionen ...
OK, das sieht gut aus ! 👍
IP technisch und VPN technisch ist dann alles korrekt und OK. Dann kann es nur noch an der Applikation selber liegen.
Kannst du in beiden remote Subnetzen und auch aus beiden diesen Netzen alle Endgeräte vom Gegenüber pingen und vice versa ? Gilt natürlich insbesondere für die TCS Server.
IP technisch und VPN technisch ist dann alles korrekt und OK. Dann kann es nur noch an der Applikation selber liegen.
Kannst du in beiden remote Subnetzen und auch aus beiden diesen Netzen alle Endgeräte vom Gegenüber pingen und vice versa ? Gilt natürlich insbesondere für die TCS Server.
... hier die Pinganfrage vom 192er -Netz an das 10er Netz ...
Beim Ping vom 10er Netz ins 192er antwortet der Gateway von meiner lokale WAN-IP !
Beim Ping vom 10er Netz ins 192er antwortet der Gateway von meiner lokale WAN-IP !
Beim Ping vom 10er Netz ins 192er antwortet der Gateway von meiner lokale WAN-IP !
Was ja nicht normal ist und zeigt das da grundsätzlich was schief läuft in die Richtig.Passiert das auch wenn wenn du das Ping Tool auf dem MT benutzt und dort unter "Advanced" dediziert als Absender IP die lokale MT LAN IP 10.255.204.x eingibst und das LAN Interface der Sophos pingst ? Ping (ICMP) natürlich im Sophos Setup vorher erlauben !
Alternativ etwas anderes ohne Firewall im 192.168.99er Netz pingen wie Drucker, Switch Management IP usw.
... wenn ich vom 10.255.204.1 das 192.168.99er anpinge, dann funktioniert das.
Aber vom 10.255.200er Netz aus nicht , da antwortet dann der Gateway vom der WAN-IP!
Da ich von beiden Seiten aus die ICMP-Pakte beantwortet bekomme, kann der Fehler nicht in der VPN zu finden sein.
Aber vom 10.255.200er Netz aus nicht , da antwortet dann der Gateway vom der WAN-IP!
Da ich von beiden Seiten aus die ICMP-Pakte beantwortet bekomme, kann der Fehler nicht in der VPN zu finden sein.
Hast du dieses Netz auch in den P2 SAs der Sophos eingetragen ? OK, müsste ja sonst wäre der Status nicht auf "established"...
Kann man dann nur vermuten das da irgendwo im Firewall Regelwerk etwas für dieses IP Netz nicht stimmt und Pakete geblockt werden.
In jedem Falle ist das ein Fehler und es wird da irgendwas geblockt wenn das Ping Ziel im .99er Netz etwas ohne lokale Firewall ist und dieses Ziel eine Gateway IP auf die 99er LAN IP der Sophos eingetragen hat !
Kann man dann nur vermuten das da irgendwo im Firewall Regelwerk etwas für dieses IP Netz nicht stimmt und Pakete geblockt werden.
Da ich von beiden Seiten aus die ICMP-Pakte beantwortet bekomme
Kommt drauf an... Theoretisch könnte die Firewall nach ICMP Typen filtern und Echo bzw. Echo Reply sind unterschedliche ICMP Types...In jedem Falle ist das ein Fehler und es wird da irgendwas geblockt wenn das Ping Ziel im .99er Netz etwas ohne lokale Firewall ist und dieses Ziel eine Gateway IP auf die 99er LAN IP der Sophos eingetragen hat !
... sind beide auch in der Sophos drin... s.Bild .
In der Firewall habe ich Filter ... die beziehen sich aber nur auf einen Input,... und kein Forward an diese Netze. Aber ich hatte auch mal für 30 sekunden alles deaktiviert. Trotzdem steht hier noch immer ... das. Siehe 2. Bild vom BCM-Server
In der Firewall habe ich Filter ... die beziehen sich aber nur auf einen Input,... und kein Forward an diese Netze. Aber ich hatte auch mal für 30 sekunden alles deaktiviert. Trotzdem steht hier noch immer ... das. Siehe 2. Bild vom BCM-Server
... kann der Fehler auch auf der Seite vom Radius -Servers bzw. dem Server liegen, der den Tunnel(PPPOE) aufgebaut hat und / oder dessen GW ... (also dem "WEG" nach draußen?) Also auf deutsch,... ein Filter der den Inhalt eines PPPOE-Tunnels durchsucht bzw. ändert?
Den Content in einem Tunnel und besonders einem VPN Tunnel kann ein Filter nicht lesen. Wenn dann kann das immer nur an Tunnelendpunkten passieren also den virtuellen PPPoE Interfaces oder VPN Interfaces.
Was komisch ist, ist die Tatsache das wenn du die Filter deaktivierst der Ping trotzdem nicht durchgeht...
Was komisch ist, ist die Tatsache das wenn du die Filter deaktivierst der Ping trotzdem nicht durchgeht...
