Suntem cu totii constienti de situatia existenta in lume din cauza pandemiei COVID-19 si masurile luate de companii pentru a ajuta personalul sa poata lucra de acasa. Acest lucru nu ar fi posibil fara Remote-Access VPN, de aceea este necesar sa trecem in revista subiectul pe intelesul tuturor discutand in special despre L2TP/IPsec.

Ce presupune?

Este un concept sustinut de numeroase implementari care asigura accesul utilizatorului la resursele companiei prin tunelarea traficului acestuia. Datele sunt trimise in mod criptat peste internet de la ip-ul public de acasa la ip-ul public al companiei. Validarea identitatii utilizatorului se face pe baza de user/parola configurata local pe VPN Server sau obtinute printr-un RADIUS/TACACS.
Tehnologiile folosite pentru securizare sunt IPsec, SSL/TLS, L2TP/IPsec, PPTP, SSH. Ceea ce noi stim sunt diversele implementari ale acestora. Exista o sumedenie de aplicatii vpn disponibile, unele sunt publice, putand fi implementate de oricine (de ex. Nord VPN), iar altele sunt enterprise, configurabile pe agregatoare VPN/routere/firewall (ex. Cisco Anyconnect).
De luat in considerare mai este si OpenVPN care foloseste tehnologii open-source (ex. OpenSSL encryption library, SSL v3/TLS v1). Poate fi configurat sa ruleze pe portul tcp 443, traficul VPN fiind atunci mascat de traficul standard HTTPS care se desfasoara cand ne conectam pe un website securizat. Este ideal pentru anonimitate peste internet in timp ce accesam reteaua companiei. Putem folosi AES pentru criptarea datelor si o securitate sporita. Singurul dezavantaj este necesitatea de a folosi aplicatii terte contra cost, revenind astfel la tehnologia pe care o sa o analizam.

L2TP over IPsec

O sa alegem L2TP over IPsec, deoarece este o tehnologie la indemana oricui si free, nefiind necesare licente, iar majoritatea vendorilor din retelistica fac disponibila implementarea. Nici securitatea nu este o problema, deoarece tehnologia IPsec permite alegerea unor algoritmi de criptare si integritate complexi. PPTP este gratuit si usor de implementat, dar prezinta probleme grave de securitate, de aceea optam pentru varianta ce prezinta un echilibru calitate/cost.
Este adevarat ca viteza de conexiune va fi mai mica din cauza dublei incapsulari (Layer2 tunneling si IPsec), dar in urma testelor pot spune ca nu se simte o diferenta considerabila in ce priveste functionalitatea serviciilor, ba chiar am efectuat un speed test in contextul rutarii intregului trafic prin l2tp si nu am observat probleme, cel mult reducerea vitezei cu 30%.

Setarea L2TP:
Echipamentul pe care vom configura L2TP va fi Mikrotik, unul din cele mai bune echipamente de networking din perspectiva calitate/pret.
Modul de conectare pe echipament va fi via Winbox.

Pasul I

Ne logam pe Winbox si pregatim un pool IP pe care il vom numi L2TP. Acesta va fi spatiul de adresare al clientilor l2tp.

IP -> Pool
Click pe + si trecem detaliile de mai jos, apoi OK:
Putem alege ce range dorim atata timp cat la final masca de retea va cuprinde range-ul respectiv.

Pasul II

Configuram profilul L2TP ducandu-ne la PPP, sub Profiles:
Completam cum urmeaza. Numele poate sa fie la alegere, Local Address este next-hop gateway pentru clientii vpn, iar la Remote Address selectam pool-ul L2TP. Restul ramane default:

Pasul III

