IPSec / Gesicherter Paketaustausch über unsichere Netzwerke

Manual:IP/IPsec


Manual: IPsec gesicherter Paketaustausch über unsichere Netzwerke

version

Gültig für RouterOS: v6.0 +

Inhalt

  • 1 Zusammenfassung
  • 2 Authentifizierungs-Header (AH)
    • 2.1 Transport Modus
    • 2.2 Tunnel Modus
  • 3 Encapsulating Security Payload
    • 3.1 Transport Modus
    • 3.2 Tunnel Modus
    • 3.3 Verschlüsselungs-Algorithmus
    • 3.4 Hardware-Verschlüsselung
      • 3.4.1 RB1100AHx2 Optimierung der Konfiguration
      • 3.4.2 HEXv3 (mmips) Optimierung der Konfiguration
  • 4 Internet Schlüssel-Austausch-Protokoll
    • 4.1 Diffie-Hellman Groups
    • 4.2 IKE Traffic
    • 4.3 Setup Prozess
  • 5 Mode Config
  • 6 XAuth Nutzer
  • 7 Peer Konfiguration
  • 8 Schlüssel
  • 9 Policy
    • 9.1 Policy Stats
  • 10 Policy Groups
  • 11 Proposal Einstellungen
  • 12 Manual SA
  • 13 Installierte SA
    • 13.1 Flushing SAs
  • 14 Remote Peers
    • 14.1 Alle IPsec Verbindungen schließen
  • 15 Statistiken
  • 16 Anwendungsbeispiele
    • 16.1 Einfache, PSK xAuth ähnliche Konfiguration
    • 16.2 Road Warrior Setup mit Mode Conf
      • 16.2.1 IPSec Server Konfiguration
      • 16.2.2 Apple iOS (iPhone/iPad) Client
      • 16.2.3 Android Client Hinweise
      • 16.2.4 RouterOS Client Konfiguration
      • 16.2.5 Shrew Client Konfiguration
    • 16.3 Road Warrior Setup mit Ikev2 RSA Authentifikation

      • 16.3.1 Ikev2 Server Setup
      • 16.3.2 RouterOS Client Konfiguration
      • 16.3.3 Windows Client Konfiguration
      • 16.3.4 Android Client Hinweise
    • 16.4 Road Warrior Setup mit Ikev1 RSA Authentifikation
      • 16.4.1 Zertifikate erstellen
      • 16.4.2 IPsec Server Konfiguration
      • 16.4.3 IPsec Client Konfiguration
      • 16.4.4 CRL Testen
      • 16.5 Seite-zu-Seite IPsec Tunnel
        • 16.5.1 IP Verbindungen
        • 16.5.2 IPsec Peer’s Konfiguration
        • 16.5.3 Policy und Proposal
        • 16.5.4 NAT und Fasttrack Bypass
      • 16.6 IPsec/L2TP hinter NAT
        • 16.6.1 IP Verbindungen
        • 16.6.2 L2TP Konfiguration
        • 16.6.3 IpSec Konfiguration
        • 16.6.4 Apple iOS (iPhone/iPad) Client
      • 16.7 Nur mit IPsec verkapselten Datenverkehr erlauben
        • 16.7.1 IPsec Policy Matcher
        • 16.7.2 Generische IPsec Policy nutzen
    • 16.8 Mit Shrew Client verbinden und nur verschlüsselten Datenverkehr erlauben
  • 17 Troubleshooting

1 Zusammenfassung

Sub-menu: /ip ipsec
Benötigtes Package: security
Standards: RFC 4301

Internet Protocol Security (IPsec) ist ein Set von Protokollen, welche von der Internet Engineering Task Force (IETF) definiert wurden, um den Datenpaketaustausch über ungesicherte IP/IPv6 Netzwerke, wie z.B. das Internet, abzusichern.
Das IPsec Protokoll kann in folgende Gruppen unterteilt werden:

  • Authentication Header (AH) RFC 4302
  • Encapsulating Security Payload (ESP) RFC 4303
  • Internet Key Exchange (IKE) Protokolle. Kryptographische Schlüssel für AH und ESP werden dynamisch generiert und verteilt.

2 Authentifikations-Header (AH)

AH ist ein Protokoll, welches die Authentifikation eines Teils oder des ganzen Inhalts eines Datagramm anbietet, indem ein Header hinzugefügt wird, der auf Grundlage der in dem Datagramm enthaltenen Werten berechnet wird. Welche Teile des Datagramms für die Berechnung verwendet werden und wo der Header platziert wird hängt vom verwendeten Tunnel und dem genutzten Transport-Modus ab.
Die Präsenz des AH Headers erlaubt die Integrität der Nachricht zu verifizieren aber verschlüsselt diese nicht. Deshalb gilt, dass AH Authentifikation aber keine Privatsphäre bietet. Ein anderes Protokoll (ESP) gilt hier als überlegen, da es Datenschutz und eine eigene Authentifikationsmethode bietet.
RouterOS unterstützt die folgenden Authentifikations-Algorithmen für AH:

  • SHA1
  • MD5

2.1 Transport Modus

Im Transport Modus wird der AH Header nach dem IP Header eingefügt. IP Daten und Header werden benutzt, um den Authentifikations-Wert zu berechnen. Die Werte von IP Feldern, die sich während der Durchreise ändern können, wie z.B. die Anzahl der TTL oder Hops, werden vor der Authentifikation auf Null gesetzt.

2.2 Tunnel Modus

Im Tunnel Modus werden die Original IP Pakete in neuen IP Paketen gekapselt wobei alle Original IP Pakete authentifiziert sind.

3 Eingekapselter Security Payload (ESP)

Encapsulating Security Payload (ESP) nutzt geteilte Schlüssel-Verschlüsselung um Datenschutz anzubieten. ESP unterstützt außerdem sein eigenes Authentifikations-Schema, wie es bei AH genutzt wird, oder kann in Verbindung mit AH verwendet werden.

Hinweis: Nutzt man AH und ESP zusammen bietet dies zwar eine doppelte Authentifikation, bedeutet aber auch zusätzliche Last für die CPU und bringt parallel keinen signifikanten Sicherheitsvorteile. Vorgeschlagen wird hier die Nutzung von ESP.

ESP verpackt seine Felder in einer ganzen anderen Art und Weise wie bei AH. Anstatt nur eines Headers, wird dieses Feld in drei Komponenten unterteilt:

  • ESP Header – Wird vor die verschlüsselten Daten gesetzt und seine Platzierung hängt davon ab, ob ESP im Transport oder Tunnel Modus genutzt wird.
  • ESP Trailer – Diese Komponente wird hinter die verschlüsselten Daten gesetzt. Es beinhaltet Füllmaterial, welches benötigt wird, um die verschlüsselten Daten anzugleichen.
  • ESP Authentication Data – Dieses Feld beinhaltet einen Integritäts-Prüf-Wert (Integrity Check Value – ICV), welcher auf ähnliche Art errechnet wird, wie das AH Protokoll arbeitet, wenn die optionale ESP Authentifikations-Funktion genutzt wird.

3.1 Transport Modus

Im Transport-Modus wird der ESP Header nach dem Original IP Header eingefügt. Der ESP Trailer und der Authentifikations-Wert werdem dem Ende des Pakets hinzugefügt. In diesem Modus  ist der IP Payload verschlüsselt und authentifiziert, der IP Header ist hingegen nicht abgesichert.

3.2 Tunnel Modus

Im Tunnel Modus ist das Original IP Paket in einem neuen IP Paket verkapselt, was wiederum IP Payload und IP Header absichert.

3.3 Verschlüsselungs-Algorithmus

RouterOS ESP unterstützt verschiedene Verschlüsselungs- und Authentifikations-Algorithmen.

Authentifikation:

  • SHA1
  • MD5

Verschlüsselung:

  • DES – 56-Bit DES-CBC Verschlüsselungs-Algorithmus;
  • 3DES – 168-Bit DES Verschlüsselungs-Algorithmus;
  • AES – 128, 192 and 256-Bit Schlüssel AES-CBC Verschlüsselungs-Algorithmus;
  • Blowfish – Hinzugefügt seit v4.5
  • Twofish – Hinzugefügt seit v4.5
  • Camellia – 128, 192 und 256-Bit Schlüssel Camellia Verschlüsselungs-Algorithmus hinzugefügt seit v4.5

3.4 Hardware-Verschlüsselung

Die Hardware-Beschleunigung erlaubt es, die Zeitspannen von Verschlüsselungsprozessen zu verkürzen, indem die in die CPU integrierte Verschlüsselungs-Engine genutzt wird. AES-CBC und sha1/sha256 sind die einzigen Algorithmen, die diese Funktion nutzen können, alle anderen werden Software-seitig bearbeitet.

Liste der RouterBoards die diese Funktion bereitstellen:

  • RB1000
  • RB1100AHx2
  • Alle RouterBOARDs der CloudCoureRouter-Serie
  • RB850Gx2
  • Hex v3

Zum Vergleich kann das RB1000 mit dieser Möglichkeit der Hardware-Unterstützung bis zu 550Mbit/s an verschlüsseltem Datenverkehr verarbeiten. Wenn man hier nun die Hardware-Unterstützung deaktiviert, sinkt dieser Wert an weitergeleiteten, verschlüsselten Daten, im AES-128 Modus auf 150Mbit/s.

3.4.1 RB1100AHx2 Optimierung der Konfiguration

Im folgenden ein paar Konfigurations-Hinweise, wie man auf einem RB1100AHx2 das Maximum an IPsec Durchsatz erreicht:

  • Es sollte vermieden werden die Ports ether12 und ether13 zu nutzen, da diese über den PCI-X Bus-Standard an den Chipsatz des Prozessor verbunden und hier somit die langsamsten Schnittstellen sind.
  • Die schnellste Weiterleitung erfolgt hier von den Switch Chip Ports (ether1-ether10) zu ether11 (direkt mit der CPU verbunden) und anders herum.
  • Die Hardware Queue ist auf allen Interfaces gesetzt
