Recent am primit un request din partea unui client ce doreste migrarea infrastructurii din datacenter in mediul cloud din Azure. Acesta are 26 de tunele ipsec intre locatiile din tara si routerul din datacenter, iar majoritatea acestora detin routere Mikrotik (98%). Problema este ca Mikrotik suporta doar policy-based IPsec, iar in Azure este posibil doar un singur tunel de acest tip. Pentru a avea mai multe tunele trebuie apelat la route-based IPsec (în Azure putem crea 30 astfel de tunele).

Din fericire nu a fost necesar sa inlocuim routerele din locatiile remote ale clientului, deoarece avem un workaround. In esenta pe Mikrotik folosim tot policy-based, dar la exchange mode selectam IKEv2. Nu este necesar sa configuram un tunel ipsec bazat pe VTI/GRE/IPIP, deoarece facem un fel de policy-based routing. Oricum, Mikrotik nu suporta VTI, iar Azure nu accepta GRE sau IPIP (tunelare ip to ip). Acest workaround merge doar daca selectam IKEv2, fiind singura portita de compatibilitate cu Azure.

Configul pe Mikrotik din CLI este acesta (parametrii pot fi diferiti in functie de configul default disponibil in Azure):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
/ip ipsec profile #selectam algoritmii pentru faza 1
add dh-group=modp1024 enc-algorithm=aes-256 hash-algorithm=sha256 lifetime=8h \
    name="Azure"
/ip ipsec peer #configuram peer-ul si exchange-mode pentru faza 1, si anume ikev2
add address=<azure-public-ip> exchange-mode=ike2 local-address=<local-public-ip> \
    name="Azure" profile="Azure"
/ip ipsec proposal #configuram algoritmii pentru faza 2
add auth-algorithms=sha256 enc-algorithms=aes-256-cbc lifetime=7h30m name=\
    "Azure"
/ip firewall filter #configuram regulile de firewall pentru a permite trafic bidirectional intre mediul Azure si LAN-ul din spatele Mikrotik
add action=accept chain=input comment="Router fw input accept all active" \
    connection-state=established,related,untracked
add action=accept chain=input comment="Azure access to router" \
    dst-address=<mikrotik-ip> in-interface-list=WAN ipsec-policy=in,ipsec \
    src-address=<azure-subnet>
add action=drop chain=input comment="Router fw input drop invalid" \
    connection-state=invalid
add action=drop chain=input comment="Router fw input drop all not from LAN" \
    in-interface-list=!LAN
add action=accept chain=forward comment="Router fw IPsec in accept" \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment="Router fw IPsec out accept" \
    ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment=\
    "Router fw forward fasttrack" connection-state=established,related
add action=accept chain=forward comment="Router fw forward accept all active" \
    connection-state=established,related,untracked
add action=drop chain=forward comment="Router fw forward drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "Router fw forward drop all from WAN not dstnated" connection-nat-state=\
    !dstnat connection-state=new in-interface-list=WAN
/ip firewall mangle
add action=change-mss chain=forward comment="Azure" dst-address=\
    <azure-subnet> new-mss=1350 passthrough=yes protocol=tcp tcp-flags=syn
/ip firewall nat
add action=accept chain=srcnat comment="Azure" dst-address=\
    <azure-subnet> src-address=<local-subnet>
add action=masquerade chain=srcnat comment="Router fw masquerade" \
    ipsec-policy=out,none out-interface-list=WAN
/ip ipsec identity #configuram psk-ul pentru ipsec
add peer="Azure" secret="SuperStrongPassword123"
/ip ipsec policy #configuram traficul interesant pentru ipsec (sursa si destinatia traficului efectiv ce va trece prin tunel)
add dst-address=<azure-subnet> peer="Azure" proposal=\
    "Azure" sa-dst-address=<azure-public-ip> sa-src-address=\
    <local-public-ip> src-address=<local-subnet> tunnel=yes

Ne-am luat dupa urmatorul model:

In Azure trebuie tinut minte sa selectam IKEv2, optiunea fara rutare BGP si route-based IPsec, altfel nu va functiona.

Articol scris de Bogdan Curduban – Network Engineer