Configuram utilizatorii, care pot fi:

  1. Locali
  2. via RADIUS (utilizatorii din grupul de vpn – daca exista o politica de access remote-vpn)
    Cei locali se configureaza simplu:
    PPP -> Secrets -> +
    Aici adaugam numele de utilizator si parola (sa satisfaca normele recomandate de Securitate), la Service trecem l2tp, iar la Profile cel pe care l-am creat la pasul 2.
    Acestia vor fi utilizatorii locali.
    Pentru utilizatorii RADIUS trebuie sa configuram conexiunea cu serverul respectiv. In meniul Mikrotik dam click pe RADIUS -> +
    Aici avem configurat profilul RADIUS. Trebuie sa completam urmatoarele:
    Serviciul este ppp (Layer 2 tunnel, point to point protocol), la Domain este completat domeniul retelei folosit in Companie, la Address am trecut ip-ul AD-ului unde ruleaza serverul RADIUS, la Protocol avem udp specific Radius si porturile de Auth&Accounting. Parola de la Secret trebuie sa respecte recomandarile de complexitate, deoarece o folosim in comunicarea cu serverul de autentificare. Dupa cum observati atunci cand se logheaza utilizatorii din Radius apar notati cu R, iar cei locali apar cu L:
    Pentru ca L2TP sa foloseasca Radius, trebuie sa bifam sub PPP -> Secrets -> PPP Authentication&Accounting:

Pasul IV

Activare server L2TP
PPP -> L2TP Server si completam:

Bifam Enabled, la Default Profile selectam profilul creat in pasul 2, iar la Authentication selectam metodele de autentificare acceptate de server.
Pentru a proteja tunelul l2tp cu Ipsec trebuie sa bifam Yes la Use IPsec si sa completam cheia privata (IPsec Secret) – este recomandat sa contina caractere speciale si sa fie de o lungime mai mare de 30 caractere, deoarece exista multi boti in Internet care folosesc forme de Brute Force/Dictionary Attack pentru a le ghici.
La Caller ID Type selectam criteriul de identificare al clientilor (in cazul nostru IP-ul). Pentru a avea mai multe sesiuni per user nu bifam ”One Session per Host”. Restul pot ramane default.

Pasul V

Selectare CIA (Confidentiality, Integrity, Authenticity)
IP -> IPsec
La faza 1 IPsec se stabilesc criteriile pentru protejarea tunelului VPN. Setarea acesteia o realizam sub Profiles pentru a selecta algoritmii doriti:
L2tp foloseste profilul faza 1 default. La noi o sa fie completat in felul urmator:

In general 3des nu este recomandat pentru criptare, dar eu am gandit asigurarea compatibilitatii si cu clientii legacy (unii angajati au sisteme de operare mai slabe acasa sau drivere de retea neactualizate). Unii intra de pe tablete/telefoane mobile si nu le functioneaza daca selectez aes 256 exclusiv. Totusi recomand alegerea algoritmului aes exclusiv, deoarece 3des/des/blowfish s-au gasit a avea vulnerabilitati.
In ce priveste integritatea mesajului folosim sha1 – un hash algorithm care inca isi face treaba cu succes.
Grupul de chei Diffie Helman recomandat pentru remote-vpn este 1024 (group2) si 2048 (group14) pentru a asigura o complexitate sporita a cheilor reinnoite, dar si procesarea mai rapida a lor, deoarece cu cat este mai mare grupul DH cu atat este mai complexa cheia, iar odata cu dificultatea ei creste si timpul de procesare. Tot astfel, clientii vpn de obicei nu suporta o complexitate mai mare.
Lifetime-ul este de o zi, perioada default si recomandata pentru faza 1. Reprezinta intervalul la care se reinitializeaza tunelul pentru reinnoirea asocierii de securitate si a cheilor folosite.
Am bifat NAT-traversal deoarece majoritatea clientilor se afla in spatele unui router care face nat. Cand este cazul portul 4500 este folosit in locul portului 500 pentru realizarea tunelului IPsec. Majoritatea routerelor cand primesc trafic pe portul 500 forwardeaza clientilor pe portul 4500 (functia de VPN Passthrough activa).