/queue interface set [find] queue=only-hardware-queue
  • RPS deaktivieren:
/system resource irq rps disable [find]
  • Man weist einen CPU Kern ether11 zu und einen anderen CPU Kern allem anderen. Weiterleiten über ether11 benötigt mehr CPU Leistung, weswegen man diesem Interface explizit einen CPU Kern alleine zuweist (in den IRQ Einstellungen ist ether11 als ether12 tx, rx und Fehler gelistet).
/system resource irq
set [find] cpu=1
set [find users="eth12 tx"] cpu=0
set [find users="eth12 rx"] cpu=0
set [find users="eth12 error"] cpu=0
  • connection tracking deaktivieren

Mit all den oben genannten Empfehlungen ist es möglich, 820Mbit/s zu verarbeiten (1470Byte Pakete auf zwei Streams).

Mit aktiviertem connection tracking 700MBit/s (1470Byte Pakete auf zwei Streams).

3.4.2 HEXv3 (mmips) Optimierung der Konfiguration

Das Hex v3 oder auch RB750Gr3 nutzt die MediaTek MT7621 CPU welche über einen integrierten Hardware Paket-Prozessor verfügt. Dies erlaubt es RouterOS den IPsec Datenverkehr auf bis zu 470Mbit/s zu erhöhen. Die Hardware-Beschleunigung wird für die folgenden Algorithmen genutzt: 128,192,256-bit aes-cbc; sha1,sha256.

Um die beste Performanz zu erhalten, müssen diese zwei einfachen Regeln eingehalten werden:

  • Paket-Fragmentation muss vermieden werden. avoid packet fragmentation;
  • Die Pakete dürfen nicht neu geordnet werden

Paket-Fragmentierung über den Tunnel kann vermieden werden, wenn die gesendeten Pakete in 1500Bytes passen, nachdem IPsec und andere verkapselnde Protokolle ihre Header hinzugefügt haben. Die Größe der IPsec Header kommen auf den genutzten Tunnel/Transport Modus, sowie den genutzten Verschlüsselungs-Algorithmus an. Mit reinem IPsec im Tunnel Modus ist es möglich, gefahrlos Pakete mit einer Größe von 1400Bytes zu senden. Um der Fragmentierung von TCP Datenverkehr vorzubeugen sollte die change-mss Regel hinzugefügt werden, um TCP MSS von 1400-40=auf 1360Bytes zu ändern. Im folgenden mangle manual ist ein Beispiel vorzufinden.

Um den maximalen IPsec Durchsatz zu demonstrieren, mit welchem das Hex v3 umgehen kann, dient das folgende einfache Seite-zu-Seite Setup. Für weitere Infos über diese Art von Setup ist hier ein Beispiel zu finden. Zwei mit 36 CPU Kernen versehe CCR Router werden hierbei benutzt, um Datenverkehr von einer zur anderen Seite zu erzeugen.
ipsec-hex-hw-setup

Die IPSec Konfiguration auf den HEX ist recht einfach:

# Hex 1
/ip address add address=1.1.1.1/24 interface=ether3
/ip address add address=2.2.2.1/24 interface=ether2
/ip route add dst-address=3.3.3.0/24 gateway=1.1.1.2

/ip ipsec {
  peer add remote-address=1.1.1.2 secret=xxx
  proposal set default enc-algorithms=aes-128-cbc
  policy add src-address=2.2.2.0/24 dst-address=3.3.3.0/24 \
    sa-src-address=1.1.1.1 sa-dst-address=1.1.1.2 tunnel=yes
}

# Hex 2
/ip address add address=1.1.1.2/24 interface=ether3
/ip address add address=3.3.3.1/24 interface=ether2
/ip route add dst-address=2.2.2.0/24 gateway=1.1.1.1

/ip ipsec {
  peer add remote-address=1.1.1.1 secret=xxx
  proposal set default enc-algorithms=aes-128-cbc
  policy add src-address=3.3.3.0/24 dst-address=2.2.2.0/24 \
    sa-src-address=1.1.1.2 sa-dst-address=1.1.1.1 tunnel=yes
}

Als nächstes führt man ein Setup des Traffic-Generators auf den CCR Routern durch:

# CCR 1
/ip address add address=2.2.2.2/24 interface=ether1
/ip route add dst-address=3.3.3.0/24 gateway=2.2.2.1

/tool traffic-generator set measure-out-of-order=yes
/tool traffic-generator packet-template
  add ip-src=2.2.2.2 ip-dst=3.3.3.2 ip-gateway=2.2.2.1

#CCR 2
/ip address add address=3.3.3.2/24 interface=ether1
/ip route add dst-address=2.2.2.0/24 gateway=3.3.3.1

/tool traffic-generator set measure-out-of-order=yes
/tool traffic-generator packet-template
  add ip-src=3.3.3.2 ip-dst=2.2.2.2 ip-gateway=3.3.3.1

Zu beachten ist, dass das measure-out-of-order aktiviert wurde, was einem anzeigt, wie viele neu geordnete Pakete erscheinen, wenn diese vom IPsec Hardware Treiber verarbeitet werden.

Wenn das Setup erfolgt ist, lässt man den Daten-Generator in beiden Richtungen laufen:

ipsec-hex-hw-aes128

ipsec-hex-hw-aes128-cpu

Wie man auf den obigen Screenshots ersehen kann, ist das Maximum, was der Verschlüsselungs-Kern verarbeiten kann, ungefähr 450MBit/s, bei einer Paketgröße von 1400Bytes. Auf Interface ether3 sieht man den kompletten, verarbeiteten Datenverkehr, mit hinzugefügtem IPsec Header, welcher bei annähernd 500Mbit/s liegt. Die CPU Last liegt annähernd bei 50%, was im Umkehrschluss bedeutet, dass IPsec am Maximum betrieben werden kann und immer noch Ressourcen für andere Aufgaben, wie z.B Firewall oder Queues frei sind.

Nun wechselt man auf maximale Sicherheits-Einstellungen, welche aktuell vom Hardware-Verschlüsselungs-CPU-Kern unterstützt werden.

/ip ipsec proposal set default enc-algorithms=aes-256-cbc auth-algorithms=sha256

ipsec-hex-hw-aes256-sha256-cpu

Die hier ersichtlichen Resultate zeigen, dass es zwar ein bisschen langsamer ist, aber die Datentransferrate immernoch bei anständigen 302Mbit/s bei einer Paketgröße von 1400Bytes liegen.

4 Internet Schlüssel-Austausch-Protokoll

Das Internet Key Exchange (IKE) ist ein Protokoll, welches authentifizierte Schlüssel-Material für das Internet Security Association and Key Management Protocol (ISAKMP) Framework zur Verfügung stellt. Es gibt auch andere Schlüssel-Austausch-System welche mit ISAKMP, aber IKE ist das meistgenutzte. Gemeinsam stellen sie Mittel für die Authentifizierung von Hosts und die automatische Verwaltung von Security Associations (SA) zur Verfügung.

Die meiste Zeit macht der IKE Dämon jedoch nichts, es gibt aber zwei mögliche Situationen damit dieser aktiviert wird:

Wenn Datenverkehr auf eine Policy Regel passt, welcher verschlüsselt oder authentifiziert werden müsste, aber die Policy über keine SAs verfügt, dann benachrichtigt die Policy den IKE Dämon darüber und der IKE Dämon initiiert die Verbindung zum Remote Host. Der IKE Dämon reagiert auf die Remote-Verbindung. In beiden Fällen stellt der Peer die Verbindung her und führt Phase2 aus.

  • Phase 1 – Die Peers verständigen sich auf einen Algorithmus, den sie bei den IKE Nachrichten verwenden werden und authentifizieren dann. Das Schlüssel-Material, aus welchen sich die Schlüssel für alle SAs ableiten und welche den folgenden ISAKMP Austausch zwischen den Hosts absichern, wird ebenso generiert. Diese Phase   welche The peers agree upon algorithms they will use in the following IKE messages and authenticate. The keying material used to derive keys for all SAs and to protect following ISAKMP exchanges between hosts is generated also. Dieser Phase sollte den folgenden Einstellungen entsprechen:
    • Authentifikations-Methode
    • DH Gruppe
    • Verschlüsselungs-Algorithmus
    • Austausch-Modus
    • Hash Algorithmus
    • NAT-T
    • DPD und Gültigkeitsdauer (optional)
  • Phase 2 – Die Peers legen eine oder mehrere SAs her, welche von IPsec genutzt werden, um Daten zu verschlüsseln. Alle vom IKE Dämon hergestellten SAs sind in Ihrer Gültigkeit zeitlich begrenzt (entweder sind sie zeitlich begrenzt und danach werden die SA ungültig oder aber die Datenmenge, die von der SA verschlüsselt werden kann ist begrenzt, oder beides). Diese Phase sollte den folgenden Einstellungen entsprechen:
    • IPsec Protokoll
    • Modus (Tunnel oder Transport)
    • Authentifikations-Methode
    • PFS (DH) Gruppe
    • Gültigkeitsdauer

Hinweis: Es gibt zwei Werte für die Gültigkeitsdauer – Soft und Hard. Wenn eine SA beginnt das Ende Ihrer Gültigkeitsdauer zu erreiche (=Soft) erhält der IKE Dämon einen Hinweis und startet eine andere Phase2, um die SA gegen eine neue auszutauschen. reaches it’s soft lifetime treshold, the IKE daemon receives a notice and starts another phase 2 exchange to replace this SA with fresh one. Wenn die SA das Ende der Gültigkeitsdauer erreicht (=Hard) wird diese verworfen.

Warnung: Phase 1 wird nicht neu verschlüsselt, wenn DPD inaktiv ist und währenddessen die Gültigkeitsdauer ausläuft. Nur Phase 2 wird neu verschlüsselt. Um die Neuverschlüsselung von Phase 1 zu erzwingen, sollte man DPD aktivieren.

