touro411
Goto Top

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:

s2s_fb_sophos

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

Content-Key: 322306

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

Ausgedruckt am: 28.03.2024 um 21:03 Uhr

Mitglied: MrSnow
MrSnow 28.11.2016 um 13:12:23 Uhr
Goto Top
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.
Mitglied: touro411
touro411 28.11.2016 um 13:16:46 Uhr
Goto Top
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..
Mitglied: aqui
aqui 28.11.2016 aktualisiert um 13:28:47 Uhr
Goto Top
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 face-sad
Mitglied: touro411
touro411 28.11.2016 um 13:40:04 Uhr
Goto Top
Wenn man dich oben richtig versteht terminieren ja die beiden FW die Tunnel und nicht die FB, richtig ?
Ja, genau

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

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?
Mitglied: aqui
aqui 28.11.2016 aktualisiert um 13:47:45 Uhr
Goto Top
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 face-wink
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 face-wink
Wie gesagt sinnvoller wären 2 simple einfache xDSL Modems statt den FBs.
Mitglied: touro411
touro411 28.11.2016 um 14:09:25 Uhr
Goto Top
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)
Mitglied: aqui
aqui 28.11.2016 um 14:42:08 Uhr
Goto Top
Dafür reicht auch ein simpler interner VoIP Adapter Cisco SPA 112 oder ne kleine Anlage wie die Auerswald 3000 VoIP... face-wink
Mitglied: touro411
touro411 28.11.2016, aktualisiert am 29.11.2016 um 08:27:51 Uhr
Goto Top
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.

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
standorta

Standort B
standortb

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?
Mitglied: aqui
aqui 29.11.2016 um 09:36:09 Uhr
Goto Top
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 !
Mitglied: touro411
touro411 29.11.2016 aktualisiert um 10:21:44 Uhr
Goto Top
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
Mitglied: aqui
aqui 29.11.2016 aktualisiert um 12:07:29 Uhr
Goto Top
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 ??
Mitglied: touro411
touro411 29.11.2016 aktualisiert um 12:21:13 Uhr
Goto Top
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 _CHOSEN
12: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
Mitglied: aqui
Lösung aqui 29.11.2016 aktualisiert um 12:30:22 Uhr
Goto Top
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.
Mitglied: touro411
touro411 29.11.2016 um 12:30:52 Uhr
Goto Top
Ja ich habe die Einstellungen ausgewählt:
ipfire_adv
ipsec_pol
Mitglied: aqui
aqui 29.11.2016 um 12:33:58 Uhr
Goto Top
Bleibt das Adressproblem...
Mitglied: touro411
touro411 29.11.2016 um 14:07:30 Uhr
Goto Top
geschafft, das VPN steht. die Lösung folgt natürlich...
Mitglied: aqui
aqui 29.11.2016 um 17:49:02 Uhr
Goto Top
Da sind wir aber mal gespannt...!!!
Mitglied: touro411
touro411 29.11.2016 um 19:18:32 Uhr
Goto Top
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:

ipsec_ip

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 ??

Das brachte mich auf den richtigen Pfad... Danke aqui face-smile
Mitglied: aqui
aqui 30.11.2016 um 09:57:48 Uhr
Goto Top
war die öffentliche IP eingetragen und nicht die WAN IP (Private IP Adresse) der IPFire
Oha...tödlich face-smile Kleine Ursache große Wirkung.... aber mit dem Log Auszug war das dann klar face-wink
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