DPD Interval si DPD Maximum Failures reprezinta functia de Dead Peer Detection responsabila pentru asigurarea serverului ca userii sunt activi trimitand un hello message si asteptand un raspuns ack atunci cand nu mai exista trafic pe tunel.

Dupa ce am configurat faza 1, trecem la faza 2 IPsec. Intram la Proposals si adaugam:

Vom utiliza sha1 si sha256 pentru a acoperi toata aria de clienti compatibili cu alg. de hashing, respectand criteriile de securitate si best practice, insa la criptare vom folosi exclusiv aes 128/256, deoarece in faza 2 protejam efectiv datele ce traverseaza intre client si server. La PFS selectam modp 1024 (group 2). PFS se ocupa cu prevenirea compromiterii cheii prezente daca cheia long-term din care a derivat este compromisa. Procedeul este folosit in IPsec cu privire la cheile Diffie Helman si asigura exact acest lucru prin functia de rekeying.
Urmatorul pas este sa aplicam Proposalul IPsec la politica (l2tp foloseste ca si in cazul fazei 1 pe cea default):

Selectarea traficului se face prin alegerea ip-ului sursa local (de pe o interfata cu ip public, de obicei WAN) si destinatia ca fiind any, deoarece sesiunile se stabilesc in mod dinamic de la ip-uri diferite, aratand astfel:
DA – Dynamic Association

Conform imaginii de sus Actiunea este de a cripta, iar protocolul de incapsulare IPsec este ESP (ajuta la realizarea CIA). Proposalul creat se adauga la final si se numeste l2tp-ipsec.
In acest moment serverul l2tp este pregatit. Inainte de a anunta clientii sa se conecteze trebuie sa ne asiguram ca facem NAT in mod corect si permitem destinatiile/porturile necesare in firewall, ajungand la Pasul VI.

Pasul VI 

 NAT si Firewall

Pentru a asigura comunicatia intre clientii VPN si resursele private din alte branch-uri ale Companiei trebuie sa configuram NAT. Vorbim acum de Site-to-Site VPN intre Companie si alte sedii, incercand sa realizam comunicatia de acasa catre sediile respective fara a le conecta in mod direct printr-un alt site-to-site. De aceea folosim ca tehnica mascarea ip-ul privat L2TP cu ip-ul privat al Companiei trimis printr-un tunel ipsec cu acel branch office. Prin NAT urmarim sa nu trimitem subnetul l2tp prin ipsec-ul respectiv, ci sa evitam modificarea configuratiei lui mascand subnetul l2tp ca si cand ar fi ip-ul privat al Companiei trimis ca trafic interesant. : IP -> Firewall -> NAT -> +

Facem o regula de src-nat mentionand ip-ul sursa L2tp si ca destinatie serverul remote al Companiei:

Lasam totul default modificand doar Action in care mentionam ca dorim sa fie schimbat ip-ul sursa cu 172.17.0.1 atunci cand destinatia va fi serverul 172.16.123.123.
Desigur exista posibilitatea sa adaugam in ACL-ul pentru IPsec subnetul l2tp, dar tehnica presupune modificarea in oglinda si la celalalt capat al VPN-ului. Daca avem mai multe tuneluri nu ar fi scalabil sa facem asta, nu mai zic de un eventual downtime intre HQ si branch-uri.