IKE kann optional eine Perfect Forward Secrecy (PFS) anbieten, was wiederum eine Eigenschaft des Schlüssel-Austauschs ist und andererseits für IKE bedeutet, das wenn der Long Term Phase 1 Schlüssel kompromittiert wird, dass es trotzdem keinen einfachen Zugang zu den IPsec Daten gibt, da diese durch den Phase 1 Prozess hergestellten SAs geschützt werden. Das bedeutet, dass zusätzliches Schlüssel-Material für jede Phase 2 generiert wird.

Die Generierung von Schlüssel-Material bedeutet einen hohen rechnerischen Aufwand.  Um eines Beispiel Willen braucht es auch auf sehr schnellen Computern ein paar Sekunden, dieses Schlüssel-Material unter dem Gebrauch von modp8192 group zu generieren. Dies findet normalerweise einmal pro Phase-1-Austausch statt, welcher nur einmal zwischen einem beliebigen Host-Paar geschieht und dann für lange Zeit aufbewahrt wird. PFS fügt diesen Ressourcenintensiven Aufwand auch jedem Phase-2-Austausch hinzu.

4.1 Diffie-Hellman Groups

Das Diffie-Hellman (DH) Schlüssel-Austausch Protokoll erlaubt es zwei Parteien einen sicheren Schlüssel herzustellen, auch ohne dass vorab ein Geheimnis geteilt wurde. Die folgenden modularen Exponential- (MODP) und Elliptische Kurven (EC2N) Diffie-Hellman (auch als “Oakley” bezeichnet)-Gruppen werden unterstützt:

Diffie-Hellman Group Name Reference
Group 1 768 bit MODP group RFC 2409
Group 2 1024 bits MODP group RFC 2409
Group 3 EC2N group on GP(2^155) RFC 2409
Group 4 EC2N group on GP(2^185) RFC 2409
Group 5 1536 bits MODP group RFC 3526
Group 14 2048 bits MODP group RFC 3526
Group 15 3072 bits MODP group RFC 3526
Group 16 4096 bits MODP group RFC 3526
Group 17 6144 bits MODP group RFC 3526

4.2 IKE Traffic

Um Problemen mit IKE Paketen vorzubeugen, welche gegen SPD Regeln verstoßen und es benötigt wird, diese mit einer noch nicht hergestellten SA zu verschlüsseln (was wiederum das Paket versucht hat), werden Originale lokale Pakete mit UDP Quell-Port 500 nicht mit SPD verarbeitet. Im selben Zug werden lokal angelieferte Daten-Pakete nicht im eingehenden Policy check berücksichtigt, wenn Sie auf den UDP Ziel-Port 500 gehen.

4.3 Setup Prozess

Damit IPsec mit automatischer Schlüsselerzeugung unter Zuhilfenahme von IKE-ISAKMP funktioniert muss man Policy, Peer und Proposal (optional) Einträge erstellen.

Warnung: IPsec ist sehr sensibel bei Zeitänderungen. Wenn also beide Enden des IPsec Tunnels zeitlich nicht synchronisiert sind (indem z.B. verschiedene NTP Server genutzt werden und diese beim Update nicht dieselben Zeitstempel verwenden) wird die Tunnelverbindung abgebrochen und muss neu hergestellt werden.

5 Mode Config

Sub-menu: /ip ipsec mode-config

Hinweis: Wenn der RouterOS Client der Initiator ist, wir dieser immer eine CISCO UNITY Erweiterung senden und RouterOS unterstützt aus dieser Erweiterung jedoch nur split-include.

Property Description
address-pool (none | string; Default: ) Name des Adress-Pools aus welchem der Antwortende versucht, eine Adresse zu beziehen, wenn mode-config aktiviert ist.
address-prefix-length (integer [1..32]; Default: ) Präfix-Länge (Netzmaske) von bezogenen Adressen, aus dem Pool.
comment (string; Default: )
name (string; Default: )
send-dns (yes | no; Default: yes) Ob eine DNS Konfiguration gesendet wird.
split-include (list of ip prefix; Default: ) Liste von Subnetzen im CIDR Format, welche getunnelt werden. Die Subnetze werden zum Peer gesendet, in dem die CISCO UNITY Erweiterung genutzt wird, während der Remote Peer gezielt dynamische Policies erstellt.

6 XAuth Users

Sub-menu: /ip ipsec user

List von erlaubten XAuth Nutzern

Property Description
address (IP; Default: ) An Clients vergebene IP Adressen. Wenn dies nicht gesetzt wurde werden dynamische Adressen aus dem im Mode Config Menü erstellten Adress-Pool vergeben.
name (string; Default: ) Username
password (string; Default: )

7 Peer Konfiguration

Sub-menu: /ip ipsec peer

Peer Konfigurations-Einstellungen werden genutzt um eine Verbindung zwischen IKE Dämonen herzustellen( phase 1 Konfiguration). Diese Verbindung wird dann dazu genutzt Schlüssel und Algorithmen für SAs auszuhandeln.

Startend mit der RouterOS Version v6rc12 nutzt die antwortende Seite nun initiator exchange type für die Auswahl der Peer Konfiguration. Das bedeutet, dass man mehrere IPsec Peers mit derselben Adresse, aber verschiedenen Austausch-Modi oder Verschlüsselungsmethoden konfigurieren kann.

Hinweis: Die Austausch-Modi main und l2tp-main werden gleich behandelt, weswegen die Modi wiederum keine Auswahl der Konfiguration von mehreren Peers treffen können.

Property Description
address (IP/IPv6 Prefix; Default: 0.0.0.0/0) Wenn die Adresse des Remote Peers mit diesem Präfix übereinstimmt, wird die Peer Konfiguration für die Authentifikation und Herstellung von Phase 1 verwendet. Wenn verschiedene Peer Adressen auf verschiedene Konfigurationseinträge passen, wird die zutreffendste genutzt (z.B. die die mit der größten Netzmaske).
auth-method (pre-shared-key | rsa-signature; Default: pre-shared-key) Authentifikations-Methode:

  • pre-shared-key – Man authentifiziert sich mit einem Passwort (secret) String, welcher zwischen den beiden Peers geteilt wird
  • rsa-signature – Authentifiziert anhand eines Paars von RSA Zertifikaten
  • rsa-key – Authentifikation mit Hilfe eines RSA Schlüssels, welcher über das entsprechende Menü in die IPsec Keys importiert wurde
  • pre-shared-key-xauth – Ähnlich der PSK Authentifikation nur zusätzlich mit xauth Nutzername/Passwort. Der passive Parameter identifiziert die Server/Client Seite
  • rsa-signature-hybrid – Antwortende Zertifikats-Authentifikation mit dem Xauth als Initiator. passive Parameter identifizizieren die Server/Client Seite
certificate (string; Default: ) Name eines Zertifikats, welches in der certificate Tabelle gelistet ist (signiert Pakete; das Zertifikat muss über einen privaten Schlüssel verfügen). Anwendbar, wenn die RSA Signatur-Authentifikationsmethode (auth-method=rsa-signature).
comment (string; Default: ) Kurze Beschreibung des Peers.
dh-group (ec2n155 | ec2n185 | modp1024 | modp1536 | modp2048 | modp3072 | modp4096 | modp6144 | modp768; Default: modp1024) Diffie-Hellman group (Chiffrierstärke)
disabled (yes | no; Default: no) Ob der Peer genutzt wird um mit dem Präfix des Remote Peers übereinzustimmen
dpd-interval (time | disable-dpd; Default: 2m) DPD=Dead peer detection  Intervall. Wenn man dieses auf disable-dpd, setzt wird nichtmehr geprüft, ob ein Peer noch verfügbar (=”tot”)ist oder nicht
dpd-maximum-failures (integer: 1..100; Default: 5) Maximale Anzahl an Fehlern, bevor ein Peer als nichtmehr verfügbar gilt. Anwendbar, wenn DPD aktiv ist.
enc-algorithm (3des | aes-128 | aes-192 | aes-256 | blowfish | camellia-128 | camellia-192 | camellia-256 | des; Default: aes-128) Liste von Verschlüsselungs-Algorithmen, welche vom Peer genutzt werden.
exchange-mode (aggressive | base | main | main-l2tp; Default: main) Verschiedene ISAKMP Phase 1 Austausch-Modi, welche RFC 2408 entsprechen. Man sollte keinen anderen Modus ausser main nutzen, außer man weiß, was man tut. main-l2tp Modus entlastet rfc2409 section 5.4 um pre-shared-key Authentifikation im main Modus zu ermöglichen.
generate-policy (no | port-override | port-strict; Default: no) Erlaubt es diesem Peer ein SA für nicht existierende Policies herzustellen. Diese Policies werden dynamisch für die Gültigkeitsdauer der SA erstellt. Automatisch erstellte Policies ermöglichen es z.B einen IPsec gesicherten  L2TP Tunnel zu erstellen (oder ein anderes Setup) wenn die IP Adresse des Peers während der Konfiguration nicht bekannt ist.

  • no – Keine Policies werden generiert
  • port-override — Generiert Policies und zwingt die Policy jeden Port zu nutzen (altes Verhaltensmuster).
  • port-strict — Nutzt die Ports vom Proposal des Peers, welcher mit der Policy übereinstimmen sollte
