androxin
Goto Top

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

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.

Content-ID: 437826

Url: https://administrator.de/forum/ipsec-site-to-site-zwischen-opnsense-und-routeros-mit-dynamischen-wan-ip-adressen-437826.html

Ausgedruckt am: 21.12.2024 um 16:12 Uhr

aqui
aqui 06.04.2019 um 12:43:34 Uhr
Goto Top
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 ?
Androxin
Androxin 06.04.2019 um 13:45:31 Uhr
Goto Top
Hey,
vielen Dank für den Link.
Dort ist bei der Policy-dst Address die feste IP des CISCO Routers eingetragen.
Die opnSense hat in meinem Fall aber auch eine dynamische IP, erreichbar über die dynDNS Domain vpn.büro.de.

Ja, die 172.... Adressen sind jeweils die lokalen Netzwerke.
aqui
aqui 06.04.2019 aktualisiert um 15:01:37 Uhr
Goto Top
Hier nochmal deine genauen ToDos:

back-to-topMikrotik:

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:
pfmt1
2.) Preshared Keys festlegen:
pfmt2
3.) Phase1 konfigurieren:
pfmt3
4.) Phase 2 Proposals konfigurieren:
pfmt4
5.) Peer Policy konfigurieren:
pfmt5
6.) Fertisch !
Hier kannst du sehen das der Tunnel sofort hochkommt. (Established)
pfmt6

back-to-toppfSense Firewall:

1.) Peers und Phase 1 konfigurieren:
pfmt8
pfmt9
3.) Phase 2 konfigurieren:
pfmt10
pfmt11
4.) Fertisch !:
Auch hier ist der Tunnel sofort aktiv:
pfmt12
Entsprechend auch die Anzeige im Dashboard der Firewall
pfmt7

Works as designed ! face-wink

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.
Androxin
Androxin 06.04.2019 um 15:09:35 Uhr
Goto Top
Tausend Dank, dass du dir die Mühe gemacht hast.

Trotzdem habe ich noch eine Frage dazu.

In dem Beispiel hat die pfSense die IP 10.99.1.99. Diese ist fest in der Policy aufm MikroTik eingetragen.

Wie kann ich das auf mein Beispiel übertragen? Ich habe schließlich keine (feste) IP, die ich dort eintragen könnte. Nur die Domain.

Das mit den Identifiern funktioniert bereits.
aqui
aqui 06.04.2019 um 15:16:33 Uhr
Goto Top
Du trägst dort dann natürlich einen FQDN Hostnamen ein. Musst du ja wenn die IP Adressen am WAN Port zyklisch wechseln.
Androxin
Androxin 06.04.2019 aktualisiert um 16:35:21 Uhr
Goto Top
Danke, dass du das noch einmal geschrieben hast.
So war eigentlich auch mein Plan.

Winbox macht mir da aber einen Strich durch die Rechnung:
unbenannt

MÜSSTE es eigentlich gehen und ich habe ggf. den Fehler an einer anderen Stelle gemacht?

Siehe auch hier:
https://forum.mikrotik.com/viewtopic.php?t=124502
areanod
areanod 06.04.2019 aktualisiert um 21:55:52 Uhr
Goto Top
Hello,

Beim Tik kannst du keinen FQDN eingeben weil... <hier gute Gründe einfügen> face-smile


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 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.
Androxin
Androxin 06.04.2019 um 22:01:05 Uhr
Goto Top
Nabend,

ich bin auf einem anderen Weg gerade (vermutlich) zum Erfolg gelangt:

In der IPsec Identity muss man unter "Generate Policy" den Eintrag "port strict" auswählen.
Dann wird die Policy automatisch mit den aktuellen IP Adressen angelegt.

Ob das wirklich des Rätsels Lösung ist, werde ich nachreichen. Momentan habe ich noch ein Problem bei der opnSense das "Remote Network" anzugeben. Es gibt in der Weboberfläche keine Eingabemöglichkeit... Daher funktioniert der Tunnel derzeit nur in eine Richtung.
Androxin
Androxin 06.04.2019 aktualisiert um 23:11:51 Uhr
Goto Top
Unglaublich, dass ich jetzt wirklich an der nächsten Stelle stecken geblieben bin.

Bei der bestehenden Phase 1 steht als Remote Peer "mobile client". Das ist richtig so. Glaube ich.
Allerdings gibt es in der Phase 2 keine Möglichkeit das Remote Netzwerk anzugeben.

Wenn ich eine komplett neue Phase 1 anlege, muss ich eine korrekte Remote Peer-IP Adresse angeben, die ich aber nicht habe.
Eigentlich müsste da 0.0.0.0 rein, richtig?

In der opnSense gibt's folgenden Fehler:

Apr 6 23:06:53 	charon: 09[IKE] <con1|556> failed to establish CHILD_SA, keeping IKE_SA
Apr 6 23:06:53 	charon: 09[IKE] <con1|556> configuration payload negotiation failed, no CHILD_SA built
Apr 6 23:06:53 	charon: 09[IKE] <con1|556> no virtual IP found, sending INTERNAL_ADDRESS_FAILURE
Apr 6 23:06:53 	charon: 09[IKE] <con1|556> no virtual IP found for %any requested by 'remote.de'  
Apr 6 23:06:53 	charon: 09[IKE] <con1|556> peer requested virtual IP %any
aqui
aqui 07.04.2019 aktualisiert um 17:53:13 Uhr
Goto Top
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....
Androxin
Androxin 10.04.2019 um 10:57:06 Uhr
Goto Top
Kurzer Zwischenstand:

Die Firmware der opnSense hat nicht nur bei OpenVPN, sondern auch, in meinem speziellen Anwendungsfall, bei IPSec einen Bug.
Die oben genannte Fehlermeldung bzgl. der virtuellen IP bezieht sich auf das "Mobile Client"-Szenario, sprich ein Client bekommt aus einem Pool eine IP Adresse zugewiesen.
In meinem Fall ist das aber vollkommen falsch, da ich einen normalen remote-peer (nur eben mit dynamischer Adresse) anbinde.
Ich werde die Kiste jetzt auf die derzeit aktuellste Firmware (19.1.5) aktualisieren und dann weiter sehen.


... und das alles nur, weil Mikrotik es nicht gebacken kriegt, endlich OpenVPN mit UDP zu implementieren. Ich könnte heulen. face-wink
aqui
aqui 10.04.2019 aktualisiert um 19:02:36 Uhr
Goto Top
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 ! face-wink
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 !!! face-wink
Wenn man damit alles richtig macht klappts auch wunderbar...