19
VPN Site to Site von IPFire zu Sophos UTM
Hallo,
ich habe vor ein Site to Site VPN zu erstellen von Standort A zu B.... siehe Schaubild:
Ich habe schon etliche Stunden getestet mit einem IPSec VPN, aber das klappte nicht vermutlich weil der Datenverkehr durch jeweils erste Lan durchgeschleust (doppeltes NAT) werden musste oder weil die Fritzbox den ESP Verkehr nicht geforwardet hat...
Möglichkeit A: Site to Site VPN mittels OpenVPN --> kann die Sophos nicht...
Möglichkeit B: Site to Site VPN mittels SSL (wo vermutlich OpenVPN dahinter stickt) --> kann das die IPFire??
Oder wie könnte ich das Ganze vllt. ganz anders lösen?
VG,
Touro411
ich habe vor ein Site to Site VPN zu erstellen von Standort A zu B.... siehe Schaubild:
Ich habe schon etliche Stunden getestet mit einem IPSec VPN, aber das klappte nicht vermutlich weil der Datenverkehr durch jeweils erste Lan durchgeschleust (doppeltes NAT) werden musste oder weil die Fritzbox den ESP Verkehr nicht geforwardet hat...
Möglichkeit A: Site to Site VPN mittels OpenVPN --> kann die Sophos nicht...
Möglichkeit B: Site to Site VPN mittels SSL (wo vermutlich OpenVPN dahinter stickt) --> kann das die IPFire??
Oder wie könnte ich das Ganze vllt. ganz anders lösen?
VG,
Touro411
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: 322306
Url: https://administrator.de/contentid/322306
Ausgedruckt am: 23.11.2024 um 05:11 Uhr
19 Kommentare
Neuester Kommentar
Hallo Rouro411,
eine ähnliche Konstellation habe ich bei einem Kunden auch. Sollte an den Fritten außer der Firewall nichts dranhängen per LAN / WLAN konfiguriere die ipFire und die Sophos als Exposed Host und richte zwischen beiden eine ipsec Verbindung ein.
eine ähnliche Konstellation habe ich bei einem Kunden auch. Sollte an den Fritten außer der Firewall nichts dranhängen per LAN / WLAN konfiguriere die ipFire und die Sophos als Exposed Host und richte zwischen beiden eine ipsec Verbindung ein.
OK, aber dann hat die externe Schnittstelle der Sophos/IPFire immernoch eine private IP und nicht die externe... Und direkt an der Fritzbox ist ja auch die Telefonie angeschlossen..
Dieses Tutorial beschreibt die wichtigsten Einstellungen:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
Das sollte analog auch alles für deine IPFire gelten !
Problem hier wie immer:
Die FritzBoxen machen ja selber IPsec als VPN Protokoll !! Daher leiten sie die IPsec Protokollkomponenten NICHT weiter auch wenn du sie per Port Forwarding entsprechend eingestellt hast.
Wenn man dich oben richtig versteht terminieren ja die beiden FW die Tunnel und nicht die FB, richtig ?
Sinnvoller wäre dann auch keine solchen gruseligen NAT Router Kaskaden zu machen wie du es hast sondern ein simples einfaches NUR DSL Modem ohne Router direkt an die Firewalls zu klemmen:
https://www.reichelt.de/WLAN-Router-Access-Point/ALLNET-ALL0333C/3/index ...
Das erspart dir den Performance Fresser Doppeltes NAT und würde dein o.a. Problem gar nicht erst auftauchen lassen !
Die relevanten IPsec Ports sind wie immer:
UDP 500
UDP 4500
ESP Protokoll (IP Nummer 50, (Achtung kein TCP oder UDP 50, ESP ist ein eigenes IP protokoll !)
Die 3 Komponenten musst du in den FBs auf die Firewall WAN Ports per Port Forwarding weiterreichen UND...
zusätzlich auch das IPsec auf der FB deaktivieren, das sie IPsec mit ihren Port Forwarding Settings weiterreicht !
Das hättest du auch selber sehr einfach ohne einen Thread checken können wenn du das mit einem Wireshark Sniffer mal auf der jeweiligen Seite verifiziert hättest mit einem Trace ob dort IPsec ankommt
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
Das sollte analog auch alles für deine IPFire gelten !
Problem hier wie immer:
Die FritzBoxen machen ja selber IPsec als VPN Protokoll !! Daher leiten sie die IPsec Protokollkomponenten NICHT weiter auch wenn du sie per Port Forwarding entsprechend eingestellt hast.
Wenn man dich oben richtig versteht terminieren ja die beiden FW die Tunnel und nicht die FB, richtig ?
Sinnvoller wäre dann auch keine solchen gruseligen NAT Router Kaskaden zu machen wie du es hast sondern ein simples einfaches NUR DSL Modem ohne Router direkt an die Firewalls zu klemmen:
https://www.reichelt.de/WLAN-Router-Access-Point/ALLNET-ALL0333C/3/index ...
Das erspart dir den Performance Fresser Doppeltes NAT und würde dein o.a. Problem gar nicht erst auftauchen lassen !
Die relevanten IPsec Ports sind wie immer:
UDP 500
UDP 4500
ESP Protokoll (IP Nummer 50, (Achtung kein TCP oder UDP 50, ESP ist ein eigenes IP protokoll !)
Die 3 Komponenten musst du in den FBs auf die Firewall WAN Ports per Port Forwarding weiterreichen UND...
zusätzlich auch das IPsec auf der FB deaktivieren, das sie IPsec mit ihren Port Forwarding Settings weiterreicht !
Das hättest du auch selber sehr einfach ohne einen Thread checken können wenn du das mit einem Wireshark Sniffer mal auf der jeweiligen Seite verifiziert hättest mit einem Trace ob dort IPsec ankommt
Wenn man dich oben richtig versteht terminieren ja die beiden FW die Tunnel und nicht die FB, richtig ?
Ja, genauDas hättest du auch selber sehr einfach ohne einen Thread checken können wenn du das mit einem Wireshark Sniffer mal auf der jeweiligen Seite
verifiziert hättest mit einem Trace ob dort IPsec ankommt
verifiziert hättest mit einem Trace ob dort IPsec ankommt
Also z.B. ein Notebook mit Whireshark an die FB schließen und die besagten Ports an das Notebook weiterleiten und schauen ob die PAkete ankommen?
Ja, ganz genau !
Mach es aber nicht so umständlich sondern gebe dem Wireshark Rechner einfach die gleiche IP Adresse wie die am Firewall WAN Port.
Die FW klemmst du dann während des Messens mal kurz ab.
Das erleichtert den Test und du musst nicht mit unterschiedlichen IPs im Port Forwarding rumfrickeln und misst zudem so wie es nachher auch Live sein soll
Auf alle Fälle ist das lösbar auch mit dem umständlichen doppelten NAT und PFW auf der FB. man muss nur IPsec deaktivieren
Wie gesagt sinnvoller wären 2 simple einfache xDSL Modems statt den FBs.
Mach es aber nicht so umständlich sondern gebe dem Wireshark Rechner einfach die gleiche IP Adresse wie die am Firewall WAN Port.
Die FW klemmst du dann während des Messens mal kurz ab.
Das erleichtert den Test und du musst nicht mit unterschiedlichen IPs im Port Forwarding rumfrickeln und misst zudem so wie es nachher auch Live sein soll
Auf alle Fälle ist das lösbar auch mit dem umständlichen doppelten NAT und PFW auf der FB. man muss nur IPsec deaktivieren
Wie gesagt sinnvoller wären 2 simple einfache xDSL Modems statt den FBs.
Auf alle Fälle ist das lösbar auch mit dem umständlichen doppelten NAT und PFW auf der FB. man muss nur IPsec deaktivieren
IpSec auf der FB deaktivieren, in dem ich alle IPsec Profile auf der FB löschen?Wie gesagt sinnvoller wären 2 simple einfache xDSL Modems statt den FBs.
Ja definitiv! Aber an der FB hängt auch die Telefonie (Fax, Telefone)
Dafür reicht auch ein simpler interner VoIP Adapter Cisco SPA 112 oder ne kleine Anlage wie die Auerswald 3000 VoIP...
Der Test mit Wireshark ist beendet... Wie befürchtet kommt nur UDP Port 500 an, ESP und UDP Port 4500 nicht.
Ei<nmal getestet mit diesen 3 Portforward Regeln und einmal mit Exposed Host --> kein Erfolg.
Ei<nmal getestet mit diesen 3 Portforward Regeln und einmal mit Exposed Host --> kein Erfolg.
Trotzdem habe ich es geschaft eine VPN verbindung mit IPSec aufzubauen, zwar nicht von Ipfire zu Sophos, aber einer Sophos mit Modem (WAN mit öff. IP) und einer Sophos (Wan mit priv. IP)
Standort A
Standort B
Nun müsste ich die Einstellungen von Standort A auf die IPFire tranferieren, das hat leider noch nicht geklappt. Arbeitet die Sophos mit IKE v1 oder v2?
Das ist erstmal egal. Wenn sie aktuellste Firmware hat sollte es eigentlich v2 sein.
Wichtig ist das du hier ESP durchbekommst. Das ist oft der Knackpunkt, da viele billige Baumarkt Router das nicht können weil es in der PFW Konfig schlicht und einfach fehlt.
Die FritzBox kann es aber ganz sicher.
Wie gesagt aber nur wenn man ihre eigenen VPN Funktionen deaktiviert. Das ist wichtig sonst leitet sie die IPsec Protokollkomponenten nicht weiter.
Das UDP 4500 trotz Port Forwarding nicht durchkommt kann normal sein !
UDP 4500 ist NAT Traversal (ESP Encapsulation in UDP)
Es ist sehr gut möglich das in deinen Endgeräten im IPsec Setup vergessen wurde NAT Traversal zu aktivieren.
Das wäre in deinem Szenario natürlich tödlich, denn damit werden die Probleme noch größer NAT mit IPsec zu überwinden. Aktiviere das also.
Check das also vorher ob das in deinen Setups auf BEIDEN Seiten NAT-T aktiviert ist !
Wichtig ist das du hier ESP durchbekommst. Das ist oft der Knackpunkt, da viele billige Baumarkt Router das nicht können weil es in der PFW Konfig schlicht und einfach fehlt.
Die FritzBox kann es aber ganz sicher.
Wie gesagt aber nur wenn man ihre eigenen VPN Funktionen deaktiviert. Das ist wichtig sonst leitet sie die IPsec Protokollkomponenten nicht weiter.
Das UDP 4500 trotz Port Forwarding nicht durchkommt kann normal sein !
UDP 4500 ist NAT Traversal (ESP Encapsulation in UDP)
Es ist sehr gut möglich das in deinen Endgeräten im IPsec Setup vergessen wurde NAT Traversal zu aktivieren.
Das wäre in deinem Szenario natürlich tödlich, denn damit werden die Probleme noch größer NAT mit IPsec zu überwinden. Aktiviere das also.
Check das also vorher ob das in deinen Setups auf BEIDEN Seiten NAT-T aktiviert ist !
Das ist erstmal egal. Wenn sie aktuellste Firmware hat sollte es eigentlich v2 sein.
Es ist v1: Starting IKEv1 pluto daemon (log von Sophos)including NAT-Traversal patch
Dann habe ich die 2 Zeilen in den Logs gefunden:
2016:11:29-09:58:49 pluto[25748]: ERROR: "VPN Connection" #1: sendto on eth0 to ext_ip_ipfire:500 failed in main_outI1. Errno 1: Operation not permitted
2016:11:29-09:58:59 pluto[25748]: packet from ext_ip_ipfire:500: ignoring informational payload, type NO_PROPOSAL_CHOSEN
Ich stelle mir noch die Frage: welche Option soll ich in der Sophos verwenden? Initiate Connection oder Respond only
Oha...wer dann noch Sophos UTMs einsetzt ist selber Schuld.
Aber egal...das ist erstmal nicht die Ursache.
NO_PROPOSAL_CHOSEN bedeutet das die vorgeschlagenen Crypto Suites der Phase 1 zwischen beiden Geräten nicht identisch sind oder es nichts gibt was auf beiden Seiten gleich ist und worauf die sich im Handshaking einigen können ?
Was hast du da eingestellt ? AES 128 und SHA 1 plus 3DES und SHA1 und evtl. noch AES 256 und SHA1 sollte eigentlich immer klappen. Hast du diese 3 Suites aktiv beidseitig ?
Vermutlich nicht...
Klar auch wenn die gruselige Sophos nur IKEv1 kann die andere Seite das auch supporten muss !
Was sagt das Logging auf der IPFire Seite ??
Aber egal...das ist erstmal nicht die Ursache.
NO_PROPOSAL_CHOSEN bedeutet das die vorgeschlagenen Crypto Suites der Phase 1 zwischen beiden Geräten nicht identisch sind oder es nichts gibt was auf beiden Seiten gleich ist und worauf die sich im Handshaking einigen können ?
Was hast du da eingestellt ? AES 128 und SHA 1 plus 3DES und SHA1 und evtl. noch AES 256 und SHA1 sollte eigentlich immer klappen. Hast du diese 3 Suites aktiv beidseitig ?
Vermutlich nicht...
Klar auch wenn die gruselige Sophos nur IKEv1 kann die andere Seite das auch supporten muss !
Was sagt das Logging auf der IPFire Seite ??
Was sagt das Logging auf der IPFire Seite ??
12:17:21 charon: 14[IKE] no IKE config found for priv. IP WAN IPFire...öff IP Standort B, sending NO_PROPOSAL _CHOSEN12:17:21 charon: 14[ENC] parsed ID_PROT request 0 [ SA V V V V V V V V V ]
12:17:21 charon: 14[NET] received packet: from öff IP Standort B[500] to priv. IP WAN IPFire[500] (256 bytes)
12:17:08 charon: 04[NET] error writing to socket: Invalid argument
12:17:08 charon: 05[NET] sending packet: from öff IP Standort A[500] to öff IP Standort B[500] (380 bytes)
12:17:08 charon: 05[IKE] sending retransmit 3 of request message ID 0, seq 1
12:16:55 charon: 04[NET] error writing to socket: Invalid argument
12:16:55 charon: 05[NET] sending packet: from öff IP Standort A[500] to öff IP Standort B[500] (380 bytes)
12:16:55 charon: 05[IKE] sending retransmit 2 of request message ID 0, seq 1
12:16:48 charon: 04[NET] error writing to socket: Invalid argument
12:16:48 charon: 14[NET] sending packet: from öff IP Standort A[500] to öff IP Standort B[500] (380 bytes)
12:16:48 charon: 14[IKE] sending retransmit 1 of request message ID 0, seq 1
12:16:45 charon: 04[NET] error writing to socket: Invalid argument
12:16:45 charon: 15[NET] sending packet: from öff IP Standort A[500] to öff IP Standort B[500] (380 bytes)
12:16:45 charon: 15[ENC] generating ID_PROT request 0 [ SA V V V V V V ]
12:16:45 charon: 15[IKE] initiating Main Mode IKE_SA Test2[19] to öff IP Standort B
12:16:44 charon: 15[IKE] initiating Main Mode IKE_SA Test2[19] to öff IP Standort B
Da hat die IPFire wohl ein generelles Problem. Laut Fehlermeldung hat sie keinerlei Crypto Suite konfiguriert.
Kann das sein das du die im Setup nicht ausgewählt hast ??
IKE Proposals (UDP 500) von der anderen Seite kommen ja an. Das PFW der FB davor scheint also zu klappen.
Was auch komisch ist:
sending packet: from öff IP Standort A[500] to öff IP Standort B[500] (380 bytes)
Wie bitte ist es möglich das die IPFire Pakete mit der öff. IP von A als Absender IP sendet ??
Technisch eigentlich unmöglich und daher rühren vermutlich auch die Socket Errors.
Da stimmt irgendwas grundsätzlich was an der IPFire IP Konfig nicht....sieht wenigstens so aus.
Kann das sein das du die im Setup nicht ausgewählt hast ??
IKE Proposals (UDP 500) von der anderen Seite kommen ja an. Das PFW der FB davor scheint also zu klappen.
Was auch komisch ist:
sending packet: from öff IP Standort A[500] to öff IP Standort B[500] (380 bytes)
Wie bitte ist es möglich das die IPFire Pakete mit der öff. IP von A als Absender IP sendet ??
Technisch eigentlich unmöglich und daher rühren vermutlich auch die Socket Errors.
Da stimmt irgendwas grundsätzlich was an der IPFire IP Konfig nicht....sieht wenigstens so aus.
Ja ich habe die Einstellungen ausgewählt:
Bleibt das Adressproblem...
geschafft, das VPN steht. die Lösung folgt natürlich...
Da sind wir aber mal gespannt...!!!
Bleibt das Adressproblem...
das war auch das Problem in der IPfire die vor der Fritzbox angeschlossen ist, war die öffentliche IP eingetragen und nicht die WAN IP (Private IP Adresse) der IPFire:
sending packet: from öff IP Standort A[500] to öff IP Standort B[500] (380 bytes)
Wie bitte ist es möglich das die IPFire Pakete mit der öff. IP von A als Absender IP sendet ??
Wie bitte ist es möglich das die IPFire Pakete mit der öff. IP von A als Absender IP sendet ??
Das brachte mich auf den richtigen Pfad... Danke aqui
war die öffentliche IP eingetragen und nicht die WAN IP (Private IP Adresse) der IPFire
Oha...tödlich Kleine Ursache große Wirkung.... aber mit dem Log Auszug war das dann klar Gutes Beispiel um mal wieder in Erinnerung zu bringen wie wichtig Logs sind zum Troubleshooten...
Könnte man ja dann fast sogar noch in das IPsec Praxistutorial übernehmen, da fehlt die IPFire noch:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