hash-algorithm (md5 | sha1 | sha256 | sha512; Default: sha1) Hashing Algorithmus. SHA (Secure Hash Algorithm) ist stärker, aber langsamer. MD5 nutzt 128-Bit Schlüssel, sha1-160Bit Schlüssel.
key (string; Default: ) Name des Schlüssels aus dem key Menü. Anwendbar wenn auth-method=rsa-key.
lifebytes (Integer: 0..4294967295; Default: 0) Phase 1 Lifebytes wird nur als administrativer Wert genutzt, welcher einem Proposal hinzugefügt wird. Wird in Fällen genutzt, in denen der Remote Peer einen genauen lifebyte Wert benötigt, um Phase 1 herzustellen.
lifetime (time; Default: 1d) Phase 1 lifetime: Gibt die Gültigkeitsdauer einer SA an.
mode-config (none | request-only | string; Default: none) Name des mode config parameters from mode-config menu. When parameter is set mode-config is enabled.

  • Der initiierende Peer auf Phase 1 welcher die mode-config Anfrage sendet und die zugeordnete IP Adresse und den DNS setzt.
  • Dem antwortenden Peer wird eine IP Adresse zugewiesen, wenn der Adress-Pool definiert ist. Dieser wird ausserdem den DNS Server Adresse und die split-include Subnetze schicken. (wenn festgelegt).
my-id (auto | fqdn | user-fqdn; Default: auto) Dieser Parameter setzt die IKE ID in den festgelegten Modus. Es ist möglich, mauell zwei Modi zu setzen, nämlich FQDN und USER_FQDN.

  • FQDN – fully qualified domain name
  • USER_FQDN – Legt einen fully-qualified Nutzernamen-String fest, z.B. “user@domain.com”;
  • auto IP addresse wird als ID genutzt.
nat-traversal (yes | no; Default: no) Nutzt Linux NAT-T Mechanismus, um IPsec Imkompabilitäten mit NAT Routern zwischen IPsec Peers zu lösen. Dies funktioniert nur mit dem ESP Protokoll (AH wird vom Aufbau her nicht unterstützt, da es das komplette Paket inkl. des IP Headers signiert, welcher vom NAT geändert wird und somit die AH Signatur ungültig wird). Diese Methode verpackt IPsec ESP Datenverkehr in UDP Streams um kleineren Imkompatibilitäten bei ESP mit NAT aus dem Weg zu gehen.
passive (yes | no; Default: no) Wenn der Passiv-Modus aktiviert ist wird auf die Initiierung der IKE Verbindung durch den Remote Peer gewartet. Der aktivierte Passiv-Modus zeigt außerdem an, dass der Peer der xAuth Responder ist und bei inaktiven Passiv-Modus xAuth Initiator.
policy-template-group (none | string; Default: ) Wenn die generierende Policy aktiv ist, prüft der Responder anhand des Templates derselben group. Wenn kein Templates passt, wird die Phase 2 SA nicht hergestellt.
port (integer:0..65535; Default: 500) Kommunikations-Port, welcher für den IPsec Datenverkehr genutzt wird.
proposal-check (claim | exact | obey | strict; Default: obey) Phase 2 die Prüfungs-Logik hinter der Gültigkeitsdauer:

  • claim – nimmt den kürzesten der vorgeschlagenen und konfigurierten Gültigkeitsdauern und benachrichtigt den Initiator darüber.
  • exact – Genau dieselbe Gültigkeitsdauer wird erwartet.
  • obey – Akzeptiert alles, was vom Initiator gesendet wird.
  • strict – Wenn die vorgeschlagene Gültigkeitsdauer länger als die Default ist muss man die vorgeschlagene zurückweisen andernfalls akzeptiert man die vorgeschlagene
remote-certificate (string; Default: ) Name eines Zertifikats (gelistet in der certificate table) um die Remote Seite zu authentifizieren (Paket-Validierung; kein Privater Schlüssel wird benötigt). Anwendbar, wenn die RSA Signations-Authentifikations-Methode genutzt wird. Wenn das Remote-Zertifikat nicht festgelegt ist, wird das vom Remote Peer erhaltene Zertifikat gegen die CA im certificate store geprüft. Ordnungsgemäße CA müssen in den certificate store importiert werden.
secret (string; Default: ) Geheimer String (in Fällen, in denen die pre-shared key Authentifikation genutzt wird). Wenn es mit ‘0x’ startet, wird es als Hexadezimaler Wert geparst
send-initial-contact (yes | no; Default: yes) Gibt an, ob IKE-Pakete vom Typ “Erstkontakt” gesendet oder auf die Remote-Seite gewartet werden soll. Dieses Paket sollte die Entfernung von alten Peer-SAs für die aktuelle Quelladresse auslösen. Normalerweise sind in Road Warrior Setups Clients die Initiatoren und dieser Parameter sollte auf no gesetzt sein und dieser Parameter sollte auf Nein gesetzt werden. Der Erstkontakt wird nicht gesendet, wenn modecfg oder xauth für ikev1 aktiviert ist.
xauth-login (string; Default: ) Initiator (Client) XAuth Nutzername
xauth-password (string; Default: ) Initiator (Client) XAuth Passwort

Hinweis: Die Informationen über die IPsec Phasen werden gelöscht, wenn /ip ipsec peer configuration on the fly verändert wird, die Pakete bleiben jedoch aufgrund der installierten SA verschlüsselt/entschlüsselt (Die  remote-peers Information wird z.B. gelöscht, wenn die Peer Konfiguration verändert wird).

8 Schlüssel

Sub-menu: /ip ipsec key

Dieses Untermenü listet alle importierten public/private Schlüssel auf, welche für die Peer Authentifikation genutzt werden können. Das Submenü bietet auch mehrere Kommandos, um mit den Schlüsseln zu arbeiten.

Beispielsweise zeigt gibt print zwei importierte 1024-Bit Schlüssel aus. Einer ist Öffentlich und einer Privat.

[admin@PoETik] /ip ipsec key> print 
Flags: P - private-key, R - rsa 
 #    NAME                                                               KEY-SIZE
 0 PR priv                                                               1024-bit
 1  R pub                                                                1024-bit

Kommandos

Property Description
export-pub-key (file-name; key) Export des Öffentlichen Schlüssels, eines existierenden, privaten Schlüssels, in eine Datei.
generate-key (key-size; name) Generiert private Schlüssel. Nimmt zwei Parameter, den Namen des neu generierten Schlüssels und die Schlüsselgröße 1024,2048 und 4096.
import (file-name; name) Importiert den Schlüssel aus einer Datei.

9 Policy

Sub-menu: /ip ipsec policy

Die Policy Tabelle wird genutzt um zu bestimmen ob die Sicherheits-Einstellungen an auf das Paket angewendet werden sollen oder nicht.

Property Description
action (discard | encrypt | none; Default: encrypt) Legt fest, was mit einem Paket geschehen soll, wenn die Policy bei diesem greift.

  • none – das Paket wird unverändert durchgelassen
  • discard – das Paket wird gedroppt
  • encrypt – wendet Änderungen an, die in der Policy und den SAs festgelegt sind
comment (string; Default: ) Kurze Beschreibung der Policy.
disabled (yes | no; Default: no) Ob eine Policy auf Pakete angewendet werden soll, um diese abzugleichen
dst-address (IP/IPv6 prefix; Default: 0.0.0.0/32) Ziel-Adresse welche in Paketen abgeglichen wird.
dst-port (integer:0..65535 | any; Default: any) Ziel-Port welcher in Paketen abgeglichen wird. Wenn auf any gesetzt, werden alle Ports abgeglichen.
group (string; Default: default) Name der policy group welcher das Template zugewiesen ist.
ipsec-protocols (ah | esp; Default: esp) Legt fest, welche Kombination von Authentifikations-Header und verkapselndem Security Payload Protokoll auf den passenden Datenverkehr angewendet werden
level (require | unique | use; Default: require) Legt fest, wenn manche SAs für die Policy nicht gefunden werden:

  • use – überspringt diese Umwandlung, droppt aber keine Pakete und benötigt keine SA vom IKE Dämon
  • require – Droppt das Paket und benötigt SA
  • unique – Droppt das Paket und benötigt eine einzigartige SA, welche nur mit dieser bestimmten Policy verwandt wird
manual-sa (string | none; Default: none) Name des manuellen SA Templates
priority (integer:-2147483646..2147483647; Default: 0) Policy Prioritäts-Klassifizierer (ganzzahlig). Größere Zaheln bedeuten höhere Priorität.
proposal (string; Default: default) Name des Proposal Templates welches vom IKE Dämon gesendet wird, um SAs für diese Policy zu etablieren.
protocol (all | egp | ggp| icmp | igmp | …; Default: all) IP Paket Protokoll dem entsprochen werden muss
sa-dst-address (ip/ipv6 address; Default: ::) SA Ziel- IP/IPv6 Adresse (Remote Peer).
sa-src-address (ip/ipv6 address; Default: ::) SA Quell- IP/IPv6 Adresse (Lokaler Peer).
src-address (ip/ipv6 prefix; Default: 0.0.0.0/32) Quell-IP Präfix
src-port (any | integer:0..65535; Default: any) Quell-Port des Pakets
template (yes | no; Default: no) Erstellt ein Template, und fügt es einer definierten policy group hinzu. Die folgenden Parameter werden vom Template genutzt:

  • Quell-Adresse, Ziel-Adresse – Das angeforderte Subnetz muss in beiden Richtungen übereinstimmen (z.B erlaubt man mit 0.0.0.0/0 alle)
  • Protokoll – Das passende Protokoll, wenn man es auf alle setzt, wird jedes Protokoll akzeptiert
  • Proposal – SA Parameter, welche für dieses Template genutzt werden.
tunnel (yes | no; Default: no) Legt fest, ob der Tunnel-Modus genutzt werden soll

Hinweis: Alle Pakete sind im Tunnel-Modus IPIP verkapselt, weswegen ihre neue IP Header Quell- und Zieladresse auf die SA Quell- und SA Zieladress-Werte der Policy gesetzt werden. Wenn man keinen Tunnel-Modus nutzt (was bedeutet, dass man den Transport-Modus nutzt) werden nur Pakete deren Quell- und Zieladressen die gleichen sind, wie die der SA Quell- und SA Zieladressen von der Policy verarbeitet. Der Transport Modus kann nur mit Paketen funktionieren, welchen von und für IPsec Peers stammen und bestimmt sind (Hosts welche Security Association hergestellt haben). Um den Datenverkehr zwischen den Netzwerken zu verschlüsseln (oder ein von einem Netzwerk zu einem Host) muss man den Tunnel-Modus verwenden.

