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
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 322306
Url: https://administrator.de/forum/vpn-site-to-site-von-ipfire-zu-sophos-utm-322306.html
Ausgedruckt am: 23.12.2024 um 12:12 Uhr
19 Kommentare
Neuester Kommentar
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
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.
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 !
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 ??
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.
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