dr.bit
Goto Top

Securepoint RC200 per S2S VPN mit Sophos UTM 9 verbinden

Moin Leute,

hat schon jemand von Euch eine Securepoint RC200 über einen Site to Site Tunnel mit einer Sophos UTM 9 verbinden können? Und wenn wie?

Also: Securepoint als Firewall im Firmennetzwerk mit 30 Arbeitsplätzen, Druckern, IP Telefonen usw.. Sophos als Firewall im Heimnetzwerk mit 2 Arbeitsplätzen, Druckern, IP Telefonen usw.
Es soll von der Firma aus gedruckt werden können, auf den Server im Heimnetzwerk zugegriffen werden können und umgekehrt. Die Heimtelefonanlage soll zusätzlich als Unteranlage der Firmenanlage konfiguriert werden.
Roadwarrior kann man deswegen ausschließen. Die Roadwarrior Rechner, die wir draußen haben funktionieren übrigens einwandfrei und auch IP Telefone außerhalb der Firma funktionieren. Mein Problem ist, daß die Verbindung zwischen den Firewalls nicht zu Stande kommt. Die sehen sich und versuchen auch sich zu verbinden klappt aber nicht. Mit einer Fritzbox wird wenigstens die Verbindung aufgebaut und initiiert, schön, soll aber nicht face-sad .
Da es mit der Fritte funtioniert, muß es wohl an der Sophos liegen ich weiß aber nicht wo.

Das sagt die Sophos:

2019:11:19-16:59:10 firewall pluto[40966]: listening for IKE messages
2019:11:19-16:59:10 firewall pluto[40966]: added connection description "S_KWB IPSec"
2019:11:19-16:59:10 firewall pluto[40966]: "S_KWB IPSec" #1: initiating Main Mode
2019:11:19-16:59:10 firewall pluto[40966]: added connection description "S_KWB IPSec"
2019:11:19-16:59:10 firewall pluto[40966]: "S_KWB IPSec" #1: received Vendor ID payload [XAUTH]
2019:11:19-16:59:10 firewall pluto[40966]: "S_KWB IPSec" #1: received Vendor ID payload [Dead Peer Detection]
2019:11:19-16:59:10 firewall pluto[40966]: "S_KWB IPSec" #1: received Vendor ID payload [RFC 3947]
2019:11:19-16:59:10 firewall pluto[40966]: "S_KWB IPSec" #1: enabling possible NAT-traversal with method 3
2019:11:19-16:59:11 firewall pluto[40966]: "S_KWB IPSec" #1: NAT-Traversal: Result using RFC 3947: no NAT detected
2019:11:19-16:59:11 firewall pluto[40966]: "S_KWB IPSec" #1: ignoring informational payload, type AUTHENTICATION_FAILED

AUTHENTICATION_FAILED ist mir schon klar, aber wo? PSK ist bei Beiden gleich.
Allerdings ist mir schleierhaft, wo die Sophos XAUTH und DPD her hat. Ist auf der Securepoint beides deaktiviert und wird laut Anleitung auch icht benötigt.

So langsam grrrr.

Gruß
Stephan

Content-Key: 516699

Url: https://administrator.de/contentid/516699

Ausgedruckt am: 19.03.2024 um 05:03 Uhr