9.1 Policy Stats

Das Kommando /ip ipsec policy print stats zeigt den aktuellen Status der Policy an. Zusätzlich werden read-only Parameter ausgegeben.

Property Description
in-accepted (integer) Wie viele eingehende Pakete wurden ohne Entschlüsselungsversuch von der Policy weitergeben.
in-dropped (integer) Wie viele eingehende Pakete wurden von der Richtlinie ohne einen Entschlüsselungsversuch gelöscht
in-transformed (integer) Wie viele eingehende Pakete wurden entschlüsselt (ESP) und/oder von der Policy verifiziert (AH)
out-accepted (integer) Wie viele ausgehende Pakete wurden ohne Entschlüsselungsversuch von der Policy weitergeben.
out-dropped (integer) Wie viele ausgehende Pakete wurden von der Richtlinie ohne einen Entschlüsselungsversuch gelöscht
out-transformed (integer) Wie viele ausgehende Pakete wurden entschlüsselt (ESP) und/oder von der Policy verifiziert (AH)
ph2-state (expired | no-phase2 | established) Angabe des Fortschritts der Schlüsselfestlegung.

10 Policy Groups

Sub-menu: /ip ipsec policy group

Property Description
name (string; Default: )
comment (string; Default: )

11 Proposal Einstellungen

Sub-menu: /ip ipsec proposal

Proposal Information welche vom IKE Dämon gesendet wird, um SAs für diese Policy herzustellen ( Phase 2). Die konfigurierten Proposals sind in der policy configuration gesetzt.

Property Description
auth-algorithms (md5|sha1|null|sha256|sha512; Default: sha1) Erlaubte Algorithmen für die Authorisierung. sha1 ist stärker, dafür ein langsamer Algorithmus.
comment (string; Default: ) Kurze Beschreibung des Items.
disabled (yes | no; Default: no) Ob das Item deaktiviert ist.
enc-algorithms (null|des|3des|aes-128-cbc|aes-128-cbc|aes-128gcm|aes-192-cbc|aes-192-ctr|aes-192-gcm|aes-256-cbc|aes-256-ctr|aes-256-gcm|blowfish|camellia-128|camellia-192|camellia-256|twofish; Default: aes-128-cbc) Erlaubte Algorithmen und Schlüssellängen, die für die SAs genutzt werden.
lifetime (time; Default: 30m) Gültigkeitsdauer einer SA, bevor diese verworfen wird.
name (string; Default: ) Name des Proposal Templates, welches in anderen Teilen der IPsec Konfiguration identifiziert wird.
pfs-group (ec2n155 | ec2n185 | modp1024 | modp1536 | modp2048 | modp3072 | modp4096 | modp6144 | modp768 | none; Default: modp1024) Diffie-Helman Gruppe welche für Perfect Forward Secrecy genutzt wird.

12 Manual SA

Sub-menu: /ip ipsec manual-sa

Das Menü dient dazu, SAs manuell zu konfigurieren. Erstellte SA Templates können dann für die Policy Konfiguration genutzt werden.

Property Description
ah-algorithm (in/out
in,out = md5|null|sha1
; Default: null)
Authentication Header Verschlüsselungs-Algorithmus.
ah-key (string/string; Default: ) Eingehender Authentifikations-Schlüssel/ Ausgehender Authentifikations-Schlüssel
ah-spi (0x100..FFFFFFFF/0x100..FFFFFFFF; Default: 0x100) Eingehende-SA-SPI/Ausgehende-SA-SPI
disabled (yes | no; Default: no) Legt fest, ob ein Objekt genutzt oder ignoriert wird
esp-auth-algorithm (in/out
in,out = md5|null|sha1
; Default: null)
Verkapselnder Security Payload Authentifikations-Verschlüsselungs-Algorithmus
esp-auth-key (string/string; Default: ) Eingehender Authentifikations-Schlüssel/ Ausgehender Authentifikations-Schlüssel
esp-enc-algorithm (in/out
in,out = 3des | aes-128 | aes-192 | aes-256 | des | …
; Default: null)
Eingehender-Verschlüsselungs-Algorithmus
esp-enc-key (string/string; Default: ) Eingehender Verschlüsselungs-Schlüssel/Ausgehender Verschlüsselungs-Schlüssel
esp-spi (0x100..FFFFFFFF/0x100..FFFFFFFF; Default: 0x100) Eingehende-SA-SPI/Ausgehende-SA-SPI
lifetime (time; Default: 0s) Gültigkeitsdauer dieser SA
name (string; Default: ) Name des Objekts als Referenz für die Policies

13 Installierte SA

Sub-menu: /ip ipsec installed-sa

Diese Funktion bietet Informationen zu installierten SAs inklusive der Schlüssel an.

Property Description
AH (yes | no)
ESP (yes | no)
add-lifetime (time/time) Hinzugefügte Gültigkeitsdauer für die SA im Format Soft/Hard

  • soft – Zeitperiode nach der IKE versuchen wird eine neue SA herzustellen
  • hard – Zeitperiode nach der eine SA gelöscht wird
addtime (time) Datum und Zeit, wenn die SA hinzugefügt wurde.
auth-algorithm (sha1 | md5) Zeigt den aktuell genutzten Authentifikations-Algorithmus
auth-key (string) Zeigt den genutzten Authentifikations-Schlüssel
current-bytes (64-bit integer) Zeigt die Anzahl der Bytes der SA an.
dst-address (IP)
enc-algorithm (des | 3des | aes …) Zeigt den aktuell genutzten Verschlüsselungs-Algorithmus an
pfs (yes | no)
replay (integer)
spi (string)
src-address (IP)
state (string) Zeigt den aktuellen Status der SA an (“mature”, “dying” etc)

13.1 Flushing SAs

Manchmal, nach inkorrekten/unvollständigen Aushandlungen, ist es nötig, die SA Tabelle manuell zurückzusetzen, sodass die SA neu ausgehandelt werden kann. Diese Option wird über das folgende Kommando angeboten /ip ipsec installed-sa flush

Dieses Kommando erlaubt nur eine Eigenschaft:

Property Description
sa-type (ah | all | esp; Default: all) Festgelegte SA Typen zum zurücksetzen:

  • ah – nur SAs mit dem AH Protokoll löschen
  • esp – nur SAs mit dem ESP Protokoll löschen
  • all – Sowohl SAs mit dem ESP und AH Protokoll löschen

14 Remote Peers

Sub-menu: /ip ipsec remote-peers

Dieses Untermenü stellt verschiedene Statistiken über Remote Peers zur Verfügung, welche aktuell eine Phase 1 Verbindung mit dem Router hergestellt haben. Man beachte, dass wenn der Peer hier nicht angezeigt wird, das nicht gleichzeitig bedeutet, dass kein IPsec Datenverkehr mit diesem ausgetauscht wird. Read only Eigenschaften:

Property Description
local-address (ip/ipv6 address) Lokale ISAKMP SA Adresse auf dem Router, welche vom Peer genutzt wird.
remote-address (ip/ipv6 address) Remote Peer’s IP/IPv6 Adresse
side (initiator | responder) Zeigt, welche Seite die Aushandlung der Phase1 initiiert hat.
state (string) Status der Phase1 Aushandlung mit dem Peer. Wenn z.B. Phase1 und Phase2 ausgehandelt sind, wird der Status “established” also verbunden angezeigt.
established (time) Wielange Peers im verbundenen Status sind.

14.1 Alle IPsec Verbindungen schließen

Das Menü verfügt über ein Kommando, um schnell alle hergestellten IPsec Verbindungen zu schließen. Dieses Kommando löscht alle installierten SAs (Phase2) und entfernt alle Einträge des Remote-Peer Menüs (Phase1).

Nutzung:

/ip ipsec remote-peers kill-connections 

15 Statistiken

Sub-menu: /ip ipsec statistics

Dieses Menü zeigt verschiedene IPsec Statistiken an.

Property Description
in-errors (integer) Alle eingehenden Fehler welche nicht mit einem anderen Zähler übereinstimmen.
in-buffer-errors (integer) Kein freier Zwischenspeicher
in-header-errors (integer) Header Fehler
in-no-states (integer) Kein Zustand wurde festgestellt, wenn z.B. eingehende SPI, Adressen oder IPsec Protokoll der SA falsch sind.
in-state-protocol-errors (integer) Umwandlung des festgelegten Protokolls schlägt fehl, wenn z.B. der SA Schlüssel falsch ist oder der Hardware-Beschleuniger die Menge an Paketen nicht verarbeiten kann.
in-state-mode-errors (integer) Umwandlungs-Modus bezogene Fehler
in-state-sequence-errors (integer) Die Sequenz-Anzahl ist außerhalb des window Wertes
in-state-expired (integer) Zustand ist abgelaufen
in-state-mismatches (integer) Der Zustand passt nicht zur Option, wenn z.B. der UDP Verkapselungs-Typ nicht passt.
in-state-invalid (integer) Zustand ist ungültig
in-template-mismatches (integer) Es gibt kein passendes Template für den Zustand, z.B. eingehende SAs sind korrekt, oder die SP Regel ist falsch. Mögliche Fehlerursachen sind unpassende SA-Quell- oder SA-Ziel-Adressen.
in-no-policies (integer) Keine Policy wurde für den Zustand gefunden, wenn z.B eingehende SAs korrekt sind, aber keine SP gefunden wurde.
in-policy-blocked (integer) Policy wurde verworfen
in-policy-errors (integer) Policy Fehler
out-errors (integer) Alle ausgehenden Fehler, welche nicht mit einem anderen Zähler übereinstimmen
out-bundle-errors (integer) Bündelgenerierungsfehler
out-bundle-check-errors (integer) Bündelprüffehler
out-no-states (integer) Kein verfügbarer Zustand
out-state-protocol-errors (integer) Transformationsprotokoll-spezifischer Fehler
out-state-mode-errors (integer) Transformationsspezifischer Fehler
out-state-sequence-errors (integer) Sequenzfehler, zB Sequenznummernüberlauf
out-state-expired (integer) Status ist abgelaufen
out-policy-blocked (integer) Policy verworfen
out-policy-dead (integer) Policy ist erloschen
out-policy-errors (integer) Policy Fehler

