Nagstamon – Ping und Winbox Einbindung

Mikrotik Winbox mit Nagstamon nutzen

Inhalt

1 Nagstamon
2Ping-Einstellungen
3 Winbox-Einstellungen

 

1 Nagstamon

Bei Nagstamon handelt es sich um einen Desktop Status Monitor, der eine Verbindung zu verschiedenen Überwachungs-Servern, wie z.B. Nagios, Icinga, Opsview, Centreon, Op5 Monitor/Ninja, Check_MK Multisite und Thruk, herstellen kann: https://nagstamon.ifw-dresden.de/  

Will man in der Nagstamon-Anwendung  einen Mikrotik-Host, der via Nagios als z.B. Down angezeigt,  schnell via Rechtsklick per Ping oder Winbox erreichen, muss man vorab in den Einstellungen Actions definieren.

Die folgenden Actions wurde auf einer Ubuntu-Linux-Distribution (Versionsausgabe via cat /etc/issue gibt einem die System: Ubuntu 14.04.5 LTS) und mit Nagstamon Version 2.0.1 funktional getestet. Da es sich bei der Winbox um ein natives Win32 Binary handelt, wird diese auf diesem System unter Zuhilfenahme von Wine genutzt (Nagstamon gibt es natürlich auch für Windows).

2 Ping-Einstellungen