Mitglied: aqui
aqui 19.11.2019 aktualisiert um 18:27:45 Uhr
Goto Top
AUTHENTICATION_FAILED ist mir schon klar, aber wo? PSK ist bei Beiden gleich
Vermutlich bedeutet "#1" die Phase 1, sprich der IPsec Tunnelaufbau scheitert schon dort.
Das hat zu 90% meist den Grund das die auszuhandelnden Schlüsselprotokolle nicht übereinstimmen. Eine Seite kann nur 3DES und die andere nur AES128 usw. DH Group Mismatch ist auch ein Punkt, der eine kann nur 2 der andere will aber 14. Dann scheitert schon die Phase 1.
Du solltest also folgende Dinge mal ganz genau ansehen:
  • Der IPsec Mode sollte auf agressive eingestellt sein auf beiden Seiten da du 2 unterschiedliche Hersteller hast. Den "Main" Mode solltest du meiden. (Kann man nacher umschalten sofern mit Agressive alles sauber rennt.)
  • Checke auf beiden Seiten das dort die gleichen Schlüsselprotokolle mind. 3DES, AES128, AES256 mit SHA1 oder SHA256 sollte mindestens auf beiden Seiten aushandelbar sein. Viele alte Implementationen können oder wollen nur 3DES.
  • DH Groups müssen ebenfalls identisch sein auf beiden Seiten. 2 (1024Bit) oder 14 (2048Bit)
  • Auch der Identifier muss identisch sein. Entweder die WAN IP (üblich wenn man feste, statische öffentliche IPs hat) oder eben ein String bei dynamischen IPs.
Diese 3 Punkte machen 80% aus. Hilfreich wäre auch mal das Log aus der Securepoint.
Grundlagen dazu auch hier:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
Cisco, Mikrotik, pfSense VPN Standort Vernetzung mit dynamischem Routing
Mitglied: Dr.Bit
Dr.Bit 20.11.2019 um 09:40:05 Uhr
Goto Top
#1 denke ich auch

auf beiden Seiten
ikev1
Verschlüsselung: 3des
Authentifizierung md5
DHG modp1024
IPSec mode gibt es bei der Securepoint nicht. Hier gibt es Strict ich denke mal es ist das Selbe und ist aktiviert.
IKE Lifetime 1h, hier was zu ändern bringt auch nix.

Sobald ich an der Konfiguration der Securepoint etwas ändere ( egal was ) wird es mir auch sofort im LOG der Sophos angezeigt. Es kommt eben nur kein Tunnel zustande.

Was ich eben auch nicht verstehe, ist daß die Sophos von der Securepoint gemeldet bekommt, das DPD und XAUTH aktiviert sind.
Die beiden Links hatte ich schon durchgearbeitet.
Bin ja nicht erst seit gestern drann face-smile

Mich wundert eben, das es mit der Fritte funktioniert.
Mitglied: Dr.Bit
Dr.Bit 20.11.2019 um 09:47:52 Uhr
Goto Top
Achso: #1 gibt nur an, der wievielte Versuch es seit Neustart des Dienstes ist.
im Moment bin ich bei #378
Mitglied: jenni
jenni 20.11.2019 um 11:38:23 Uhr
Goto Top
Bin da voll bei Aqui!

Wie viele Tunnel hast du denn am Laufen?
hatte das gleich Problem mit ner Pfsense und einem VPN Router. Der Tunnel über IPSec wollte einfach nicht zu stande kommen. Nach FirmwareUpdate ging es.
Mitglied: aqui
aqui 20.11.2019 um 12:41:52 Uhr
Goto Top
Verschlüsselung: 3des, Authentifizierung md5
Oha, das ist ja uralt und MD5 gilt heute nicht mehr als sicher, ebensoweing 3DES. Das solltest du nicht mehr verwenden wenn möglich. !
Die FritzBox nutzt AES. Das hegt sich dann doch der Verdacht das es ein Schlüssel Mismatch ist.
Mitglied: Dr.Bit
Dr.Bit 20.11.2019 um 13:36:59 Uhr
Goto Top
@aqui
Hab ich auch gedacht.

umgestellt auf
aes128 sha2_256 modp2048
Genau das Gleiche.

Der Fritte habe ich in der conf. allerdings vorgegeben, das sie 3des nutzen soll. Geht auch einwandfrei.

@jenni

Roadwarrior sind 4 draußen. IPSec keiner. Klappt ja nicht. Da die Roadwarrior allerdings auch über kurz oder lang neue und mehr Geräte bekommen und z.T. schon haben, hat das natürlich keine Zeit mehr und muß vorgestern erledigt sein. Und wehe da sind noch "Kinderkrankheiten". Chef eben face-smile
Mitglied: Dr.Bit
Dr.Bit 20.11.2019 um 19:35:52 Uhr
Goto Top
Update:

weil ich ja nix besseres zu tun habe, habe ich nochmal eine pfSense aufgesetzt. Genau das Gleiche. Ich werde das Gefühl nicht los, daß die Securepoint nicht wirklich mit den Firewalls will. Ich werde am WE mal eine Sophos in der Firma aufsetzen und testen. Mal sehen.
Das LOG von der SP sagt nämlich nur aus, daß die einkommende Verbindung geprüft wird und die entsprechende IKE gesucht wird. Als nächstes kommt die Meldung, daß sie gefunden wurde und das war´s. Weiter macht die SP nichts.
Mitglied: aqui
aqui 21.11.2019 aktualisiert um 13:50:32 Uhr
Goto Top
habe ich nochmal eine pfSense aufgesetzt. Genau das Gleiche.
Es hätte hier allen sehr geholfen wenn du mal den Tunnel Verbindungsaufbau im pfSense Log (IPsec) hier gepostet hättest face-sad
Dort steht meist sehr genau woran es genau scheitert.
Das Log der SP wäre trotzdem interessant auch wenn es nichtssagend ist.

Helfen würde auch wenn du die Settings der pfSense für die Phase 1 und Phase 2 hier mal als Screenshot posten würdest.
Ebenso die der SP. Irgendwo hast du ganz sicher einen Konfig Fehler. Das Log der pfSense wäre essentiell.
Wie sollen wir dir denn zielführend helfen wenn man dir alles immer einzelnd aus der Nase ziehen muss. Das macht nicht wirklich Spaß face-sad Sowas kann man doch auch gleich mit anhängen !
Mitglied: Dr.Bit
Dr.Bit 21.11.2019 um 16:06:10 Uhr
Goto Top
Da hast Du natürlich Recht. Es ist allerdings nicht so einfach immer alles parat zu haben, wenn die Standorte so weit auseinander sind und Copy and Paste nicht über den Teamviewer rüber will.
Wie dem auch sei - es läuft!!! face-smile face-smile face-smile
Ich habe alles einmal neu eingerichtet und das Einzige was ich anders gemacht habe ist, und da muß man auch erst einmal drauf komme, ich habe die Verbindungen auf beiden Seiten gleich benannt. Also den lokalen Namen für die Verbindung auf beiden Firewalls.
Mir erschließt sich überhaupt nicht, warum die gleich sein müssen.

TrotzdemDanke für Eure Mühen. face-smile
Mitglied: aqui
aqui 22.11.2019 aktualisiert um 16:42:51 Uhr
Goto Top
Mir erschließt sich überhaupt nicht, warum die gleich sein müssen.
Müssen sie auch nicht !! Im Gegenteil...
Man muss wenn man im Identifier mit Strings arbeitet statt mit IPs, wie es bei dir scheinbar der Fall ist, immer auf der einen Seite den Namen des remoten Identifiers eintragen und auf der anderen Seite den des einen.
Also jede Seite muss immer sein Gegenüber "kennen". In der Regel sind die Identifier unterschiedlich.
Vermutlich hast du das durcheinander gebracht und jetzt da beide gleich sind kann es keinen Mismatch mehr geben face-wink
Wenns nun klappt ist ja alles gut... Case closed !

Bitte dann auch
Wie kann ich einen Beitrag auf "gelöst" oder "erledigt" setzen?
nicht vergessen !
Mitglied: Dr.Bit
Dr.Bit 24.11.2019 um 16:50:52 Uhr
Goto Top
Da hast Du mich falsch verstanden.
Das die Namen der Verbindung ( die dyndns Namen ) auf beiden Seiten verschieden sein müssen, also der Eine auf den Anderen zeigt und umgekehrt versteht sich von selbst.
Nein die lokalen, ich nenne sie mal Dateinamen, auf den verschiedenen Firewalls sind gleich. Und damit klappt es dann. Wenn ich den Verbindungsnamen auf der Sophos oder Securepoint umbenenne fällt die Verbindung wieder aus.

Egal, funktioniert! Alles gut! Schönes WE noch.