16 Anwendungsbeispiele

16.1 Einfache, PSK xAuth ähnliche Konfiguration

Serverseitige Konfiguration:

/ip ipsec peer
add address=2.2.2.1 auth-method=pre-shared-key-xauth secret="123" passive=yes

/ip ipsec user
add name=test password=345

Clientseitige Konfiguration:

/ip ipsec peer
add address=2.2.2.2 auth-method=pre-shared-key-xauth secret="123" \
  xauth-login=test xauth-password=345

Hinweis: Auf der Serverseite ist es zwingend erforderlich, passive auf yes zu setzen, wenn XAuth genutzt wird.

16.2 Road Warrior Setup mit Mode Conf

Im folgenden Setup ist es nötig, dass Mitarbeiter auf lokale Office-Server und die Workstations anderer Mitarbeiter Remote Zugriff erhalten. Das Office verfügt über zwei Subnetze:

  • 192.168.55.0/24 für die Workstations
  • 192.168.66.0/24 Netzwerk, welches nicht von den RoadWarrios Clients erreichbar sein muss
  • 10.5.8.0/24 für Server

Der Zugriff zu diesen Netzwerken sollte sicher sein.

ipsec-road-warrior

Das tyische an RoadWarrior Setups wie diesem ist, dass es unmöglich ist, die Adresse des Users, welcher sich verbindet, vorab in Erfahrung zu bringe, weshalb es ein Setup des generate-policy Parameters auf der Serverseite geben muss. Dies führt jedoch zu anderen Problemen, da der Client bei diesem Setup jede Policy erzeugen und Zugriff zu jedem Netzwerk im Office erlangen kann. Auch wenn man 0.0.0.0/0 setzt und den Büroangestellten den Zugang zum Internet verbietet.

Mode Conf, policy group und policy templates erlauben einem diese Probleme zu überwinden.

16.2.1 IPsec Server Konfiguration

Zuerst muss man einen Pool anlegen, aus dem der RoadWarrios eine Adresse bezieht. Normalerweise setzt man im Büro einen DHCP-Server für die lokalen Workstations auf, weswegen man denselben DHCP-Pool für diese Zwecke nutzen kann.

/ip pool
add name=ipsec-RW ranges=192.168.77.2-192.168.77.254

Als nächstes muss man einstellen, welche Einstellungen an den Client gesendet werden, welcher Mode Conf nutzt.

/ip ipsec mode-config
add address-pool=ipsec-RW name=RW-cfg split-include=\
    10.5.8.0/24,192.168.55.0/24

Wie man sehen kann legt man fest, welcher Pool Adressen ausgibt und das man zwei erlaubte Subnetze vorfindet.
Um nun nur festgelegte Quell-/Ziel-Adressen in generierten Policies zu erlauben, nutzt  man Policy Gruppen und erstellt Policy Templates:

/ip ipsec policy group
add name=RoadWarrior

/ip ipsec policy
add dst-address=192.168.77.0/24 group=RoadWarrior src-address=10.5.8.0/24 \
    template=yes
add dst-address=10.5.8.0/24  group=RoadWarrior src-address=192.168.77.0/24 \
    template=yes
add dst-address=192.168.77.0/24 group=RoadWarrior src-address=192.168.55.0/24 \
    template=yes

Nun fügt man einfach xauth Nutzer und Peers mit aktiviertem Mode Conf und Policy Group hinzu.

/ip ipsec user
add name=user1 password=123
add name=user2 password=234

/ip ipsec peer
add auth-method=pre-shared-key-xauth generate-policy=port-strict mode-config=RW-cfg \
    policy-template-group=RoadWarrior secret=123 passive=yes

16.2.2 Apple iOS (iPhone/iPad) Client

Damit sich iOS Geräte verbinden können, werden Änderungen beim Proposal benötigt:

  • Funktioniert nicht mit dem 3des Verschlüsselungs-Algorithmus, aes-128/256 funktioniert
  • auth Algorithmus muss sha1 sein
  • PFS group muss none sein
  • lifetime muss 8 hours sein

Beispiel einer validen Proposal Konfiguration für iOS Geräte:

/ip ipsec proposal
set default enc-algorithms=aes-128-cbc,aes-256-cbc lifetime=8h \
    pfs-group=none

Hinweis: iPhone arbeitet nicht mit split-include 0.0.0.0/0. Wenn man 0.0.0.0/0 für ältere Clients setzt, wird der Datenverkehr nicht über den Tunnel gesendet, für neuere iOS Clients wird der Tunnel nicht hergestellt.

16.2.3 Android Client Hinweise

Android Geräte versuchen eine Policy mit dem Ziel 0.0.0.0/0 hinzuzufügen, man muss also sicherstellen, dass das richtige Policy Template hinzugefügt wird.

Im aktuellen Fall muss man das folgende hinzufügen:

/ip ipsec policy
add group=RoadWarrior src-address=192.168.77.0/24 dst-address=0.0.0.0/0 template=yes

16.2.4 RouterOS Client Konfiguration

/ip ipsec peer
add address=2.2.2.2 auth-method=pre-shared-key-xauth generate-policy=port-strict secret=123 \
     xauth-login=user1 xauth-password=123 mode-config=request-only

16.2.5 Shrew Client Konfiguration

n:version:2
n:network-ike-port:500
n:network-mtu-size:1380
n:network-natt-port:4500
n:network-natt-rate:15
n:network-frag-size:540
n:network-dpd-enable:0
n:client-banner-enable:0
n:network-notify-enable:0
n:client-wins-used:0
n:client-wins-auto:1
n:client-dns-used:1
n:client-dns-auto:0
n:client-splitdns-used:1
n:client-splitdns-auto:0
n:phase1-dhgroup:2
n:phase1-life-secs:86400
n:phase1-life-kbytes:0
n:vendor-chkpt-enable:0
n:phase2-life-secs:300
n:phase2-life-kbytes:0
n:policy-nailed:1
n:policy-list-auto:1
n:client-addr-auto:1
s:network-host:2.2.2.2
s:client-auto-mode:pull
s:client-iface:virtual
s:network-natt-mode:disable
s:network-frag-mode:disable
s:auth-method:mutual-psk-xauth
s:ident-client-type:address
s:ident-server-type:address
b:auth-mutual-psk:MTIz
s:phase1-exchange:main
s:phase1-cipher:3des
s:phase1-hash:md5
s:phase2-transform:esp-3des
s:phase2-hmac:sha1
s:ipcomp-transform:disabled
n:phase2-pfsgroup:2
s:policy-level:require

16.3 Road Warrior Setup mit Ikev2 RSA Authentifikation

Man geht hier vom gleichen Setup-Szenario wie im Road Warrior Setup mit Mode Conf Beispiel aus.

16.3.1 Ikev2 Server Setup

Bevor man mit der Konfiguration von IPsec beginnt, benötigt man Zertifikate. Einige Zertifikatsanforderungen müssen erfüllt sein, damit sich verschiedene Geräte mit dem Server verbinden können:

  • Gleiche Namen sollten IP oder DNS Namen des Servers enthalten (erforderlich bei Windows)
  • Der Subject Alt Name sollte IP oder DNS des Servers beinhalten (benötigt für andere Client, wie z.B den strongSwan Client auf Android)
  • EKU tls-server und tls-client werden für Windows benötigt.

Unter Berücksichtigung aller oben genannten Anforderungen können Server-und Client-Zertifikate erstellt werden:

/certificate
add common-name=ca name=ca
sign ca ca-crl-host=2.2.2.2
add common-name=2.2.2.2 subject-alt-name=IP:10.5.130.6 key-usage=tls-server name=server1
sign server1 ca=ca
add common-name=client1 key-usage=tls-client name=client1
sign client1 ca=ca
add common-name=client2 key-usage=tls-client name=client2

Now that we have certificates, server can be configured. Note that windows client requires modeconf, so we will use it to give out IP addresses from pool and send DNS, we also need to modify default template a little, to allow policies only from specific source addresses and generate unique level (required by multiple clients behind the same public IP):

/ip pool add name=rw-pool ranges=192.168.77.2-192.168.77.254
/ip ipsec policy
set 0 level=unique dst-address=192.168.77.0/24
/ip ipsec mode-conf
add name=cfg1 send-dns=yes address-pool=rw-pool address-prefix=32
/ip ipsec peer
add auth-method=rsa-signature certificate=server1 generate-policy=port-strict \
  mode-config=cfg1 passive=yes remote-certificate=none

Hinweis: Windows nutzt Punkt-zu-Punkt-Links, weswegen die die Festlegung jedes anderen außer des /32 Präfixes in den mode-config Einstellungen nichts bewirkt. Split include Subnetze werden ebenso nicht berücksichtigt.

Hinweis: Aktuell unterstützt RouterOS keine der EAP Authentifikations-Methoden.

16.3.2 RouterOS Client Konfiguration

Der erste Schritt ist der Export des Client Keys und Zertifikats vom Server:

/certificate export-certificate ca
/certificate export-certificate client1 export-passphrase=1234567890

Danach erfolgt der Upload der exportierten ca.crt, client1.crt and client1.key Datei auf das Client-Gerät, woraufhin man diese über den folgenden Befehl importiert /certificate import command. Dann man damit fertig ist, konfiguriert man den Client

