gelöst 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 .
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
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 .
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
11 Antworten
- LÖSUNG aqui schreibt am 19.11.2019 um 18:24:38 Uhr
- LÖSUNG almera schreibt am 20.11.2019 um 09:40:05 Uhr
- LÖSUNG almera schreibt am 20.11.2019 um 09:47:52 Uhr
- LÖSUNG jenni schreibt am 20.11.2019 um 11:38:23 Uhr
- LÖSUNG aqui schreibt am 20.11.2019 um 12:41:52 Uhr
- LÖSUNG almera schreibt am 20.11.2019 um 13:36:59 Uhr
- LÖSUNG almera schreibt am 20.11.2019 um 19:35:52 Uhr
- LÖSUNG aqui schreibt am 21.11.2019 um 13:49:52 Uhr
- LÖSUNG almera schreibt am 21.11.2019 um 16:06:10 Uhr
- LÖSUNG aqui schreibt am 22.11.2019 um 16:41:51 Uhr
- LÖSUNG almera schreibt am 24.11.2019 um 16:50:52 Uhr
- LÖSUNG aqui schreibt am 22.11.2019 um 16:41:51 Uhr
- LÖSUNG almera schreibt am 21.11.2019 um 16:06:10 Uhr
- LÖSUNG aqui schreibt am 21.11.2019 um 13:49:52 Uhr
- LÖSUNG almera schreibt am 20.11.2019 um 19:35:52 Uhr
- LÖSUNG almera schreibt am 20.11.2019 um 13:36:59 Uhr
- LÖSUNG aqui schreibt am 20.11.2019 um 12:41:52 Uhr
- LÖSUNG jenni schreibt am 20.11.2019 um 11:38:23 Uhr
- LÖSUNG almera schreibt am 20.11.2019 um 09:47:52 Uhr
- LÖSUNG almera schreibt am 20.11.2019 um 09:40:05 Uhr
LÖSUNG 19.11.2019, aktualisiert um 18:27 Uhr
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.
Grundlagen dazu auch hier:
https://administrator.de/wissen/ipsec-vpn-praxis-standort-kopplung-cisco ...
https://administrator.de/wissen/cisco-mikrotik-vpn-standort-vernetzung-d ...
LÖSUNG 20.11.2019 um 09:40 Uhr
#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
Mich wundert eben, das es mit der Fritte funktioniert.
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
Mich wundert eben, das es mit der Fritte funktioniert.
LÖSUNG 20.11.2019 um 09:47 Uhr
Achso: #1 gibt nur an, der wievielte Versuch es seit Neustart des Dienstes ist.
im Moment bin ich bei #378
im Moment bin ich bei #378
LÖSUNG 20.11.2019 um 11:38 Uhr
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.
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.
LÖSUNG 20.11.2019 um 12:41 Uhr
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.
LÖSUNG 20.11.2019 um 13:36 Uhr
@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
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
LÖSUNG 20.11.2019 um 19:35 Uhr
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.
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.
LÖSUNG 21.11.2019, aktualisiert um 13:50 Uhr
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 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ß Sowas kann man doch auch gleich mit anhängen !
LÖSUNG 21.11.2019 um 16:06 Uhr
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!!!
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.
Wie dem auch sei - es läuft!!!
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.
LÖSUNG 22.11.2019, aktualisiert um 16:42 Uhr
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
Wenns nun klappt ist ja alles gut... Case closed !
Bitte dann auch
https://administrator.de/faq/32
nicht vergessen !
LÖSUNG 24.11.2019 um 16:50 Uhr
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.
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.
Ähnliche Inhalte
Neue Wissensbeiträge
Heiß diskutierte Inhalte