Desigur exista posibilitatea sa adaugam in ACL-ul pentru IPsec subnetul l2tp, dar tehnica presupune modificarea in oglinda si la celalalt capat al VPN-ului. Daca avem mai multe tuneluri nu ar fi scalabil sa facem asta, nu mai zic de un eventual downtime intre HQ si branch-uri.
Cand vine vorba de accesul la internet de obicei clientilor VPN nu li se da voie sa acceseze internetul folosind reteaua companiei, configurand remote vpn-ul doar pentru destinatiile private. In setarile l2tp de pe statia lor li se spune sa nu trimita tot traficul prin l2tp, dar daca se doreste acest lucru din motive obiective (de ex accesarea unor echipamente remote pe ip-ul public al acestora, deoarece au ACL pe interfata WAN care permite traficul catre ele doar de la ip-ul public al Companiei) se adauga subnetul l2tp la regula de masquerade pentru NAT catre internet: IP -> Firewall -> NAT -> +
Selectam src-nat si la Out Interface interfata WAN. La Src Address completam subnetul l2tp pe care dorim sa-l NATam.
La Action selectam masquerade (mascare).
Astfel, permitem traficului l2tp sa fie NAT-at cu ip-ul public al Companiei in Internet.

Regulile de firewall presupun permiterea pe chain-ul de input (traficul care intra in Mikrotik) din internet pe porturile udp 500 (ISAKMP), 4500 (Nat Traversal), protocol esp (IPsec) si udp 1701 (port l2tp). Le configuram astfel:
IP -> Firewall -> Filter Rules -> +
In felul acesta configuram pentru fiecare port:
Chain: Input
Protocol: UDP & ESP
Dst. Port: 500, 4500, 1701
Action: Accept (Adica permitem sa acceseze routerul)
Daca dorim sa fim mai precisi este bine sa selectam la Input Interface interfata de WAN

Pentru limitarea accesului in reteaua companiei este bine sa configuram reguli de forward (Traficul intre retele, rutat de Mikrotik)
Permitem icmp/http/https/dns/rdp pentru Work from Home, deoarece aplicatiile folosite sunt web, iar unele servere se acceseaza prin Remote Desktop (port 3389). DNS-ul este permis pentru comunicatia cu Domain Controller/DNS Server aflat in reteaua locala a Companiei. Ping (ICMP) este permis doar pentru testarea comunicatiei intre client si resursele Companiei.
Pasii de configurare a unei reguli de Forward ->
Chain: Forward -> Actiunea de forwardare/rutare a pachetelor intre retele
Src Address: Subnetul l2tp
Dst. Address: IP-ul serverului
Protocol: UDP/TCP (depinde de protocolul folosit de aplicatia server)
Dst Port: 53,443,3389 etc. (portul specific serviciului, DNS, HTTPS sau RDP).

In felul acesta am finalizat proiectul de configurare l2tp/ipsec server si putem anunta clientii sa configureze l2tp/ipsec client pe statiile lor (procedura este diferita in functie de sistemul folosit). Este important sa le oferim urmatoarele informatii:
Server address: Ip-ul public WAN sau fqdn-ul acestuia (de ex vpn.companie.ro)
Pre-shared key (cheie privata): cheia secreta ipsec de peste 30 de caractere cu litere mici si majuscule, caractere speciale, cifre etc.
User/parola: Fiecare ar trebui sa le cunoasca (daca autentificarea se face prin RADIUS), deoarece le folosesc la e-mail, conectare pe Windows etc. Nu recomand setarea de utilizatori locali, deoarece este necesar in termeni de securitate sa supunem utilizatorii unor politici de domeniu.

Concluzia este ca putem oferi solutii de WFH fara cost si securizat atunci cand situatia o cere. Desigur, daca dorim sa avem grupuri de angajati cu acces dinamic, de exemplu sa configuram un acl dinamic aplicat per grup de VPN (ex. Contabilitate, Secretariat, IT etc.), fiecare conectandu-se la resurse diferite, va recomand Cisco Anyconnect. Singurul dezavantaj il reprezinta costul, dar avantajele il eclipseaza. Putem alege integrare IPsec sau SSL si sa folosim LDAP in loc de RADIUS pentru autentificare, aplicand cu ajutorul acl-urilor dinamice restrictii customizate per grup. Ramane sa discutam intr-un alt articol despre Anyconnect configurat pe Cisco ASA.

Work From Home, Stay Safe!

Articol scris de Bogdan Curduban – Network Engineer