/ip ipsec peer add address=2.2.2.2 auth-method=rsa-signature certificate=client1 \
  mode-config=request-only exchange-mode=ike2 generate-policy=port-strict

16.3.3 Windows Client Konfiguration

Der Windows Client erlaubt keinen separaten Import von Keys oder Zertifikaten. Deswegen ist es erforderlich, eine externes Tool für die Konvertierung (z.B. OpenSSL) der .crt und .key Dateinen in das pkcs12 Format zu nutzen.

openssl pkcs12 -export -out cl1.pfx -inkey cert_export_client1.key -in cert_export_client1.crt -certfile cert_export_ca.crt 

Um Zertifikate zu importen, öffnet man die Microsoft Management Console (mmc) drückt Ctrl+M und fügt “Certificates” von der Liste hinzu und wählt “Local Computer”.

snap-in

Dann erfolgt ein Rechtsklick auf den “Personal” Ordner und man wählt “All Tasks”->”Import…”. Dort wählt man die cl1.pfx Datei aus.

cert-import

CA und Client Zertifikat sollten nun im “Personal”-> “Certificates” Ordner erscheinen. CA Zertifikate müssen in die Trusted Root Liste verschoben werden. Über drag and drop kann man die CA in den “Trusted Root Certificates” Ordner verschieben. Nur Client Zertifikate sollten im Ordner “Personal” verbleiben.

mmc-personal

Nun ist man soweit, den Client aufzusetzen. Nachdem man den VPN Tunnel hinzugefügt hat, wählt man den VPN Typ IKEv2 sowie “Use machine certificates” aus.

win-ike2

16.3.4 Android Client Hinweise

Native Android Clients unterstützen aktuell kein ikev2. Der StrongSwan Client aus dem Play Store kann genutzt werden, um sich auf einen ikev2 Server zu verbinden. Der StrongSwan Client akzeptiert, genau wie Windows, Keys und Zertifikate im pkcs12 Format. Es wird also ein externes Tool benötigt, um die exportierten .crt und .key Dateien in .pfx zu konvertieren und diese .pfx Dateien dann zu importieren.

Nachdem man diese importiert hat, sieht man die CA und das Client Zertifikat in den User Zertifikaten:
android-cert-import

Diese kann man dann in der Profil-Konfiguration auswählen.

android-cl-cert

Das Ca Zertifikat wird automatisch ausgewählt, wie man auf dem unten ersichtlichen Screenshot ersehen kann. In manchen Fällen kann es aber auch sein, dass man das passende CA Zertifikat selbst festlegen muss, hierfür wählt man “Select automatically” ab und wählt dafür das importierte CA aus der Liste aus.

android-ca-cert

16.4 Road Warrior Setup mit Ikev1 RSA Authentifikation

16.4.1 Zertifikate erstellen

Alle Zertifikate können auch auf dem RouterOS Server erstellt werden, indem man den Zertifikats-Manager nutzt. Siehe auch das Beispiel >>

16.4.2 IPsec Server Konfiguration
/ip ipsec policy group
add name=test

/ip ipsec peer
add auth-method=rsa-signature certificate=server exchange-mode=main \
    generate-policy=port-override passive=yes policy-template-group=test remote-certificate=none
/ip ipsec policy
add dst-address=172.16.1.0/24 group=test src-address=172.16.2.0/24 template=yes

16.4.3 IPsec Client Konfiguration
16.4.4 CRL testen

Nun geht man davon aus, dass Client2 sich nichtmehr verbinden darf. Hierfür ist es nötig, dass das Zertifikat widerrufen wird, damit es von der CRL Liste ausgeschlossen wird.

/certificate
issued-revoke client2

Der Hinweis R=Revoked gibt einem an, dass das Zertifikat widerrufen wurde.

[admin@pe0] /certificate> print 
Flags: K - private-key, D - dsa, L - crl, C - smart-card-key, 
A - authority, I - issued, R - revoked, E - expired, T - trusted 
 #         NAME               COMMON-NAME               FINGERPRINT              
 0 K L A T myCa               myCa                      7fa636e6576495fe78f1a4...
 1 K   I T server             server                    cf0650a291bf4685f2fbd3...
 2 K   I   client1            client1                   26233de30e89b203b946ab...
 3 K   R   client2            client2                   cf172b62201befaf8d8966...

Wenn man nun die aktuelle Verbindung mit Client2 unterbricht, wird dieser nichtmehr in der Lage sein, eine Phase1 Verbindung herzustellen.

16.5 Seite-zu-Seite IPsec Tunnel

Unter Beachtung des Setups, wie im folgenden ersichtlich

site-to-site-ipsec-example

Zwei Remote Office Router sind mit dem Internet verbunden und die Office Workstations hinter den Routern sind geNATed. Jedes Office verfügt über ein eigenes, lokales Subnetz. 10.1.202.0/24 für Office1 und 10.1.101.0/24 für Office2. Beide Remote Offices benötigen einen sicheren Tunnel zu den lokalen Netzwerken, hinter den Routern.

16.5.1 IP Verbindungen

Auf beiden Routern wird ether1 als WAN-Port und ether2 als Verbindung zu den Workstations genutzt. Um das lokale Netzwerk zu maskieren, werden NAT Regeln genutzt.
Office1 Router:

/ip address
add address=192.168.90.1/24 interface=ether1
add address=10.1.202.1/24 interface=ether2

/ip route 
add gateway=192.168.90.254

/ip firewall nat
add chain=srcnat out-interface=ether1 action=masquerade

Office2 Router:

/ip address
add address=192.168.80.1/24 interface=ether1
add address=10.1.101.1/24 interface=ether2

/ip route 
add gateway=192.168.80.254

/ip firewall nat
add chain=srcnat out-interface=ether1 action=masquerade

16.5.2 IPSec Peer’s Konfiguration

Der nächste Schritt ist, die Konfiguration des Peers hinzuzufügen. Hierfür muss man die Adresse, den Port und den pre-shared-key festlegen. Andere Parameter bleiben auf den default Werten.

Office1 Router:

/ip ipsec peer
add address=192.168.80.1/32 port=500 auth-method=pre-shared-key secret="test"

Office2 Router:

/ip ipsec peer
add address=192.168.90.1/32 port=500 auth-method=pre-shared-key secret="test"

16.5.3 Policy und Proposal

Es ist wichtig, dass die vorgeschlagene Authentifikation sowie der Verschlüsselungs-Algorithmus auf beiden Routern gleich sind. In diesem Beispiel wird das vorfestgelegte “Standard” Proposal genutzt

[admin@MikroTik] /ip ipsec proposal> print 
Flags: X - disabled 
 0   name="default" auth-algorithms=sha1 enc-algorithms=3des lifetime=30m 
     pfs-group=modp1024 

Das Proposal liegt vor, weswegen man sich im nächsten Schritt um die Korrektur der IPsec Policy kümmern kann. Man will nun hin und zurück (10.1.202.0/24 zu 10.1.101.0/24 und zurück) den Datenverkehr verschlüsseln.

Office1 Router:

/ip ipsec policy
add src-address=10.1.202.0/24 src-port=any dst-address=10.1.101.0/24 dst-port=any \
sa-src-address=192.168.90.1 sa-dst-address=192.168.80.1 \
tunnel=yes action=encrypt proposal=default

Office2 Router:

/ip ipsec policy
add src-address=10.1.101.0/24 src-port=any dst-address=10.1.202.0/24 dst-port=any \
sa-src-address=192.168.80.1 sa-dst-address=192.168.90.1 \
tunnel=yes action=encrypt proposal=default

Hier ist zu beachten, dass man den Tunnel- anstelle des Transport-Modus konfiguriert hat, da es sich hier um eine Seite-zu-Seite-Verschlüsselung handelt.

16.5.4 NAT und Fasttrack Bypass

Wenn man zu diesem Zeitpunkt versucht, einen IPsec Tunnel herzustellen, wird dies nicht funktionieren und die Pakete werden abgewiesen. Dies aus dem Grund, da beide Router NAT Regeln aktiv haben und dies die Quell-Adresse der Pakete, nach dem verschlüsseln, verändert. Der Remote Router erhält also ein verschlüsseltes Paket und will es entschlüsseln, scheitert aber an der Tatsache, das die Quell-Adresse nichtmehr mit der in der Policy Konfiguration festgelegten Adresse übereinstimmt. Für mehr Informationen siehe auch packet flow ipsec example.
Um dieses Problem zu umgehen, benötigt man eine NAT Bypass Regel.

Office1 Router:

/ip firewall nat
add chain=srcnat action=accept  place-before=0 \
 src-address=10.1.202.0/24 dst-address=10.1.101.0/24

Office2 Router:

/ip firewall nat
add chain=srcnat action=accept  place-before=0 \
 src-address=10.1.101.0/24 dst-address=10.1.202.0/24

Hinweis: Wenn man versucht hat, den Tunnel herzustellen, bevor die NAT Bypass Regel eingerichtet wurde, muss man zuerst die Verbindungs-Tabelle um diesen Verbindungs-Eintrag bereinigen oder den Router neustarten.

Hier ist es sehr wichtig, diese Bypass Regel vor allen NAT Regeln zu setzen!

Ein anderes Problem ist aktiviertes Fasttrack, aufgrunddessen ein Bypass der Pakete an der IPsec Policy vorbei erfolgt. Deshalb muss diese Regel vor Fasttrack akzeptiert werden.

/ip firewall filter
add chain=forward action=accept place-before=1
 src-address=10.1.101.0/24 dst-address=10.1.202.0/24 connection-state=established,related
add chain=forward action=accept place-before=1
 src-address=10.1.202.0/24 dst-address=10.1.101.0/24 connection-state=established,related

Dies kann jedoch eine erhöhte Last auf die CPU bedeuten, wenn es mehrere Tunnel und entsprechenden Datenverkehr auf den Tunneln gibt.

