De ceva timp la implementarile de site to site VPN in Cisco ASA am avut probleme in selectarea interfetei sursa pentru accesarea serviciilor din celalalt sediu prin tunel. De exemplu NTP, SNMP, LDAP au nevoie de specificarea interfetei sursa atunci cand serverul nu este direct conectat, iar ASA da drop la traficul venit de la alte subneturi catre ip-urile interfețelor indirecte. De exemplu din INTERNET permite trafic doar catre ip-ul configurat pe interfata OUTSIDE, iar din INTERN permite trafic catre ip-ul interfetei direct conectate. Daca am chiar si in reteaua locala mai multe vlan-uri, nu functioneaza traficul din vlan 20 catre ip-ul interfetei gig0/1.10 de exemplu, dar inter-vlan routing merge intre retelele propriuzise din spate.

Nu se poate face bypass prin modificarea nivelului de securitate pe interfata si nici prin permit any any in firewall. Acesta este pur si simplu comportamentul dispozitivului. Tot ce tine de trafic management de asemeni nu functioneaza, precum ICMP, SNMP, AAA, NTP.

Ca studiu de caz avem trafic interesant ipsec intre sursa 172.16.108.0/24 și destinația 172.16.49.0/24. Sa vedem cum limitarea respectiva isi spune cuvantul:

a) Ping intre hosturile 172.16.108.163 si 172.16.49.43 functioneaza:

b) Ping cu sursa 172.16.108.251 (ip setat pe interfața ASA) nu functioneaza:

b) Ping cu sursa 172.16.108.251 (ip setat pe interfata ASA) nu functioneaza:

In designul unei retele aceasta limitare poate fi extrem de problematica. Nu tot timpul avem resursele pentru un Nagios sau AD in reteaua locala, de aceea de cele mai multe ori vom folosi vpn s2s in vederea deservirii userilor si monitorizarii infrastructurii. Solutia cea mai la indemana pana am gasit varianta din titlu a fost folosirea interfetei OUTSIDE (WAN) drept sursa prin vpn, necesitand anuntarea ip-ului public de WAN in ACL-ul ipsec ca trafic interesant. Stiu, suna un pic redundant, dar nu exista alta solutie, cel putin stiuta de noi. Este intradevar ciudat sa specific sursa de unde porneste tunelul ca fiind parte a traficului interesant, dar nu am avut incotro. Interfata OUTSIDE este direct conectata din perspectiva peer-ului, deci ip-ul de pe ea este bun ca sursa. Functioneaza, insa nu este best-practice.

Eram fortati sa avem ca destinatie pentru servicii ip-ul public al ASA-ului ceea ce implica cateva reguli in plus.

Daca am fi dorit sa schimbam din policy based IPsec in route based IPsec ecuatia se schimba. Avand in vedere ca la VTI se foloseste rutare si o alta interfata (virtuala) legata de mediul exterior, folosirea interfetei OUTSIDE ca sursa nu mai era o solutie. Chiar am deschis un topic pe comunitatea Cisco aici si nu am primit un raspuns cu privire la aceasta problema nici pana in ziua de astazi (acum le aratam noi). ASA momentan nu permite folosirea interfetelor VTI ca sursa in implementari de tip NAT, SNMP Client, NTP etc. Aceasta limitare impiedica pe multi care au o topologie de tip Hub&Spoke sa treaca la solutia mai securizata si simpla a VTI-urilor IKEv2. Speram sa-i ajutam cu acest articol.

Solutia care ne ajuta sa evitam toata ”mantocareala” cu selectarea ip-ului public de OUTSIDE in ACL-ul IPsec o reprezinta transformarea unei interfete inside, deja parte a traficului interesant din VPN, sa devina valabila pentru management-access. Ce presupune? O simpla comanda:

Acum reluam verificarile mai dinainte. Ping cu sursa in interfata respectiva functioneaza acum:

Asadar putem folosi aceasta interfata ca sursa pentru NTP, SNMP sau LDAP. Acum putem implementa VTI asigurand comunicarea cu serverele remote prin vpn. Obtinem astfel buna functionare a serviciilor. Clientul vpn, de exemplu, are nevoie de comunicare intre ASA și serverul LDAP pentru autentificarea userilor. Sub schema VTI nu functiona, dar acum utilizam fara probleme interfata PRODUCTION1 ca sursa. Setarile arata astfel:

aaa-server LdapServers (PRODUCTION1) host 192.168.168.12

Daca efectuam un test aaa obtinem urmatorul rezultat:

# test aaa-server authorization LdapServers username bogdan.curduban
Server IP Address or name: 192.168.168.12
INFO: Attempting Authorization test to IP address (192.168.168.12) (timeout: 10 seconds)
INFO: Authorization Successful

In concluzie, functia management-access este un tool excelent daca dorim sa transmitem trafic de management catre ASA prin VPN. Atunci cand traficul vine de pe OUTSIDE poate ajunge si la interfata de INSIDE. Putem selecta numai o singura interfata pentru acest rol. Este utila daca dorim sa monitorizam ASA folosind SNMP (ex Nagios), daca dorim ca ASA sa isi sincronizeze ora cu un server NTP din celalalt capat al tunelului VPN sau autentificarea userilor prin LDAP. Sper sa va ajute.

Articol scris de Bogdan Curduban – Network Engineer