IPSec Site to Site zwischen opnSense und RouterOS mit dynamischen WAN-IP Adressen
Moin, moin.
Ich versuche, inzwischen verzweifelt, eine Site to Site VPN Verbindung zwischen dem fiktiven "Büro" (opnSense, dyndns: vpn.büro.de; 172.17.3.0/24) und einem MikroTik LTE Router (Dynamische IP Adresse; 172.18.1.0/24), herzustellen.
Phase 1 funktioniert bereits.
In der opnSense ist folgendes konfiguriert:
- Anschlussart: standard
- Schlüsselaustauschversion: v2
- Internet Protokoll: IPv4
- Schnittstelle: eth0WAN
- Authentifizierungsmethode: Mutual PSK
- Meine Kennung: "Bedeutender Name" (vpn.büro.de)
- Verschlüsselungsalgorithmus: 3DES
- Hashalgorithmus: SHA1
- DH Schlüsselgruppe: 2
- Lebenszeit: 28800
- NAT Traversal: Aktivieren
Bei der Phase 2 wirds langsam schwieriger, eigentlich sollte die aber auch noch funktionieren:
In der opnSense ist folgendes konfiguriert:
- Modus: Tunnel IPv4
- Lokales Netzwerk Typ: Netzwerk
- Adresse: 172.17.3.0/24
- Phrase 2 Protokoll: ESP
- Verschlüsselungsalgorithmen: AES (automatisch), ... 3DES, ...
- Hashalgorithmen: SHA1, SHA256, SHA512
- PFS Schlüsselgruppe: aus
- Lebenszeit 3600
Dann kommt noch die "Mobile Clients" Konfiguration auf der opnSense dazu. Von der bin ich mir nicht sicher, ob das so richtig ist:
- Virtueller Addresspool: "Den Clients eine virtuelle IP-Adresse zur Verfügung stellen": 192.168.181.0/28
- Netzwerkliste: Ja
Soweit so gut. Über das LOG auf dem MikroTik kann man gut nachvollziehen, dass Phase 1 und Phase 2 korrekt aufgebaut werden. Das "Büro" ist auch als Remote Peer verbunden. In der opnSense sieht man, dass meinem IPSec Benutzer die Host-IP 192.168.181.1 zugewiesen wurde.
Vermutlich fehlt jetzt noch die korrekte Konfiguration der Policy auf dem MikroTik Router. Korrekt?
Reiter General:
Src. Address: 172.18.1.0/24
Dst. Address: 172.17.3.0/24
Reiter Action:
- Action: encrypt
- Level: require
- IPsec Protocols: esp
- Tunnel: ja
- SA Src. Address: Was muss ich hier angeben?
- SA Dst. Address: Was muss ich hier angeben?
Hat jemand einen Tipp für mich?
Nachtrag: Natürlich habe ich mich auch durch diverse Tutorials gearbeitet.
Allerdings weicht das Aussehen der aktuellen RouterOS Version deutlich von den in den Tutorials verwendeten Version ab, so dass es schwer ist die Beispiele zu adaptieren.
Ich versuche, inzwischen verzweifelt, eine Site to Site VPN Verbindung zwischen dem fiktiven "Büro" (opnSense, dyndns: vpn.büro.de; 172.17.3.0/24) und einem MikroTik LTE Router (Dynamische IP Adresse; 172.18.1.0/24), herzustellen.
Phase 1 funktioniert bereits.
In der opnSense ist folgendes konfiguriert:
- Anschlussart: standard
- Schlüsselaustauschversion: v2
- Internet Protokoll: IPv4
- Schnittstelle: eth0WAN
- Authentifizierungsmethode: Mutual PSK
- Meine Kennung: "Bedeutender Name" (vpn.büro.de)
- Verschlüsselungsalgorithmus: 3DES
- Hashalgorithmus: SHA1
- DH Schlüsselgruppe: 2
- Lebenszeit: 28800
- NAT Traversal: Aktivieren
Bei der Phase 2 wirds langsam schwieriger, eigentlich sollte die aber auch noch funktionieren:
In der opnSense ist folgendes konfiguriert:
- Modus: Tunnel IPv4
- Lokales Netzwerk Typ: Netzwerk
- Adresse: 172.17.3.0/24
- Phrase 2 Protokoll: ESP
- Verschlüsselungsalgorithmen: AES (automatisch), ... 3DES, ...
- Hashalgorithmen: SHA1, SHA256, SHA512
- PFS Schlüsselgruppe: aus
- Lebenszeit 3600
Dann kommt noch die "Mobile Clients" Konfiguration auf der opnSense dazu. Von der bin ich mir nicht sicher, ob das so richtig ist:
- Virtueller Addresspool: "Den Clients eine virtuelle IP-Adresse zur Verfügung stellen": 192.168.181.0/28
- Netzwerkliste: Ja
Soweit so gut. Über das LOG auf dem MikroTik kann man gut nachvollziehen, dass Phase 1 und Phase 2 korrekt aufgebaut werden. Das "Büro" ist auch als Remote Peer verbunden. In der opnSense sieht man, dass meinem IPSec Benutzer die Host-IP 192.168.181.1 zugewiesen wurde.
Vermutlich fehlt jetzt noch die korrekte Konfiguration der Policy auf dem MikroTik Router. Korrekt?
Reiter General:
Src. Address: 172.18.1.0/24
Dst. Address: 172.17.3.0/24
Reiter Action:
- Action: encrypt
- Level: require
- IPsec Protocols: esp
- Tunnel: ja
- SA Src. Address: Was muss ich hier angeben?
- SA Dst. Address: Was muss ich hier angeben?
Hat jemand einen Tipp für mich?
Nachtrag: Natürlich habe ich mich auch durch diverse Tutorials gearbeitet.
Allerdings weicht das Aussehen der aktuellen RouterOS Version deutlich von den in den Tutorials verwendeten Version ab, so dass es schwer ist die Beispiele zu adaptieren.
Please also mark the comments that contributed to the solution of the article
Content-ID: 437826
Url: https://administrator.de/contentid/437826
Printed on: December 3, 2024 at 05:12 o'clock
12 Comments
Latest comment
Nicht in diesem Tutorial:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
Halte dich daran, dann klappt das auch !
Die 172er Adressen sind das die der jeweils lokalen LANs ?
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
Halte dich daran, dann klappt das auch !
Die 172er Adressen sind das die der jeweils lokalen LANs ?
Hier nochmal deine genauen ToDos:
IKEv2 zur Sicherheit verwenden.
10.1.1.149 = Test WAN IP Mikrotik
10.99.1.99 = Test WAN IP pfSense
1.) Peers konfigurieren:
2.) Preshared Keys festlegen:
3.) Phase1 konfigurieren:
4.) Phase 2 Proposals konfigurieren:
5.) Peer Policy konfigurieren:
6.) Fertisch !
Hier kannst du sehen das der Tunnel sofort hochkommt. (Established)
3.) Phase 2 konfigurieren:
4.) Fertisch !:
Auch hier ist der Tunnel sofort aktiv:
Entsprechend auch die Anzeige im Dashboard der Firewall
Works as designed !
Wenn du eine dynmaische IP verwendest musst du als "my identifier" und "peer identifier" (pfSense) bzw. "my id type" und "remote id type" (Mikrotik) den Hostnamen nehmen oder auch einen fiktiven String wie die Email usw.
Wichtig ist das diese Identifier auf beiden Seiten gleich sind.
Mikrotik:
Verwendete Konfig ==> Default Konfig mit NAT Firewall auf eth1 und Ports eth2-5 als Bridge zum lokalen LAN (ggf. anpassen)IKEv2 zur Sicherheit verwenden.
10.1.1.149 = Test WAN IP Mikrotik
10.99.1.99 = Test WAN IP pfSense
1.) Peers konfigurieren:
2.) Preshared Keys festlegen:
3.) Phase1 konfigurieren:
4.) Phase 2 Proposals konfigurieren:
5.) Peer Policy konfigurieren:
6.) Fertisch !
Hier kannst du sehen das der Tunnel sofort hochkommt. (Established)
pfSense Firewall:
1.) Peers und Phase 1 konfigurieren:3.) Phase 2 konfigurieren:
4.) Fertisch !:
Auch hier ist der Tunnel sofort aktiv:
Entsprechend auch die Anzeige im Dashboard der Firewall
Works as designed !
Wenn du eine dynmaische IP verwendest musst du als "my identifier" und "peer identifier" (pfSense) bzw. "my id type" und "remote id type" (Mikrotik) den Hostnamen nehmen oder auch einen fiktiven String wie die Email usw.
Wichtig ist das diese Identifier auf beiden Seiten gleich sind.
Hello,
Beim Tik kannst du keinen FQDN eingeben weil... <hier gute Gründe einfügen>
Glücklicherweise hat ROS ein wirklich großartige (wenn auch manchmal zickige) Skript-Sprache.
Ich würde folgendes Skript empfehlen zumindest beim Startup vom Tik auszuführen, sinnvoller jedoch mittels Scheduler in bestimmten Abständen :
Beim Anlegen der Policy gibst du für die SA Dst Adress entweder irgendeinen fiktiven Wert (z.B: 1.1.1.1) oder die aktuelle IP der Gegenseite ein.
Es ist hier anzumerken, dass die Aktualisierung des Wertes nur für neue Verbindungsversuche gilt, d.h. wenn der Tik gerade versucht Verbindung aufzubauen und das Skript ändert die DST-SA, dann muss der aktuelle Verbindungsversuch erst beendet oder abgebrochen werden damit ein neuer Versuch mit den geänderten Werten erfolgt.
Man könnte theoretisch auch folgendes Skript anwenden um die Phasen 2 am Tik neu zu initalisieren, es kann bei einer bestehenden Verbindung jedoch zu Unterbrechungen kommen, speziell wenn du starke Verschlüsselung einsetzt:
lG
NACHTRAG:
Vergiss was ich oben geschrieben habe und setze dir einen Scheduler, der jede Stunde laufen soll:
Zeile 1: Es wird verglichen ob vpn.buero.de und die eingetragene IP Adresse in SA-DST-ADDR gleich sind, das Script soll DO ausführen wenn die Antwort NEIN / false ist.
Zeile 2: Die neue IP Adresse von vpn.buero.de wird in der Policy als SA-DST-ADR eingetragen
Zeile 3: Alle aktuellen IPSec Tunnel werden geflushed (=alle Verbindungen werden gelöscht) und werden dann neu aufgebaut.
Vorsicht wenn am Tik mehr als nur ein IPSEC Tunnel konfiguriert ist, da werden dann nämlich alle beendet und neu aufgebaut.
Beim Tik kannst du keinen FQDN eingeben weil... <hier gute Gründe einfügen>
Glücklicherweise hat ROS ein wirklich großartige (wenn auch manchmal zickige) Skript-Sprache.
Ich würde folgendes Skript empfehlen zumindest beim Startup vom Tik auszuführen, sinnvoller jedoch mittels Scheduler in bestimmten Abständen :
{ /ip ipsec policy set sa-dst-address=[:resolve vpn.buero.de] numbers=[/ip ipsec policy find where dst-address~"172.17.3.0/24"]
Beim Anlegen der Policy gibst du für die SA Dst Adress entweder irgendeinen fiktiven Wert (z.B: 1.1.1.1) oder die aktuelle IP der Gegenseite ein.
Es ist hier anzumerken, dass die Aktualisierung des Wertes nur für neue Verbindungsversuche gilt, d.h. wenn der Tik gerade versucht Verbindung aufzubauen und das Skript ändert die DST-SA, dann muss der aktuelle Verbindungsversuch erst beendet oder abgebrochen werden damit ein neuer Versuch mit den geänderten Werten erfolgt.
Man könnte theoretisch auch folgendes Skript anwenden um die Phasen 2 am Tik neu zu initalisieren, es kann bei einer bestehenden Verbindung jedoch zu Unterbrechungen kommen, speziell wenn du starke Verschlüsselung einsetzt:
{
/ip ipsec policy set sa-dst-address=[:resolve vpn.buero.de] numbers=[/ip ipsec policy find where dst-address~"172.17.3.0/24"]
/ip ipsec installed-sa flush
lG
NACHTRAG:
Vergiss was ich oben geschrieben habe und setze dir einen Scheduler, der jede Stunde laufen soll:
if (!([:resolve vpn.buero.de] = [/ip ipsec policy get number=[/ip ipsec policy find where dst-address~"172.17.3.0/24"] sa-dst-address])) do={
/ip ipsec policy set sa-dst-address=[:resolve vpn.buero.de] numbers=[/ip ipsec policy find where dst-address~"172.17.3.0/24"];
/ip ipsec installed-sa flush}
Zeile 2: Die neue IP Adresse von vpn.buero.de wird in der Policy als SA-DST-ADR eingetragen
Zeile 3: Alle aktuellen IPSec Tunnel werden geflushed (=alle Verbindungen werden gelöscht) und werden dann neu aufgebaut.
Vorsicht wenn am Tik mehr als nur ein IPSEC Tunnel konfiguriert ist, da werden dann nämlich alle beendet und neu aufgebaut.
Das sollte für eine Lösung helfen:
https://www.marthur.com/networking/mikrotik-script-no-ip-com-ddns-update ...
https://forum.mikrotik.com/viewtopic.php?t=125244
http://alsacecom.fr/blog/2012/05/24/mikrotik-routeros-site-to-site-conf ...
oder auch gut erklärt hier:
http://www.devcows.com/blog/create-an-ipsec-tunnel-between-2-mikrotik-r ...
oder, sofern deine MTs hinter NAT Router liegen (Kaskade) auch hier:
https://blog.pessoft.com/2016/05/29/mikrotik-ipsec-tunnel-with-ddns-and- ...
Hier ist besonders Update 2 und Update 3 interessant, da sie die Option bieten das doch mit FQDNs zu machen. Die aktuelle Firmware scheint da neue Optionen zu haben. Mal testen....
https://www.marthur.com/networking/mikrotik-script-no-ip-com-ddns-update ...
https://forum.mikrotik.com/viewtopic.php?t=125244
http://alsacecom.fr/blog/2012/05/24/mikrotik-routeros-site-to-site-conf ...
oder auch gut erklärt hier:
http://www.devcows.com/blog/create-an-ipsec-tunnel-between-2-mikrotik-r ...
oder, sofern deine MTs hinter NAT Router liegen (Kaskade) auch hier:
https://blog.pessoft.com/2016/05/29/mikrotik-ipsec-tunnel-with-ddns-and- ...
Hier ist besonders Update 2 und Update 3 interessant, da sie die Option bieten das doch mit FQDNs zu machen. Die aktuelle Firmware scheint da neue Optionen zu haben. Mal testen....
sondern auch, in meinem speziellen Anwendungsfall, bei IPSec einen Bug.
Warum nimmst du dann nicht pfSense ?? Wäre ja sinnvoller, denn von der Stabilität und Featureset sind die meilenweit voraus.In meinem Fall ist das aber vollkommen falsch, da ich einen normalen remote-peer anbinde.
Dann nimmt man ja logischerweise auch einen Remote Peer in der Konfig und keine Mobile Client Konfig ! Ich werde die Kiste jetzt auf die derzeit aktuellste Firmware (19.1.5) aktualisieren
Besser nicht und lieber pfSense latest nehmen !.. und das alles nur, weil Mikrotik es nicht gebacken kriegt, endlich OpenVPN mit UDP zu implementieren.
Na ja, dann machst du halt TCP wenn du so auf OVPN fixiert bist. Ist zwar mehr Overhead und frisst Performance aber geht zur Not auch.Aber es gibt ja glücklicherweise noch IPsec !!!
Wenn man damit alles richtig macht klappts auch wunderbar...