Die Lösung ist die Nutzung von RAW Firewall Tabellen, um Connection Tracking zu Bypassen, wodurch die Notwendigkeit der oben aufgeführten Filterregeln entfällt und die CPU-Belastung um etwa 30% verringert werden kann.

/ip firewall raw
add action=notrack chain=prerouting src-address=10.1.101.0/24 dst-address=10.1.202.0/24
add action=notrack chain=prerouting src-address=10.1.202.0/24 dst-address=10.1.101.0/24

16.6 IPsec/L2TP hinter NAT

Unter Beachtung des Setups, wie im folgenden ersichtlich

ipsec-l2tp-example

Der Client benötigt eine sichere Verbindung zum Office, mit der öffentlichen Adresse 1.1.1.1, aber der Server weiss nicht, was die Quell-Adresse sein wird, von der aus der Client sich verbindet. Hierbei handelt es sich dann um ein Road-Warrior Setup. Der Client befindet sich zudem hinter einem Router mit aktiviertem NAT.
Für das Setup wird der RouterOS Router als Client Gerät hinter NAT verwendet (dies könnte auch jedes andere Gerät sein: Windows PC, Smartphone, Linux PC, etc.)

16.6.1 IP Verbindungen

Serverseitig:

/ip address 
add address=1.1.1.1/24 interface=ether1

/ip route
add gateway=1.1.1.2

Auf dem Client Router:

/ip address 
add address=2.2.2.2/24 interface=ether1
add address=10.5.8.0/24 interface=ether2

/ip route
add gateway=2.2.2.1

/ip firewall net
add chain=srcnat action=masquerade out-interface=ether1

Auf dem Client:

/ip address
add address=10.5.8.120/24 interface=ether1

16.6.2 L2TP Config

Serverseitig:

/interface l2tp-server 
set enabled=yes profil=default

/ip pool 
add name=l2tp-pool ranges=192.168.1.2-192.168.1.20

/ppp profile 
set default local-address=192.168.1.1 remote-address=l2tp-pool

/ppp secret
add name=l2tp-test password=test123456

Auf dem Client:

/interface l2tp-client
add connect-to=1.1.1.1 disabled=no name=l2tp-out1 password=password user=l2tp-test

16.6.3 IPsec Konfiguration

Serverseitig:

/ip ipsec proposal
set [ find default=yes ] enc-algorithms=3des,aes-128,aes-192,aes-256
/ip ipsec peer
add generate-policy=yes hash-algorithm=sha1 nat-traversal=yes secret=test123456

RouterOS als Client:

/ip ipsec proposal
set [ find default=yes ] enc-algorithms=aes-128
/ip ipsec peer
add address=1.1.1.1/32 hash-algorithm=sha1 nat-traversal=yes secret=test123456

/ip ipsec policy
add dst-address=1.1.1.1/32 protocol=udp sa-dst-address=1.1.1.1 \
      sa-src-address=10.5.8.120 src-address=10.5.8.120/32

Man sollte beachten, dass nat-traversal aktiviert ist. Diese Option wird benötigt, da die IPsec Verbindung durch einen NAT Router hergestellt wird (andernfalls wird IPsec keine Phase2 herstellen können).

Warning: Nur eine L2TP/IPsec Verbindung kann durch das NAT hergestellt werden. Dies bedeutet, dass sich nur ein Client auf den Server hinter dem gleichen Router verbinden kann.

16.6.4 Apple iOS (iPhone/iPad) Client

Man muss bei iOS L2TP als VPN Typ auswählen, um sich auf einen IPsec/L2TP Server auf RouterOS zu verbinden (dies beinhaltet den default IPsec Server welcher durch die QuickSet VPN checkbox erstellt wird).

ios-ipsec

16.7 Nur mit IPsec verkapselten Datenverkehr erlauben

Es gibt einige Szenarien, in denen man aus Sicherheitsgründen den Zugriff von/auf bestimmte Netzwerke verhindern möchte, wenn eingehende/ausgehende Pakete nicht verschlüsselt werden. Wenn man zum Beispiel ein L2TP/IPsec-Setup hat, will man nicht verschlüsselte L2TP-Verbindungsversuche verwerfen.

Es gibt verschiedene Wege, um dies zu erreichen:

  • Man nutzt einen IPsec Policy Abgleich in der Firewall;
  • Man nutzt eine generische IPsec Policy mit der action=drop und eine geringeren Priorität (kann in Road-Warrior Setups genutzt werden, wenn dynamische Policies erstellt werden);
  • Mit der DSCP Einstellung oder Prioritäten in der Mangle und Abgleich derselben Werte in der Firewall, nach der Entkapselung.

16.7.1 IPsec Policy Matcher

Man startet mit den einschlägigen und von IPsec benötigten Regeln accept established,related, accept ESP Protokoll und accept UDP 500 und 4500.

/ip firewall filter
add chain=input comment=established,related connection-state=\
    established,related in-interface=WAN
add chain=input comment=ESP disabled=yes in-interface=WAN protocol=ipsec-esp
add chain=input comment="UDP 500,4500" disabled=yes dst-port=500,4500 \
    in-interface=WAN protocol=udp src-port=500,4500

Nun setzt man den IPsec Policy Abgleich auf accept aller Pakete, die mit einer der IPsec Policies übereinstimmen und verwirft den Rest.

add chain=input comment="ipsec policy matcher" in-interface=WAN \
    ipsec-policy=in,ipsec
add action=drop chain=input comment="drop all" in-interface=WAN log=yes

Der IPsec Policy Abgleich nimmt zwei Parameter, nämlich die Direction und Policy. Man nutzt die eingehende Richtung/Direction und die IPsec Policy. Die IPsec Policy Option erlaubt es einem, die Datenpakete näher unter die Lupe zu nehmen, nachdem diese entkapselt wurden. Wenn man z.B nur Gre eingekapselte Pakete von einer festgelegten Quell-Adresse zulassen und den Rest verwerfen will, nimmt man die folgenden Regeln.

add chain=input comment="ipsec policy matcher" in-interface=WAN \
    ipsec-policy=in,ipsec protocol=gre src=address=192.168.33.1
add action=drop chain=input comment="drop all" in-interface=WAN log=yes

16.7.2 Generische IPsec Policy nutzen

Der Kniff an dieser Methode ist, dass man die default Policy mit der action=drop hinzufügt. Angenommen, es ist ein L2TP/IPsec Server mit der öffentlichen Adresse 1.1.1.1 aktiv und man will alle nicht verschlüsselten L2TP-Verbindungen verwerfen:

/ip ipsec policy
add src-address=1.1.1.1 dst-address=0.0.0.0/0 sa-src-address=1.1.1.1 \
  protocol=udp src-port=1701 tunnel=yes action=drop

Nun wird der Router jeden eingehenden, nicht verschlüsselten L2TP-Datenverkehr verwerfen, bis auf die Pakete, die einer Policy entsprechen, die aufgrund einer erfolgreich aufgebauten L2TP/IPsec Verbindung erstellt wurde und deren Priorität höher ist, als die der statischen default Regel.

[admin@rack2_10g1] /ip ipsec policy> print
Flags: T - template, X - disabled, D - dynamic, I - inactive, * - default
 0 T * group=default src-address=::/0 dst-address=::/0 protocol=all
       proposal=default template=yes

 1     src-address=1.1.1.1/32 src-port=1701 dst-address=0.0.0.0/0
       dst-port=any protocol=udp action=discard level=unique
       ipsec-protocols=esp tunnel=yes sa-src-address=1.1.1.1
       sa-dst-address=0.0.0.0 proposal=default manual-sa=none priority=0


 2  D  src-address=1.1.1.1/32 src-port=1701 dst-address=10.5.130.71/32
       dst-port=any protocol=udp action=encrypt level=require
       ipsec-protocols=esp tunnel=no sa-src-address=1.1.1.1
       sa-dst-address=10.5.130.71 priority=2

16.8 Mit Shrew Client verbinden und nur verschlüsselten Datenverkehr erlauben

17 Fehlerbehebung

Problem: Der Windows Fehler 809 erscheint, wenn man sich mit dem IPsec Server verbinden will, welcher sich hinter einem NAT befindet.

Lösung: Das Windows Betriebssystem unterstützt keine NAT-T Sicherheitszuordnungen zu Servern, die sich hinter einem Gerät befindet, welches NAT aktiv hat. Ein  befindenSicherheitsoperating systems do not support NAT-T security associations to servers that are located behind a NAT device. Eine Problemumgehung ist möglich, man muss hierfür aber die Windos Registry anpassen. Hierzu findet man hier mehr.
[ Top | Back to Content ]

Mikrotik-Blog.de Hinweise und Quellenangaben:
  • Dieser Artikel stammt nicht von Mikrotik-Blog.de. Mikrotik-Blog.de hat diesen Artikel nur übersetzt, wir bitten dies zu beachten. Im Artikel befinden sich u.U. gekennzeichnete Mikrotik-Blog.de-Hinweise, wenn wir dies als notwendig für das Verständnis erachten. Der Original Mikrotik Wiki-Artikel ist hier zu finden: http://wiki.mikrotik.com/wiki/Manual:IP/IPsec#Testing_CRL
  • Die Medien, wenn von uns nicht anders ausgewiesen, entstammen ebenso dem oben genannten Original Mikrotik Wiki-Artikel.
  • Die von Mikrotik-Blog.de übersetzten Artikel können teilweise schon älter sein und ggf. nicht mehr ganz dem aktuellsten Stand entsprechen. Als Hinweisgeber sind diese unserer Meinung nach jedoch allesamt weiterhin relevant.
  • Wir sind keine zertifizierten Übersetzer, deshalb können sprachliche und inhaltliche Fehler bei der Übersetzung passieren, wofür wir keine Verantwortung übernehmen können – Wir geben uns Mühe und bitten um Nachsicht und nehmen gerne Hinweise auf Fehler entgegen! ?
Dieser Beitrag wurde unter IPsec abgelegt und mit , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.