Rechtsklick auf die Anwendung im SysTray > Settings > Action > New action drücken und das folgende Eingeben (ggf. alternativ die Einstellungen der Nagstamon Dokumentation: https://nagstamon.ifw-dresden.de/docs/actions/ )

nagstamon-action-ping

3 Winbox-Einstellungen

Rechtsklick auf die Anwendung im SysTray > Settings > Action > New action drücken und das folgende Eingeben:

nagstamon-action-winbox

Es ist darauf zu achten, dass Sonderzeichen im Passwort richtig im String eingegeben werden:

Beispiel: wine64 /home/mikrotik-blog.de/Winbox.exe $ADDRESS$ IHR_NAME IHR_PASSWORT

Beispiel oben mit korrekt eingegebenem Beispiel-Namen/Passwort:
Name= Sam
Passwort= geheimesPasswort!!!

wine64 /home/mikrotik-blog.de/Winbox.exe $ADDRESS$ Sam geheimesPasswort\!\!\!


Veröffentlicht unter Nagstamon | Verschlagwortet mit , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , | Hinterlasse einen Kommentar

Konfiguration ab Werk/Default Configurations

Manual:Default Configurations


Manual:Konfiguration ab Werk

version

Gilt für RouterOS: v5, v6+

Inhalt

  • 1 Liste der Default Konfigurationen

    • 1.1 Kompaktgeräte Indoor
    • 1.2 Kompaktgeräte Outdoor
    • 1.3 Engineered
    • 1.4 CAP
  • 2 WAN Port
  • 3 Lokaler Port
  • 4 Wireless Konfiguration
  • 5 Default IP und DHCP Konfiguration
  • 6 Firewall, NAT und MAC Server
  • 7 DNS

1 Liste der Default Konfiguration

1.1 Kompaktgeräte Indoor

Wan port Lan port Wireless mode ht chain ht extension dhcp-server dhcp-client Firewall NAT Default IP Mac Server
RB750 RB750G ether1 Switched ether2-ether5 auf dem LAN-Port auf dem WAN-Port Zugriff auf den WAN-Port wird blockiert Masquerade wan port 192.168.88.1/24 on lan port Disabled on wan port
RB751 ether1 Switched ether2-ether5, bridged wlan1 with switch AP b/g/n 2412MHz 0,1 above-control auf dem LAN-Port auf dem WAN-Port Zugriff auf den WAN-Port wird blockiert Masquerade wan port 192.168.88.1/24 on lan port Disabled on wan port
RB951 ether1 Switched ether2-ether5, bridged wlan1 with switch AP b/g/n 2412MHz 0 above-control auf dem LAN-Port auf dem WAN-Port Zugriff auf den WAN-Port wird blockiert Masquerade wan port 192.168.88.1/24 on lan port Disabled on wan port
RB1100 AH/AHx2 192.168.88.1/24 on ether1
RB1200 192.168.88.1/24 on ether1
CCR series 192.168.88.1/24 on ether1
RB2011 ether1 two switch groups bridged (ether2-ether10, wlan1 if present) auf dem LAN-Port auf dem WAN-Port Zugriff auf den WAN-Port wird blockiert Masquerade wan port 192.168.88.1/24 on ether1 Disabled on wan port
CRS all ports switched 192.168.88.1/24 on ether1
CRS with wireless ether1 all other ports switched and bridged with wireless auf dem LAN-Port auf dem WAN-Port Zugriff auf den WAN-Port wird blockiert Masquerade wan port 192.168.88.1/24 on ether1 Disabled on wan port
mAP ether1 bridged wireless station b/g/n 2.4GHz 0 above control auf dem LAN-Port auf dem WAN-Port Zugriff auf den WAN-Port wird blockiert Masquerade wan port 192.168.88.1/24 on lan port Disabled on wan port

1.2 Kompaktgeräte Outdoor

Wan port Lan port Wireless mode ht chain ht extension dhcp-server dhcp-client Firewall NAT Default IP Mac Server
Groove 2Hn wlan1 ether1 station b/g/n 2.4GHz 0 above control auf dem LAN-Port auf dem WAN-Port Zugriff auf den WAN-Port wird blockiert Masquerade wan port 192.168.88.1/24 on lan port Disabled on wan port
Groove 5Hn wlan1 ether1 station a/n 5GHz 0 above control auf dem LAN-Port auf dem WAN-Port Zugriff auf den WAN-Port wird blockiert Masquerade wan port 192.168.88.1/24 on lan port Disabled on wan port
Groove A-5Hn bridged wlan1,ether1 AP a/n 5300MHz 0 192.168.88.1/24 on lan port
Metal 5 wlan1 ether1 station a/n 5GHz 0 above control auf dem LAN-Port auf dem WAN-Port Zugriff auf den WAN-Port wird blockiert Masquerade wan port 192.168.88.1/24 on lan port Disabled on wan port
Metal 2 wlan1 ether1 station b/g/n 2GHz 0 above control auf dem LAN-Port auf dem WAN-Port Zugriff auf den WAN-Port wird blockiert Masquerade wan port 192.168.88.1/24 on lan port Disabled on wan port
SXT 5xx,
SXT G-5xx
wlan1 ether1 station 5GHz-a/n (5ghz-a/n/ac) 0,1 above control auf dem LAN-Port auf dem WAN-Port Zugriff auf den WAN-Port wird blockiert Masquerade wan port 192.168.88.1/24 on lan port Disabled on wan port
OmniTik ether1 Switched ether2-ether5, bridged wlan1 with switch AP a/n 5300MHz 0,1 auf dem LAN-Port auf dem WAN-Port Masquerade wan port 192.168.88.1/24 on lan port
SEXTANT wlan1 ether1 station a/n 5GHz 0,1 above control auf dem LAN-Port auf dem WAN-Port Zugriff auf den WAN-Port wird blockiert Masquerade wan port 192.168.88.1/24 on lan port Disabled on wan port
BaseBox 5 bridged wlan1,ether1 AP a/n 5GHz 0,1 192.168.88.1/24 on lan port
BaseBox 2 bridged wlan1,ether1 AP b/g/n 2GHz 0,1 192.168.88.1/24 on lan port
QRT 2 wlan1 ether1 station b/g/n 2.4GHz 0,1 above control auf dem LAN-Port auf dem WAN-Port Zugriff auf den WAN-Port wird blockiert Masquerade wan port 192.168.88.1/24 on lan port Disabled on wan port
QRT 5 wlan1 ether1 station 5GHz-a/n 0,1 above control auf dem LAN-Port auf dem WAN-Port Zugriff auf den WAN-Port wird blockiert Masquerade wan port 192.168.88.1/24 on lan port Disabled on wan port

1.3 Engineered

Wan port Lan port Wireless mode ht chain ht extension dhcp-server dhcp-client Firewall NAT Default IP Mac Server
RB411xx,
RB435G,
RB433xx,
RB495xx,
RB800
192.168.88.1/24 on ether1
RB450xx ether1 Switched ether2-ether5 auf dem LAN-Port auf dem WAN-Port Zugriff auf den WAN-Port wird blockiert Masquerade wan port 192.168.88.1/24 on lan port Disabled on wan port
RB711-5xx,
RB711G-5xx
wlan1 ether1 station a/n 5GHz 0 above control auf dem LAN-Port auf dem WAN-Port Zugriff auf den WAN-Port wird blockiert Masquerade wan port 192.168.88.1/24 on lan port Disabled on wan port
RB711UA-5xx,
RB711GA-5xx
bridged wlan1,ether1 AP a/n 5300MHz 0 192.168.88.1/24 on lan port
RB711-2xx wlan1 ether1 station b/g/n 2.4GHz 0 above control auf dem LAN-Port auf dem WAN-Port Zugriff auf den WAN-Port wird blockiert Masquerade wan port 192.168.88.1/24 on lan port Disabled on wan port
RB711UA-2xx bridged wlan1,ether1 AP a/n 2412MHz 0 192.168.88.1/24 on lan port
RB911/912-2xx wlan1 ether1 station b/g/n 2.4GHz 0 above control auf dem LAN-Port auf dem WAN-Port Zugriff auf den WAN-Port wird blockiert Masquerade wan port 192.168.88.1/24 on lan port Disabled on wan port
RB911/912-5xx wlan1 ether1 station 5GHz-a/n (5GHz-a/n/ac) 0,1 above control auf dem LAN-Port auf dem WAN-Port Zugriff auf den WAN-Port wird blockiert Masquerade wan port 192.168.88.1/24 on lan port Disabled on wan port
RB921/922-2xx wlan1 bridged wireless with ethernets station b/g/n 2.4GHz 0,1 above control auf dem LAN-Port auf dem WAN-Port Zugriff auf den WAN-Port wird blockiert Masquerade wan port 192.168.88.1/24 on lan port Disabled on wan port
RB921/922-5xx wlan1 bridged wireless with ethernets station 5GHz-a/n (5GHz-a/n/ac) 0,1 above control auf dem LAN-Port auf dem WAN-Port Zugriff auf den WAN-Port wird blockiert Masquerade wan port 192.168.88.1/24 on lan port Disabled on wan port
RB953GS-5xx ether1 switched: sfp1,ether2,ether3 and bridged with wireless ap-bridge 5GHz-a/n (5GHz-a/n/ac) 0,1,2 above control auf dem LAN-Port auf dem WAN-Port Zugriff auf den WAN-Port wird blockiert Masquerade wan port 192.168.88.1/24 on lan port Disabled on wan port

Hinweis: Um das nach einem System Reset angewandte Konfigurations-Skript zu sehen, gibt man das folgende Kommando ein (die untenstehende Warnung sollte beachtet werden) /system default-configuration print

Warnung: /system default-configuration print zeigt immer die ab Werk Default Konfiguration an, sogar wenn diese von einem Netinstall Skript überschrieben wurde.

1.4 CAP

Wenn die CAP Default Konfiguration geladen ist, wird ‚ether1‘ als Management Port mit konfiguriertem DHCP-Client gesetzt.

Alle anderen Ethernet Interfaces werden gebridged und ‚wlan1‘ wird von CAPsMAN verwaltet

2 WAN Port

Wenn die Konfiguration vorgenommen wird, wird der WAN Port in „<wan port>-gateway“ umbenannt. Wenn Beispielsweise ether1 der Wan Port ist, wird dieser in „ether1-gateway“ umbenannt.

3 Lokaler Port

Lokale Ports können sein:

  • Ein einzelnes Interface
  • Ethernet-Ports welche in einer Switch-Gruppe gebündelt sind
  • bridged, alle Interfaces welche nicht WAN-Ports oder oder Switch Slaves sind.

Wenn die Ports geswitched sind, wird der Master-Port in „<ethernet name>-master-local“ umbenannt und die Slaves in „<ethernet name>-slave-local“.

Als Beispiel schaut man sich hierzu ein RB751 an. Auf dem Board ist ether1 als WAN Port konfiguriert und es verfügt über einen Switch Chip und ein vorkonfiguriertes Wlan-Interface. In diesem Fall sind alle Ports, bis auf ether1, in einer Switch Gruppe gruppiert und mit dem Wlan-Interface gebridged.

Die generierte Konfiguration sieht wie folgt aus:

/interface set ether2 name=ether2-master-local;
/interface set ether3 name=ether3-slave-local;
/interface set ether4 name=ether4-slave-local;
/interface set ether5 name=ether5-slave-local;
/interface ethernet set ether3-slave-local master-port=ether2-master-local;
/interface ethernet set ether4-slave-local master-port=ether2-master-local;
/interface ethernet set ether5-slave-local master-port=ether2-master-local;

/interface bridge add name=bridge-local disabled=no auto-mac=no protocol-mode=rstp;

:local bMACIsSet 0;
:foreach k in=[/interface find] do={
        :local tmpPort [/interface get $k name];
        :if ($bMACIsSet = 0) do={
               :if ([/interface get $k type] = "ether") do={
                      /interface bridge set "bridge-local" admin-mac=[/interface ethernet get $tmpPort mac-address];
                      :set bMACIsSet 1;
                 }
        }
        :if (!($tmpPort~"bridge" || $tmpPort~"ether1" || $tmpPort~"slave")) do={
               /interface bridge port add bridge=bridge-local interface=$tmpPort;
        }
}

4 Wlan Konfiguration

Die Wlan Konfiguration hängt vom Markt-Segment ab, für welches das Board designt ist. Es kann als AP oder Station in 2GHz oder 5GHz Frequenz. Die Standard-Frequenz in 2GHz ist 2412 und bei 5GHz 5300. Die SSID lautet „Mikrotik-“ + die letzten 3 Bytes der Wlan MAC-Adresse in Hex. Startend mit RouterOS v5.25 und v6rc14 ist das Wlan Sicherheits-Profil mit WPA/WPA2 vorkonfiguriert. Der Sicherheitsschlüssel entspricht der Seriennummer des Routers.

Wenn die MAC-Adresse des wlan1 Interfaces  00:0B:6B:30:7F:C2 lautet und die Seriennummer des Boards die folgende ist

/sys routerboard print 
       routerboard: yes
     serial-number: 0163008F8883

Die folgenden Einstellungen werden angewandt:

  • SSID=“MikroTik-307FC2″
  • Sicherheitseinstellungen:
    • mode=dynamic-keys
    • authentication-types=wpa-psk,wpa2-psk
    • wpa-pre-shared-key=0163008F8883
    • wpa2-pre-shared-key=0163008F8883

Hinweis: Beim Sicherheitsschlüssel ist die Groß-/Kleinschreibung zu beachten!

Wenn das Board über zwei Chains verfügt (dies kann man vom Zeichen D in der Namensbezeichnung ableiten) sind beide Chains aktiviert. Die HT Extension ist auf allen CPEs aktiviert.

Beispiels-Konfiguration auf dem RB751:

:if ( $wirelessEnabled = 1) do={
# wait for wireless
       :while ([/interface wireless find] = "") do={ :delay 1s; };

       /interface wireless set wlan1 mode=ap-bridge band=2ghz-b/g/n ht-txchains=0,1 ht-rxchains=0,1 \
               disabled=no country=no_country_set wireless-protocol=any
       /interface wireless set wlan1 channel-width=20/40mhz-ht-above ;
}

5 Default IP und DHCP Konfiguration

Die Default IP Adresse auf allen Baords ist die 192.168.88.1/24. Boards ohne festgelegte Konfiguration verfügt über eine auf ether1 gesetzte IP Adresse, andere Boards verfügen über eine IP Adresse auf dem LAN Interface.

Alle Boards verfügen über einen konfigurierten WAN Port und über einen auf diesem konfigurierten DHCP Client.

Typisch auf allen CPEs ist, dass ein DHCP-Server auf dem LAN-Port aktiv ist und dort IP-Adressen im Adressbereich 192.168.88.2-192.168.88.254 ausgegeben werden.

Ein als Beispiel auf einem RB751 angewandte DHCP Konfiguration.

/ip dhcp-client add interface=ether1-gateway disabled=no

/ip pool add name="default-dhcp" ranges=192.168.88.10-192.168.88.254;
/ip dhcp-server 
  add name=default address-pool="default-dhcp" interface=bridge-local disabled=no;

/ip dhcp-server network 
  add address=192.168.88.0/24 gateway=192.168.88.1 dns-server=192.168.88.1 comment="default configuration";

6 Firewall, NAT und MAC Server

Alle Boards mit einem konfigurierten WAN Port verfügen ebenso über eine Absicherung auf diesem Port. Jeder Datenverkehr, der den WAN Port verlässt, wird maskiert. In der Forward Chain wurden ebenso drei Regeln für Boards mit einer Maskierungsregel hinzugefügt: accept established, accept related und invalide gedroppt, damit keine Pakete mit lokaler IP über den WAN-Port verbreitet werden.
Konfigurationsbeispiel:

/ip firewall {
      filter add chain=input action=accept protocol=icmp comment="default configuration"
      filter add chain=input action=accept connection-state=established in-interface=ether1-gateway comment="default configuration"
      filter add chain=input action=accept connection-state=related in-interface=ether1-gateway comment="default configuration"
      filter add chain=input action=drop in-interface=ether1-gateway comment="default configuration"
      nat add chain=srcnat out-interface=ether1-gateway action=masquerade comment="default configuration"
}


/tool mac-server remove [find];
/tool mac-server mac-winbox disable [find];
:foreach k in=[/interface find] do={
       :local tmpName [/interface get $k name];
       :if (!($tmpName~"ether1")) do={
              /tool mac-server add interface=$tmpName disabled=no;
              /tool mac-server mac-winbox add interface=$tmpName disabled=no;
        }
}
/ip neighbor discovery set [find name="ether1-gateway"] discover=no


7 DNS

Jedes Board erlaubt Remote DNS Requests und verfügt über einen vom Router voreingestellten, statischen DNS Namen.

	/ip dns {
		set allow-remote-requests=yes
		static add name=router address=192.168.88.1
	}

[ Top | Back to Content ]

Veröffentlicht unter RouterBOARD Konfiguration ab Werk, RouterOS Installation und Paketquellen | Verschlagwortet mit , , , , , , , , , , , | Hinterlasse einen Kommentar

RouterBOOT

Manual:RouterBOOT

RouterBOOT ist für das starten von RouterOS auf RouterBOARD Geräten verantwortlich.

Inhalt

  • 1 Main und Backup Loaders
  • 2 RouterBOARD Reset Button
  • 3 Konfiguration
  • 4 Einfaches Upgrade
    • 4.1 RouterBOOT Version prüfen
  • 5 Xmodem Methode

1 Main und Backup Loaders

Standardmäßig wird der main loader für den Start genutzt, RouterBOARD Geräte verfügen jedoch auch noch über einen zweiten (als Backup) Bootloader, welcher genutzt wird, wenn der main loader nicht funktioniert. Es ist möglich, den Backup Loader über Konfigurationseinstellungen im RouterOS aufzurufen:

system routerboard settings set force-backup-booter=yes

es ist außerdem möglich, den Backup Booter zu nutzen, wenn man das Gerät mit dem gedrückten RESET Button hochfährt. Manchmal erhält RouterBOOT Firmware Upgrades (siehe Changelog). Es ist außerdem möglich, den main RouterBOOT upzugraden. Im Falles eines Fehlers kann man den Backup Booter für den Start des Geräts nutzen und den main loader downgraden. Für Upgrade Instruktionen folgt man der separaten Anleitung in Manual:Bootloader upgrade

2 RouterBOARD Reset Button

Der RouterBOOT Reset Button verfügt über drei Funktionen:

  • Hält man diesen während der Bootzeit gedrückt, bis die LED Lichter anfangen zu blinken und lässt den Button dann los, wird die RouterOS Konfiguration gelöscht (total 5 Sekunden)
  • Hält man ihn weitere 5 Sekunden, bis die LED Lichter normal leuchten und lässt den Button dann los, wird der CAP Modus aktiviert (total 10 Sekunden)
  • Wieder weitere 5 Sekunden gedrückt, bis die LEDs ausgehen und man den Button dann loslässt, wird das RouterBOARD nach einem Netinstall Server suchen (insgesamt also 15 Sekunden)

Hinweis: Wenn man den Button drückt, bevor man das Gerät an eine Stromquelle anschließt, wir zusätzlich zu allem oben genannten der Backup RouterBOOT genutzt. Um die oben genannten Schritte ohne den Backup Loader durchzuführen, drückt man den Button nachdem das Gerät mit einer Stromquelle verbunden wurde.

3 Konfiguration

Für RouterBOARD Geräte die über die Funktion eines seriellen Konsolen Konnektor verfügen, ist es möglich, Zugriff auf das RouterBOOT loader Konfigurations-Menü zu erhalten. Das benötigte Kabel wird im Serial console Manual beschrieben. RouterBOARD serieller Port ist konfiguriert auf  115200bit/s, 8 data bits, 1 stop bit, no parity. Es wird empfohlen, den Hardware flow control zu deaktivieren.

Dieses Beispiel zeigt das Menü, welches auf RouterBOOT 3.19 verfügbar:

RouterBOOT booter 3.19

CCR1009-8G-1S-1S+

CPU frequency: 1200 MHz
  Memory size: 2048 MiB
    NAND size: 128 MiB
    NAND partitions: 2

Press any key within 2 seconds to enter setup

RouterBOOT-3.19
What do you want to configure?
   d - boot delay
   k - boot key
   s - serial console
   n - silent boot
   o - boot device
   f - cpu frequency
   r - reset booter configuration
   e - format nand
   w - repartition nand
   y - active partition
   g - upgrade firmware
   i - board info
   p - boot protocol
   b - booter options
   t - do memory testing

Die Optionen sind selbsterklärend.

letter description explanation
d boot delay Verzögert den Start von RouterOS um Interfaces die Initialisierung zu erlauben
k boot key Der Button, welcher das Konfigurations-Menü öffnet
s serial console Setzt die Baud-Rate des seriellen Ports
n silent boot Unterdrückt jede Ausgabe auf dem seriellen Port, für den Fall, das daran ein Gerät verbunden ist (wie z.B. ein GPS Gerät oder Temperatur Monitor)
o boot device Erlaubt die Aktivierung von Netinstall booting
f cpu frequency Erlaubt die Anpassung von CPU/Memory Frequenzen
r reset booter configuration Setzt die Einstellungen in diesem Menü zurück.Warnung, hier erfolgt keine Bestätigung!
e format nand Zerstört alle Daten auf dem NAND, inklusive der RouterOS Konfigurations/Lizenz
w repartition nand Für mehr Infos sollte man das Manual:Partitions zu Rate ziehen
y active partition Auswahl der aktiven Partition von welcher versucht werden soll, RouterOS zu laden
g upgrade firmware Erlaubt das Upgrade der RouterBOOT Version über das Netzwerk oder das XModem Protokoll
i board info
p boot protocol
b booter options Auswahl welcher Bootloader standardmäßig genutzt werden soll
t do memory testing Sehr einfaches Speicher-Test-Tool

Drückt man das passende Tastatur-Zeichen gibt einem eine Liste mit weiteren Optionen aus, welche unten ersichtlich sind:

# d - boot delay:

Select boot delay:
   1 - 1s
 * 2 - 2s
   3 - 3s
   4 - 4s
   5 - 5s
   6 - 6s
   7 - 7s
   8 - 8s
   9 - 9s

# k - boot key:

Select key which will enter setup on boot:
 * 1 - any key
   2 - <Delete> key only

# s - serial console:

Select baud rate for serial console:
 * 1 - 115200
   2 - 57600
   3 - 38400
   4 - 19200
   5 - 9600
   6 - 4800
   7 - 2400
   8 - 1200
   9 - off

# n - silent boot:

Silent boot:
   0 - off
 * 1 - on

# o - boot device:

Select boot device:
   e - boot over Ethernet
 * n - boot from NAND, if fail then Ethernet
   1 - boot Ethernet once, then NAND
   o - boot from NAND only
   b - boot chosen device
   f - boot Flash Configure Mode
   3 - boot Flash Configure Mode once, then NAND


# f - cpu frequency:

Select CPU frequency:
   a -  200MHz
   b -  400MHz
   c -  600MHz
   d -  800MHz
   e - 1000MHz
 * f - 1200MHz

# r - reset booter configuration:

# e - format nand:

Do you realy want to format your storage device?
that would result in losing all your data
type "yes" to confirm: 

# w - repartition nand:

Select parititon count:
   1 - partition
 * 2 - partitions
   3 - partitions
   4 - partitions

# y - active partition:

Select active partiton:
 * 0 - partition
   1 - partition

# g - upgrade firmware:

Upgrade firmware options:
   e - upgrade firmware over ethernet
   s - upgrade firmware over serial port

# i - board info:

Board Info:

        Board type: CCR1009-8G-1S-1S+
     Serial number: 48FF01DDE6FD
  Firmware version: 3.19
     CPU frequency: 1200 MHz
       Memory size: 2048 MiB
         NAND size: 128 MiB
        Build time: 2014-09-23 15:02:34
  eth1 MAC address: 00:0C:42:00:BE:4A
  eth2 MAC address: 00:0C:42:00:BE:4B
  eth3 MAC address: 00:0C:42:00:BE:4C
  eth4 MAC address: 00:0C:42:00:BE:4D
  eth5 MAC address: 00:0C:42:00:BE:4E
  eth6 MAC address: 00:0C:42:00:BE:4F
  eth7 MAC address: 00:0C:42:00:BE:50
  eth8 MAC address: 00:0C:42:00:BE:51
  eth9 MAC address: 00:0C:42:00:BE:52
 eth10 MAC address: 00:0C:42:00:BE:53

# p - boot protocol:

Choose which boot protocol to use:
 * 1 - bootp protocol
   2 - dhcp protocol

# b - booter options:

Select which booter you want to load:
 * 1 - load regular booter
   2 - force backup-booter loading

#t - do memory testing:

launches built in memory test!

# x - exit setup:

Exit bios configuration menu and continues with system startup.

4 Einfaches Upgrade

RouterBOOT kann von RouterOS aus wie folgt upgegraded werden:

  • Indem man das folgende Kommando ausführt /system routerboard upgrade
  • Neustart des Routers, damit das Upgrade angewendet wird (/system reboot)

Hinweis: Wenn man eine andere Version installieren möchte, die nicht in der „routerboard.npk“ inkludiert ist, uploadet man die aktuellste RouterBOOT Firmware auf den FTP des Routers. Die aktuellste Firmware ist auf routerboard.com verfügbar. Danach folgt man den oben genannten Schritten.

4.1 RouterBOOT Version prüfen

Dieses Kommando zeigt die aktuelle RouterBOOT Version des eigenen Geräts und das verfügbare Upgrade, welches entweder in der routerboard.npk enthalten ist oder man eine zum Gerät passende FWF Datei geuploadet hat:

[admin@MikroTik] > system routerboard print 
       routerboard: yes
             model: "750"
     serial-number: "1FC201DD513B"
  current-firmware: "2.18"
  upgrade-firmware: "2.20"
[admin@MikroTik] > 

In diesem Fall sieht man, dass in der aktuellen RouterOS Version eine neuere Version der Bootloader Firmware verfügbar ist.

Hinweis: Der Downgrade ist genauso möglich, wenn man eine ältere *.FWF Datei uploaded.

5 Xmodem Methode

Wenn es keine IP Verbindung auf das RouterBOARD gibt, kann man den seriellen Konsolen XMODEM Transfer nutzen, um eine FWF Datei auf den Router zu senden, während eine Verbindung via serieller Konsole besteht. Aus dem Bootloader Menü heraus ist es möglich, mit dieser Methode ein Upgrade der Firmware durchzuführen. Diese Methode ist die letzte Möglichkeit eine Verbindung herzustelle und man sollte diese nur nutzen, wenn die zwei vorigen Methoden nichtmehr verfügbar sind.

[ Top | Back to Content ]

Veröffentlicht unter RouterBOOT | Verschlagwortet mit , , , , , , , , , , , | Hinterlasse einen Kommentar

CHR/CloudHostedRouter

Manual:CHR


Manual:CHR – CloudHostedRouter

Inhalt

  • 1 Cloud Hosted Router
  • 2 Systemvoraussetzungen
  • 3 CHR Installation
    • 3.1 Installations-Ablauf CHR
    • 3.2 CHR Installation

      • 3.2.1 VMWare Fusion / Workstation
      • 3.2.2 VirtualBox
      • 3.2.3 Hyper-V
      • 3.2.4 Amazon Web Services (AWS)
  • 4 CHR Lizenzierung
    • 4.1 Bezahlte Lizenzen

      • 4.1.1 p1
      • 4.1.2 p10
      • 4.1.3 p-unlimited
    • 4.2 Kostenlose Lizenzen

      • 4.2.1 free
      • 4.2.2 60-day trial
  • 5 Bezug der Lizenz

    • 5.1 Upgrade einer kostenlosen zu p1 oder höher
    • 5.2 Upgrade von einer höheren aufwärts
  • 6 Lizenz Update
  • 7 Fehlersuche
    • 7.1 Ausführung auf VMware ESXi
      • 7.1.1 MTU ändern
    • 7.2 Bridge unter Linux nutzen
    • 7.3 Packets not passing from guests

1 Cloud Hosted Router

Cloud Hosted Router (CHR) ist eine RouterOS Version welche für den Betrieb als virtuelle Maschine konzipiert ist. Sie unterstützt die x86 64-Bit Architektur und kann auf den bekanntesten Hypervisoren (mikrotik-blog.de: https://de.wikipedia.org/wiki/Hypervisor) wie z.B. VMWare, Hyper-V, VirtualBox, KVM und anderen genutzt werden. CHR verfügt standardmäßig unbeschränkt über alle Funktionen von RouterOS aber unterscheidet sich im Lizenzierungsmodell von den anderen RouterOS Versionen.

2 Systemvoraussetzungen

Minimal-Anforderung ans System:

  • 64bit CPU mit Virtualisierungs-Unterstützung
  • 128 MB oder mehr RAM für die CHR Instanz
  • 128 MB Festplattenplatz, für die virtuelle CHR Festplatte

CHR wurde auf den folgenden Plattformen getestet:

  • VirtualBox 5 auf Linux und OS X
  • VMWare Fusion 7 und 8 auf OS X
  • Qemu 2.4.0.1 auf OS X
  • Hyper-V auf Windows Server 2012 (aktuell wird nur die virtuelle Maschine von Hyper-V (Generation 1) unterstützt)

Hinweis: Die Minimal-Anforderung sind 128MB RAM, um den Selbst-Installations-Prozess zu vollenden.

3 CHR Installation

Warnung: Die minimal unterstützte CHR Version ist 6.34

Es werden vier verschiedene virtuelle Disk Images zur Auswahl gestellt:

  • RAW disk image (.img file)
  • VMWare disk image (.vmdk file)
  • Hyper-V disk image (.vhdx file)
  • VirtualBox disk image (.vdi file)

Hinweis: Es handelt sich um Disk Images, also nicht um virtuelle Maschinen Appliances, die importiert werden können.

3.1 Installations-Ablauf CHR

  • Schritt1: Download des virtuellen Disk Images für den eigenen Hypervisor
  • Schritt2: Erstellen einer virtuellen Gast-Maschine
  • Schritt3: Man verwendet die zuvor heruntergeladene Image Datei als virtuelles Laufwerk
  • Schritt4: Man startet die virtuelle CHR Maschine als Gast
  • Schritt5: Login in den neuen CHR. Default Nutzer ist ‚admin‘, ohne Passwort

3.2 CHR Installation

3.2.1 VMWare Fusion / Workstation
3.2.2 VirtualBox
3.2.3 Hyper-V
3.2.4 Amazon Web Services (AWS)

4 CHR Lizenzierung

Der CHR verfügt über 4 Lizenz-Level:

  • free (kostenlos)
  • p1 perpetual-1 (ohne Ablaufdatum)($45)
  • p10 perpetual-10 (ohne Ablaufdatum) ($95)
  • p-unlimited perpetual-unlimited (ohne Ablaufdatum-unbegrenzt)($250)

Die kostenlose 60-Tage Probier-Lizenz ist für alle Lizenzstufen verfügbar.  Um diese zu bekommen benötigt man ein Konto auf MikroTik.com da die komplette Lizenzverwaltung dort stattfindet.

Perpetual ist eine Lizenz auf Lebenszeit (einmal kaufen, für immer nutzen). Es ist möglich, eine perpetual Lizenz auf eine andere CHR Instanz zu übertragen.

Eine laufende CHR Instanz zeigt einem den Zeitpunkt an, wenn Sie eine Verbindung zu Mikrotiks Verwaltungsserver aufnehmen muss, um die Lizenz zu erneuern. Wenn es der CHR Instanz nicht möglich ist, die Lizenz zu erneuern, wird sich die CHR Instanz verhalten, als ob die Testphase abgelaufen wäre und erlaubt dann keine Upgrades auf neuere RouterOS Versionen mehr.

License Speed limit Price
Free 1Mbit/s Kostenlos
P1 1Gbit/s $45
P10 10Gbit/s $95
P-Unlimited Unlimited $250

4.1.1 p1

p1 (perpetual-1) Lizenz Level erlaubt der CHR eine unbegrenzte Laufzeit. Auf jedem Interface ist Sie auf 1Gbit/s im Upload begrenzt. Alle anderen von CHR zur Verfügung gestellten Funktionen sind nicht eingeschränkt. Es ist möglich, von p1 auf p10 oder p-unlimited Upzugraden. Nach dem das Upgrade käuflich erworben wurde, wird die Lizenz, für den späteren Gebrauch, im Konto zur Verfügung gestellt.

4.1.2 p10

p10 (perpetual-10) Lizenz Level erlaubt der CHR eine unbegrenzte Laufzeit. Auf jedem Interface ist Sie auf 10Gbit/s im Upload begrenzt. Alle anderen von CHR zur Verfügung gestellten Funktionen sind nicht eingeschränkt. Es ist möglich, von p10 auf p-unlimited Upzugraden. Nach dem das Upgrade käuflich erworben wurde, wird die Lizenz, für den späteren Gebrauch, im Konto zur Verfügung gestellt.

4.1.3 p-unlimited

Das p-unlimited (perpetual-unlimited) Lizenz Level erlaubt der CHR eine unbegrenzte Laufzeit. Es ist der höchste Lizenz-Rang („Tier“) und es gibt keinerlei Beschränkungen.

4.2 Kostenlose Lizenzen

Es gibt verschiedene Optionen um CHR kostenfrei auszuprobieren.

4.2.1 free

Das free (=kostenlos) Lizenz Level erlaubt der CHR eine unbegrenzte Laufzeit. Auf jedem Interface ist Sie auf 1Mbit/ss im Upload begrenzt. Alle anderen von CHR zur Verfügung gestellten Funktionen sind nicht eingeschränkt. Um diese zu nutzen, muss man nur die Disk Image Datei von Mikrotiks Download Seite herunterladen und einen virtuellen Gast erstellen.

4.2.2 60-day trial

Zusätzlich zur kostenlosen, aber eingeschränkten Free Installation, kann man außerdem die P1/P10/PU Lizenzen, mit erhöhten Geschwindigkeiten pro Interface, in einem Testzeitraum von 60 Tagen testen.

Hierfür wird ein Konto auf MikroTik.com benötigt. Danach kann man das anvisierte Lizenz Level für den Testzeitraum von 60 Tagen über den Router, der die RouterID dem Konto zuweist und somit den Erwerb der Lizenz, über das Konto, ermöglicht. Alle zum Kauf angeboten Lizenzstufen stehen als Testlizenzen zur Verfügung. Der Testzeitraum von 60 Tagen beginnt am Tag des Erwerbs. Nachdem der Testzeitraum abgelaufen ist, wird das Lizenz-Menü anfangen „Limited Upgrades“ anzuzeigen. RouterOS kann ab diesem Zeitpunkt nicht länger mit Updates versorgt werden.

Wenn man plant, die ausgewählte Lizenz zu kaufen, muss dies innerhalb des 60tägigen Testzeitraums geschehen. Wenn der Testzeitraum endet und innerhalb von 2 weiteren Monaten kein Kauf erfolgt, wird das Gerät nicht länger im MikroTik Konto angezeigt. Danach muss man sich eine neue CHR Installation erstellen um einen Kauf im entsprechenden Zeitfenster durchzuführen.

Um eine Testlizenz anzufordern, muss man das folgende Kommando in der Kommandozeile des CHR Geräts eingeben: „/system license renew„. Man wird dann nach Nutzername und Passwort des eigenen Mikrotik.com Kontos gefragt.

5 Bezug der Lizenzen

Nach dem erstmaligen Setup wird der CHR Instanz eine free Lizenz zugewiesen. Von hier aus ist es möglich, die Lizenz auf ein höheres Level upzugraden. Wenn man einmal über die Testlizenz verfügt, wird alles weitere bzgl. Lizenz auf dem Account Server verwaltet. Dort ist es dann möglich, die Lizenz auf einen höheren Rang upzugraden bis zur man die  p-unlimited Stufe erreicht hat.

5.1 Upgrade einer kostenlosen zu einer p1 oder höher

Jedes erste Upgrade vom free Rang zu einer höheren Lizenzstufe erfordert die Registrierung der CHR Instanz auf dem Account Server. Dafür muss man seinen MikroTik.com Nutzernamen, Passwort und das gewünschte Lizenz Level, welches man erwerben will. Anschließend wird dem eigenen Konto, auf dem Mikrotik Server, eine CHR ID hinzugefügt, sowie eine 60 Tage gültige Testphase für diese ID erstellt. Es gibt zwei Wege, um eine Lizenz zu erhalten – entweder man nutzt die Winbox oder das RouterOS Kommandozeilen-Interface:

Wenn man die WinBox nutzt (System -> License menu):

chr_licence_01

chr_licence_02

Using command line interface:

[admin@MikroTik] > /system license print 
  system-id: 6lR1ZP/utuJ
      level: free

[admin@MikroTik] > /system license renew 
account: mymikrotikcomaccount
password: *********************
level: p1 
  status: done
  
[admin@MikroTik] > /system license print 
        system-id: 6lR1ZP/utuJ
            level: p1
  next-renewal-at: jan/10/2016 21:59:59
      deadline-at: feb/09/2016 21:59:59

Um ein höheres Test-Level zu erhalten, setzt man eine neue CHR Instanz auf, erneuert die Lizenz und wählt das gewünschte Level aus.

Um ein Upgrade der Testlizenz auf eine Vollversion durchzuführen loggt man sich auf dem MikroTik.com Account Server ein und wählt ‚all keys‘ in der Cloud Hosted Router (CHR) Rubrik aus:

800px-chr_keys_01

Angezeigt wird dann eine Liste der eigenen CHR Maschinen und Lizenzen: 800px-chr_keys_02

Um ein Upgrade von der Testlizenz auf die Vollversion durchzuführen, klickt man ‚Upgrade‘, wählt das gewünschte Lizenz Level aus (dieses kann sich vom Level der Testlizenz unterscheiden) und klickt ‚Upgrade key‘:

Account server

Man wählt die Zahlungsmethode aus:

Account server

Es ist möglichüber einen Konto Restbetrag (deposit), Kredit Karte (KK), PayPal oder einen Restbetrag (Prepaid) Schlüssel (wenn man einen hat).

5.2 Upgrade von einer höheren aufwärts

Aktuell ist nur ein Upgrade zu einem höheren Rang möglich (nur bei bezahlten Lizenzen) und dies wird auf dem Account Server vollzogen. Damit der Wechsel auf dem Router umgesetzt wird wird das renew Kommando genutzt. Wenn der Router bereits über eine beliebige Testversion oder eine bezahlte Lizenz verfügt, ist die Lizenzstufe, die man für den renew Befehl festgelegt, nicht mehr wichtig, sondern wird von den auf dem Account Server hinterlegten Daten festgelegt. Die möglichen Upgrades sind die folgenden:

  • p1 Upgrade auf p10
  • p1 Upgrade auf p-unlimited
  • p10 Upgrade auf p-unlimited

6 Lizenz Update

Im ‚/system license‘ Menü zeigt der Router an, wann next-renewal-at ist und er sich mit dem Lizenzserver von Mikrotik verbindet (licence.mikrotik.com). Der Kommunikationsversuch findet einmal pro Stunde nach dem dem Datum welches über next-renewal-at  ausgegeben wird und wird nicht aufhören bist der Server mit einem Fehler antwortet. Wenn das deadline-at Datum erreicht ist ohne dass es einen erfolgreichen Kontakt zum Account Server gab wird der Router als abgelaufen werten und wird zukünftige Software Updates nichtmehr durchführen. Der Router wird jedoch weiterhin mit dem selben Lizenz Rang (Tier) wie zuvor arbeiten.

7 Fehlersuche – Troubleshooting

7.1 Ausführung auf einer VMware ESXi

7.1.1 MTU ändern

VMware ESXi unterstützt eine MTU bis zu 9000 bytes. Um daraus einen Vorteil zu erhalten, muss man seine ESXi-Installation anpassen, um eine höhere MTU zu ermöglichen. Der virtuellen Ethernet-Schnittstelle, die nach der MTU-Änderung hinzugefügt wird, wird vom ESXi-Server ordnungsgemäß die Weitergabe von Jumbo-Frames erlaubt. Interfaces, welche vor der MTU-Änderung auf dem ESXi-Server hinzugefügt wurden, werden vom ESXi-Server von der Weitergabe abgehalten (es wird weiterhin die alte MTU als maximale mögliche Größe gemeldet). Um dem vorzubeugen, muss man die Interfaces zu den virtuellen Gästen hinzufügen.

Beispiel. Es gibt zwei Interfaces, welche einem ESXi Gast hinzugefügt wurden. Die automatisch erkannte MTU auf den Interfaces zeigt die Größe an wie Sie zu der Zeit war, als das Interface hinzugefügt wurde:

[admin@chr-vm] > interface ethernet print 
Flags: X - disabled, R - running, S - slave 
 #    NAME           MTU MAC-ADDRESS       ARP       
 0 R  ether1        9000 00:0C:29:35:37:5C enabled   
 1 R  ether2        1500 00:0C:29:35:37:66 enabled

7.2 Bridge unter Linux nutzen

Wenn Linux-Bridge IGMP-Snooping unterstützt und es Probleme mit IPv6-Datenverkehr gibt, ist es erforderlich, diese Funktion zu deaktivieren, da sie mit MLD-Paketen interagiert (Multicast) und sie nicht weiterleitet.

echo -n 0 > /sys/class/net/vmbr0/bridge/multicast_snooping

7.3 Nicht erfolgte Weiterleitung von Paketen im Gast-Modus

Das Problem: Nach der Konfiguration der Software-Interfaces (VLAN, EoIP, bridge, etc.) auf dem Gast CHR stoppt die Datenweitergabe zu Zielen in der Außenwelt, also hinter dem Router.

Lösung: Man muss seine VMS (Virtualization Management System) Sicherheitseinstellungen prüfen, ob anderen MAC Adressen erlaubt werden, wenn Pakete mit VLAN Tags der Durchgang erlaubt wird. Man passt die Sicherheitseinstellungen entsprechend den eigenen Bedürfnissen an, wie zum Beispiel MAC-Spoofing oder bestimmte MAC-Adressbereiche. Für VLAN-Schnittstellen können in der Regel zulässige VLAN-Tags oder VLAN-Tag-Bereiche definiert werden.

[ Top | Back to Content ]

Veröffentlicht unter CHR | Verschlagwortet mit , , , , , , , , , , , , , , , , | Hinterlasse einen Kommentar

Mikrotik Produktnamen und ihre Bedeutung/Product Naming

Manual:Product Naming


Manual:Produktbezeichnung

Inhalt

  • 1 Details der Namensgebung von RouterBOARD Produkten
    • 1.1 Board Namen
    • 1.2 Board Funktionen
    • 1.3 Integrierte Wlan Details
    • 1.4 Gehäuse-Typen
    • 1.5 Speziellere Typen von OUT -Gehäusen sind:
    • 1.6 Beispiel
  • 2 CloudCoreRouter Details der Namensgebung
  • 3 CloudRouterSwitch Details der Namensgebung

1 Details der Namensgebung von RouterBOARD Produkten

RouterBOARD (Kurzversion RB)

<board name> <board features>-<built-in wireless> <wireless card features>-<connector type>
-<enclosure type>

1.1 Board Namen

Aktuell gibt es drei Typen von Board-Bezeichnungen:

  • Dreistellige Nummer
    • Die erste Stelle steht für die Serie
    • Die zweite Stelle gibt die kabelgebundenen Interfaces an (Ethernet, SFP, SFP+)
    • Die dritte Stelle gibt die kabellosen Interfaces an (integriert, mPCI und mPCIe Slots)
  • Word – Aktuell werden die folgenden Markennamen genutzt: OmniTIK, Groove, SXT, SEXTANT, Metal. Wenn es an der Hardware grundlegende Veränderungen gibt, (wie z.B. eine neue CPU) wird die Änderungsversion am Ende hinzugefügt (z.B. r2, r3 usw)
  • Davon ausgenommen Bezeichnungen – Die 600, 800, 1000, 1100, 1200, 2011 Boards stehen einzigartig für ihre Serie oder verfügen über mehr als 9 kabelgebundene Interfaces, der Name wurde der Einfachheit halber auf die vollen „hundert“ erhöht oder entsprechend dem Entwicklungsjahr bezeichnet.

1.2 Board Funktionen

Die Board Funktionen folgen direkt nach der Board Namen Rubrik (kein Freizeichen oder Bindestrich), ausser wenn der Board Name ein Wort ist, dann werden die Board Funktionen mit Leerzeichen separiert.
Aktuell genutzte Funktionen (die Liste entspricht der Reihenfolger ihrer Nutzung):

  • U – USB
  • P – power injection with controller
  • i – single port power injector without controller
  • A – Mehr Speicher/RAM (und normalerweise ein höheres Lizenz-Level)
  • H – leistungsfähigere CPU
  • G – Gigabit (Kann „U“,“A“,“H“ einschließen, wenn es nicht mit „L“ genutzt wird)
  • L – light Edition
  • S – SFP port (legacy usage – SwitchOS devices)
  • e – PCIe Interface Erweiterungskarte
  • x<N> – N steht für die Anzahl der CPU Kerne ( x2, x16, x36 etc)
  • R – MiniPCI oder MINIPCIe Slot

1.3 Integrierte Wlan Details

Wenn das Board über eine integrierte Wlan-Schnittstelle verfügt, werden alle Funktionen im folgenden Format dargestellt::

<band><power_per_chain><protocol><number_of_chains>

  • Band
    • 5 – 5Ghz
    • 2 – 2.4Ghz
    • 52 – Dualband 5Ghz und 2.4Ghz
  • power_per_chain – Leistung pro Chain

    • (not used) – „Normal“ – <23dBm at 6Mbps 802.11a; <24dBm at 6Mbps 802.11g
    • H – „High“ – 23-24dBm at 6Mbps 802.11a; 24-27dBm at 6Mbps 802.11g
    • HP – „High Power“ – 25-26dBm 6Mbps 802.11a; 28-29dBm at 6Mbps 802.11g
    • SHP – „Super High Power“ – 27+dBm at 6Mbps 802.11a; 30+dBm at 6Mbps 802.11g
  • Protokoll
    • (nicht gebraucht) – für Karten, die nur 802.11a/b/g unterstützen
    • n – für Karten mit 802.11n Unterstützung
    • ac – für Karten mit 802.11ac Unterstützung
  • number_of_chains – Anzahl der Chains

    • (not used) – single chain
    • D – dual chain
    • T – triple chain
  • connector type – Verbindungstypen der Karten mit dem Board

    • (nicht gebraucht) – nur eine Verbindungsoption auf dem Modell
    • MMCX – MMCX Verbindungstyp (mikrotik-blog.de: dieser Verbindungstyp ist unserer Meinung nach stabiler und fester in der Verbindung, als u.FL. Wir würden diesen bevorzugen. Funktional sind beide.)
    • u.FL – u.FL Verbindungstyp

1.4 Gehäuse-Typen

  • (not used) – main type of enclosure for a product
  • BU – board unit (no enclosure) – for situation when board-only option is required, but main product already comes in the case
  • RM – rack-mount enclosure
  • IN – indoor enclosure
  • EM – extended memory
  • LM – light memory
  • BE – black edition case
  • TC – Tower (vertical) case
  • OUT – outdoor enclosure

1.5 Speziellere Typen von OUT-Gehäusen sind:

  • SA – =Sektor Antennen Gehäuse (für SXT)
  • HG – High-Gain (=hoher Gewinn) Antennengehäuse (für SXT)
  • BB – BaseBox Gehäuse (für RB911)
  • NB – NetBox? Gehäuse (für RB911)
  • NM – NetMetal? Gehäuse (für RB911)
  • QRT – QRT Gehäuse (für RB911)
  • SX – Sextant Gehäuse (für RB911,RB711)
  • PB – PowerBOX Gehäuse (für RB750P, RB950P)

1.6 Beispiel

Im folgenden eine Übersetzung einer RouterBOARD-Bezeichnung anhand des RB912UAG-5HPnD

  • RB = RouterBOARD
  • 912 – 9te Serie des Boards, mit 1 Kabelgebundenen Interface und 2 Wlan Interfaces (integriert und miniPCIe)
  • UAG – verfügt über einen USB Port, mehr Speicher und Gigabit Ethernet Port
  • 5HPnD – Verfügt über eine integrierte 5GHz High Power Dual chain Wlan-Karte mit der Unterstützung von 802.11n.

2 CloudCoreRouter Details der Namensgebung

CloudCoreRouter (Kurzversion CCR) Bezeichnungen bestehen aus:

<4 digit number>-<list of ports>-<enclosure type>

  • 4 digit number – Vierstellige Nummer

    • Die erste Stelle steht für die Serie
    • Die zweite Stelle ist (reserved)
    • Die dritte und vierte Stelle stehen für Anzahl an CPU Kernen auf dem Gerät
  • list of ports – Liste der Ports

    • -<n>G – Anzahl an Gigabit Ethernet Ports
    • -<n>S – Anzahl an SFP Ports
    • -<n>S+ – Anzahl an SFP+ Ports

3 CloudRouterSwitch Details der Namensgebung

CloudRouterSwitch (Kurzversion CRS) Bezeichnungen bestehen aus:

<3 digit number>-<list of ports>-<built-in wireless card>-<enclosure type>

  • 3 digit number – Dreistellige Nummer

    • Die erste Stelle steht für die Serie
    • Die zweite und dritte Stelle steht für die Anzahl an kabelgebundenen Interface (Ethernet, SFP, SFP+)
  • list of ports – Liste der Ports

    • -<n>G – Anzahl an Gigabit Ethernet Ports
    • -<n>S – Anzahl an SFP Ports
    • -<n>S+ – Anzahl an SFP+ Ports

[ Top | Back to Content ]

Veröffentlicht unter Produktbezeichnung | Verschlagwortet mit , , , , , , , , , , , | Hinterlasse einen Kommentar

Eingabe des RouterOS Lizenz-Schlüssels/Entering a RouterOS License key

Manual:Entering a RouterOS License key

Veröffentlicht unter Lizenzschlüssel in RouterOS eingeben | Verschlagwortet mit , , , , , , , , , , | Hinterlasse einen Kommentar

Purchasing a License for RouterOS/Der Kauf einer Lizenz für RouterOS

Manual:Purchasing a License for RouterOS


Manual:  Der Kauf einer Lizenz für RouterOS

(Hinweis von Mikrotik-Blog.de: Der Kauf der Lizenzen ist natürlich auch direkt über Mikrotik möglich. Es sollten jedoch immer Preise mit denen von deutschen Distributoren verglichen werden. Oftmals sind diese günstiger.)

Als erstes sollte man sich eine Konto auf Account Server erstellen. Dies kann auf der Hauptseite von mikrotik.com durchgeführt werden. Die Anmeldung ist ein einfacher Ablauf und die Anmeldung ist kostenlos.

Wichtig! Vor dem Kauf eines Schlüssels muss man RouterOS installieren. Es wird eine SoftID generiert, die beim Kauf benötigt wird. Bevor man die SoftID im Bestellformular eingibt, sollte man sicherstellen, dass diese sich nicht auf dem Router geändert hat. Nach der Installation hat man 24 Stunden Zeit, um einen Schlüssel einzugeben. Um Zeit zu „sparen“ sollte man während man den Router nicht benötigt, diesen ausschalten, da dann der Timer angehalten wird.

Nachdem man sich einen erstellt hat, beginnt man mit dem Login. Im folgenden der beispielhafte Ablauf:

purchase1

Auf das eigene Konto einloggen

purchase2

Klick auf Purchase a Key

purchase3

Man wählt das License Level und die Anzahl der Lizenzen die man benötigt aus

purchase4

Man gibt nun die SoftIDs ein und wählt die Systemart aus. Hier ist zu beachten, dass einem die SoftID nach der Installation von RouterOS angezeigt wird. Die Systemart ist eine Auswahl zwischen RouterBOARD und X86. Grundsätzlich gilt, dass wenn man über ein RouterBOARD (TM) Gerät verfügt, man dann RouterBOARD auswählt. Bei allen anderen wählt man X86.
ANMERKUNG: Bei älteren RouterBOARD 230 Modellen handelt es sich ebenso um X86 Geräte.

purchase5

Man klickt auf die Bezahlung per Kreditkarte und wird auf die Zahlungsseite der Bank weitergeleitet

Auf der Bankseite wird man nach der Credit Card Number, CVC/CVV code, Ablaufdatum der Kreditkarte und nach dem Namen der Ka. Die CVC/CVV Code kann auf der Rückseite der Karte gefunden werden und dabei handelt es sich um einen dreistelligen Code.Nachdem man alle Details abgegeben und die Informationen abgeschickt hat, wird die Kreditkarte geladen. Den Browser sollte man dabei nicht schließen, ebenso sollte man nichts drücken, bis der Prozess beendet ist. Danach geht einem der Schlüssel in einer E-Mail zu und wird zudem in der Rubrik“work with keys“ angezeigt.

Instruktionen, wie man diese Lizenz am Router einspielt, sind hier zu finden.

Veröffentlicht unter Lizenzkauf für RouterOS | Verschlagwortet mit , , , , | Hinterlasse einen Kommentar

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! 🙂
Veröffentlicht unter IPsec | Verschlagwortet mit , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , | Hinterlasse einen Kommentar

Lizenz

RouterOS Licensing – License


Manual: Lizenz

Inhalt

  • 1 RouterBOARD und PC Lizenzen
  • 2 CHR Lizenz
  • 3 Lizenz Levels
  • 4 Upgrading von RouterOS v3 (2009)
  • 5 Lizenz-Level ändern
  • 6 Nutzung der Lizenz
    • 6.1 Kann man die Festplatte formatieren oder re-flashen?
    • 6.2 Auf wievielen Computern kann man die Lizenz nutzen?
    • 6.3 Kann man die Festplatte temporär auch für etwas anderes als RouterOS nutzen?
    • 6.4 Kann man die Lizenz auf eine andere Festplatte übertragen?
    • 6.5 Was ist ein Ersatzschlüssel?
    • 6.6 Muss man den ganzen Schlüssel am Router eingeben?
    • 6.7 Kann man ein anderes Betriebssystem auf der Festplatte installieren und danach RouterOS?
    • 6.8 Kann man die Lizenz auf einem anderen System nutzen, wenn das eigene RouterBOARD defekt ist?
    • 6.9 Von Resellern bezogene Lizenzen
  • 7 Gekaufte Lizenzen und wie man damit umgeht
    • 7.1 Wo kann man RouterOS Lizenzschlüssel erwerben?
    • 7.2 Wenn man den Schlüssel woanders erworben hat
    • 7.3 Wenn man über eine Lizenz verfügt und diese auf einen anderes Konto übertragen will?
  • 8 Siehe auch

1 RouterBOARD und PC Lizenzen

RouterBOARD Geräte werden mit einer vorinstallierten RouterOS Lizenz aufgeliefert. Wenn man also ein RouterBOARD Gerät gekauft hat, muss bzgl. der Lizenz nichtsmehr getan werden.

Für x86 Systeme (z.B. PC’s ) muss man hingegen eine Lizenz erwerben.

Der Lizenzschlüssel ist ein Block aus Symbolen, welcher vom eigenen mikrotik.com Konto oder aus der erhaltenen E-Mail kopiert und auf dem Router eingefügt werden muss. Man kann diesen Schlüssel im Terminal oder über den Button „Paste key“ im Winbox license Menü einfügen. Danach startet man den Router neu und der Schlüssel ist im System hinterlegt.

Das RouterOS-Lizenzierungsschema basiert auf der SoftwareID-Nummer, die an das entsprechende Speichermedium (Festplatte, NAND) gebunden ist.

Das aktuelle Lizenz-Level kann man sich über die CLI System-Konsole ausgeben lassen:

[admin@RB1100] > /system license print 
    software-id: "43NU-NLT9"
         nlevel: 6
       features: 
[admin@RB1100] >
license_menu

oder vom entsprechenden Winbox oder Webfig Menü.

2 CHR Lizenz

Cloud Hosted Router (CHR) Lizenzen für virtuelle Maschinen werden nicht in Levels unterteilt. Für weitere Informationen siehe auch CHR manual.

3 Lizenz Level

Nach der RouterOS Installation läuft dieses im trial mode. Man hat dann 24 Stunden um sich für Level1 zu registrieren oder Level 3,4,5,6 käuflich zu erwerben und einen gültigen Schlüssel einzugeben.

Level 3 fungiert einzig als Wlan Client (Client oder CPE) Lizenz. Für x86 PC’s ist Level3 nicht einzeln käuflich erhältlich. Wenn man mehr als 100 Level3 Lizenzen benötigt, wendet man sich direkt an sales[at]mikrotik.com

Level 2 fungierte als Übergang für alte Lizenzformate (vor v2.8). Diese Lizenzen sind nicht mehr verfügbar und wenn man über eine dieser Lizenzen verfügt, wird diese zwar weiterhin funktionieren, aber um ein Upgrade durchzuführen muss man eine neue Lizenz kaufen.

In der folgenden Tabelle werden die Unterschieden zwischen den Lizenz-Leveln verdeutlicht.

Level number 0 (Testphase) 1 (Demo) 3 (WISP CPE) 4 (WISP) 5 (WISP) 6 (Controller)
Price Kein Schlüssel erforderlich Registrierung erforderlich volume only $45 $95 $250
Erstkonfigurations- Support 15 Tage 30 Tage 30 Tage
Wlan AP 24Std Testphase Ja Ja Ja
Wlan Client und Bridge 24Std Testphase Ja Ja Ja Ja
RIP, OSPF, BGP Protokolle 24Std Testphase Ja(*) Ja Ja Ja
EoIP Tunnel 24Std Testphase 1 Unbegrenzt Unbegrenzt Unbegrenzt Unbegrenzt
PPPoE Tunnel 24Std Testphase 1 200 200 500 Unbegrenzt
PPTP Tunnel 24Std Testphase 1 200 200 500 Unbegrenzt
L2TP Tunnel 24Std Testphase 1 200 200 500 Unbegrenzt
OVPN Tunnel 24Std Testphase 1 200 200 Unbegrenzt Unbegrenzt
VLAN Interfaces 24Std Testphase 1 Unbegrenzt Unbegrenzt Unbegrenzt Unbegrenzt
HotSpot aktive Nutzer 24Std Testphase 1 1 200 500 Unbegrenzt
RADIUS Client 24Std Testphase Ja Ja Ja Ja
Queues 24Std Testphase 1 Unbegrenzt Unbegrenzt Unbegrenzt Unbegrenzt
Web proxy 24Std Testphase Ja Ja Ja Ja
User manager aktive Verbindungen 24Std Testphase 1 10 20 50 Unbegrenzt
Anzahl von KVM Gästen keine 1 Unbegrenzt Unbegrenzt Unbegrenzt Unbegrenzt

(*) – BGP ist nur für RouterBOARDs in Lizenz Level 3 enthalten. Für andere Geräte wird Level 4 oder höher für BGP benötigt.

Gültig für alle Lizenzen:

  • verfallen nie
  • beinhalten 15-30 Tage freien Support über E-Mail.
  • Gebrauch einer unbegrenzten Anzahl an Interfaces
  • Jede Lizenz ist für eine Installation vorgesehen
  • Unbegrenzte Anzahl von Software Upgrades

4 Upgrading von RouterOS v3 (2009)

Mit RouterOS 3.25 und 4.0beta3 wurde ein neues SoftID Format eingeführt. Das Lizenz Menü zeigt sowohl die alte als auch die neue SoftID an. Auch wenn man ein Upgrade auf eine neue RouterOS Version vornimmt, wird RouterOS weiterhin so funktionieren, wie vorher. Um aber um einige der neuen Funktionen nutzen zu können, ist es ein LIZENZ UPDATE unabdingbar. Um dies durchzuführen, klickt man einfach den  „Update license key“ Button in der Winbox (aktuell geht das nur über die Winbox).

2009-05-21_1608

Die neuen SoftID’s liegen in der folgenden Form vor:  XXXX-XXXX (Vier Symbole, Bindestrich, vier Symbole).

Die folgenden Maßnahmen werden durchgeführt:

  1. Winbox kontaktiert www.mikrotik.com mit der alten SoftID
  2. www.mikrotik.com überprüft den Schlüssel, auf Grundlage der in der Datenbank hinterlegten Schlüssel-Daten
  3. Der Server generiert einen neuen Schlüssel als „Upgrade“ und setzt diesen dann das gleiche Konto, wie den alten.
  4. Die Winbox erhält den neuen Schlüssel und lizenziert den Router automatisch mit dem neuen Schlüssel.
  5. Ein neustart ist notwendig
  6. Neue RouterOS Funktionen sind verfügbar

Wichtiger Hinweis!: Wenn man diesen Button auch in v3.24 vorfindet, sollte man diesen nicht benutzen, da er nicht funktionieren wird.

Bevor man ein Downgrade von RouterOS vornimmt, muss man erst den alten Schlüssel anwenden, bevor man das Downgrade durchführt. Wenn RouterOS den neuen Schlüssel anwendet, wird der alte in einer Datei im Files Ordner gespeichert, damit man den alten Schlüssel jederzeit vorliegen hat.

Noch wichtiger: Man sollte niemals von v4.0b3 zu v3.23 oder älter ein Downgrade durchführe. Nur von v3.24 sollte man ein Downgrade durchführen, da man sonst das neue Format seines Schlüssels verliert.

5 Lizenz-Level ändern

  1. Es gibt keine Lizenz Level Upgrades, wenn man ein anderes Lizenz Level benötigt. In diesem Fall muss man sich das entsprechende Level käuflich erwerben. Man sollte vorsichtig sein, wenn man das erste Mal eine Lizenz kauft, damit man auch das für den entsprechenden Fall passende Lizenz Level erwirbt.
  2. Warum man das Lizenz-Level durch ein Upgrade der Lizenz ändern kann, lässt sich anhand eines Beispiels erklären: Den Motor eines Autos kann man nicht von 2L auf 4L Hubraum hochsetzen, indem man die Differenz bezahlt, weswegen es auch bei den Lizenz-Leveln nicht so einfach ist, die Levels zu wechseln. Diese Lizenz-Politik wird so von vielen Software-Unternehmen gehandhabt, weswegen es erforderlich ist, dass man mit Bedacht beim Kauf vorgeht. Nichtsdestotrotz wurden die Preise angepasst und verringert und das Zeitlimit von Software Updates wurde komplett entfernt.

6 Nutzung der Lizenz

6.1 Kann man die Festplatte formatieren oder re-flashen?

Formatieren oder das anfertigen und Verteilen eines Images der Festplatte mit Nicht-Mikrotik-Tools (wie z.B DD und Fdisk) zerstört die Lizenz. Es ist nicht zu empfehlen und der Mikrotik Support könnte die Anfrage nach einem Ersatzschlüssel ablehnen. Für diesen Zweck nutzt man am besten die von MikroTik bereitgestellten Tools Netinstall oder CD-install, welche in der Download Rubrik frei verfügbar sind.

6.2 Auf wievielen Computern kann man die Lizenz nutzen

Die RouterOS Lizenz kann nur in einem System genutzt werden, nicht gleichzeitig in mehreren Systemen. Diese ist an die Festplatte gebunden auf der Sie installiert wurde. Man hat jedoch die Möglichkeit, die Festplatte in ein anderes Computersystem zu integrieren. Die Lizenz ansich kann man jedoch nicht auf eine andere Festplatte transferieren oder die Festplatte formatieren oder überschreiben, ohne dass die RouterOS Lizenz verloren geht und man eine neue erwerben muss. Wenn man die Lizenz ausversehen unbrauchbar gemacht hat, kann man das Support-Team für weitere Hilfe kontaktieren.

6.3 Kann man die Festplatte temporär auch für etwas anderes als RouterOS nutzen?

Wie oben beschrieben geht das nicht, also nein.

6.4 Kann man die Lizenz auf eine andere Festplatte übertragen?

Wenn die aktuell genutzt Festplatte zerstört wurde oder nicht länger genutzt werden kann, ist es möglich, die Lizenz auf eine andere Festplatte zu transferieren. Hierfür muss man einen Ersatzschlüssel beantragen (siehe auch unten), welcher jedoch 10$ kostet.

6.5 Was ist ein Ersatzschlüssel?

Das ist ein spezieller Schlüssel, welcher vom Support Team zur Verfügung gestellt werden, wenn man aus Versehen seine Lizenz verloren hat. Der Support entscheidet dann darüber, ob für 10$ ein neuer ausgestellt wird, welcher dann dieselben Funktionen beinhaltet, wie der verlorene. Zu beachten ist, dass in manchen Fällen auch die Einsendung der alten Festplatte an den Support erforderlich ist, um den entsprechenden Fall eingehend zu prüfen um somit Missbrauch vorzubeugen.

Hinweis: Ausgestellt wird jeweils pro Original-Schlüssel nur ein Ersatzschlüssel. Eine zweimalige Nutzung eines Ersatzschlüssels ist nicht möglich. In Fällen, in denen der Ersatzschlüssel weg ist, muss ein neuer Schlüssel für das Gerät erworben werden.

6.6 Muss man den ganzen Schlüssel am Router eingeben?

Nein, es reicht, wenn man in kopiert und im Telnet Fenster einfügt oder ihn über das License Menü in der Winbox aktiviert.

Kopiervorgang im Telnet Fenster (oder im Winbox New Terminal),

pastelicense

Eine andere Möglichkeit besteht darin, im Winbox License Fenster auf System —> License zu klicken,

applylicensewinbox

6.7 Kann man ein anderes Betriebssystem auf der Festplatte installieren und danach RouterOS?

Nein, weil sobald man Formatierungs- oder Partitionierungswerkzeuge nutzt oder Tools, die etwas am MBR ändern, man die Lizenz verliert und man eine neue kaufen muss. Dieser Vorgang ist nicht umsonst (siehe auch Ersatzschlüssel weiter oben).

6.8 Kann man die Lizenz auf einem anderen System nutzen, wenn das eigene RouterBOARD defekt ist?

RouterBOARDs werden mit intergrierter Lizenz ausgeliefert. Diese Lizenz kann nicht auf ein anderes System übertragen werden, was auch Upgrades mit einbezieht, welche während der Laufzeit des RouterBOARDs eingespielt wurden.

6.9 Von Resellern bezogene Lizenzen

Die Schlüssel, die man von anderen Verkäufern oder Wiederverkäufern käuflich erwirbt, liegen nicht auf dem eigenen www.mikrotik.com Konto vor. Auf diesem liegen nur Lizenzen vor, die einem Mikrotik direkt verkauft hat. Es ist jedoch möglich, diese Schlüssel über den „Request key“ Link im eigenen Konto verfügbar zu machen, ggf . als Beleg oder für Upgrades (wenn verfügbar).

7 Käuflich erworbene Lizenzen und wie man mit diesen umgeht

7.1 Wo kann man RouterOS Lizenzschlüssel erwerben?

Über den Konto Server welcher über www.mikrotik.com verfügbar ist.

7.2 Wenn man den RouterOS Lizenzschlüssel woanders erworben hat?

Wenn man diesen woanders gekauft hat, kontaktiert für Unterstützung das entsprechende Unternehmen.

7.3 Wenn man über eine Lizenz verfügt und diese auf ein anderes Konto übertragen will?

Man kann Zugriffe auf Schlüssel anhand von Virtual Folders verwalten.

8 Siehe auch

Veröffentlicht unter Lizenz | Verschlagwortet mit , , , , , , , , , , , , , , , , , , , | Hinterlasse einen Kommentar