Test sul Cisco VPN Concentrator Netgroup Gruppo di lavoro sulle VPN

Cisco VPN Concentrator series modello 3005: 100 connessioni, 4 Mb/s, software encryption, 32 MB RAM modello 3015: idem, 64 MB RAM, upgradable ai modelli successivi modello 3030: 1500 connessioni, 50 Mb/s, hardware encr., 128 MB RAM modello 3060: 5000 connessioni, 100 Mb/s, hw encr., 256 MB RAM modello 3080: 10000 connessioni, 100 Mb/s, hw encr., 256 MB RAM Prezzi: ~4000 € (modello 3005), ~16000 € (modello 3015), ~26000 € (mod.3030) Netgroup Roma 19-20/02/2003

Principali funzionalità Capacità di stabilire VPN LAN-to-LAN e Client-to-LAN. Protocolli supportati: PPTP, L2TP/IPSEC, IPSEC, IPSEC/TCP ed IPSEC/UDP, ampia configurabilità dei meccanismi di criptazione. Autenticazione tramite database locale, Radius, NT-Domain (e W2K-Domain con AD), tramite certificati, ed altro. Management via seriale, http, https, ssh, telnet, etc. Client (IPSEC) per W*, Linux, MacOsX, SunOS Possiblilità di definire filtri sulle interfacce ethernet Netgroup Roma 19-20/02/2003

Caratteristiche degli oggetti in prova Cisco VPN Concentrator 3005 Cisco VPN Concentrator software V 3.5 Cisco VPN Client Sofware V 3.7.2 http://www.cisco.com/cgibin/tablebuild.pl/vpnclient-3des Netgroup Roma 19-20/02/2003

Layout canonico Netgroup Roma 19-20/02/2003

Layout di test Netgroup Roma 19-20/02/2003

Meccanismi di autenticazione (protocollo IPSEC) Autenticazione basata su username e gruppi Sul server vanno definiti i gruppi e le password di gruppo Ogni gruppo definisce il meccanismo di autenticazione ed il server di autenticazione da utilizzare Il client deve avere configurato il gruppo da utilizzare con la corretta password Netgroup Roma 19-20/02/2003

Layout di test (con autenticazioni) Netgroup Roma 19-20/02/2003

Autenticazione su DB locale Vanno creati uno o piu’ gruppi sul VPN server, e definita la password di gruppo Per ogni gruppo vanno definiti utenti (sempre sul server), con password Il client deve essere configurato per utilizzare uno di questi gruppi, e la sua password All’atto di stabilire la connessione il client chiede username e password Tutto funziona correttamente Netgroup Roma 19-20/02/2003

Autenticazione su W2K Si deve definire sul server un gruppo che autentichi con meccanismo NT-Domain e va specificato il server di autenticazione Non devono essere creati utenti in questo gruppo nel DB locale Il client chiede username, password ed opzionalmente domain name Il VPN server chiede l’autenticazione al W2K server L’autenticazione funziona correttamente sia verso W2K server senza AD, sia su W2K domain server con active directory Netgroup Roma 19-20/02/2003

Autenticazione verso Radius Si deve creare un gruppo sul VPN server, specificando Radius come meccanismo di autenticazione, definendo il nome del Radius server, e specificando la chiave del Radius server Non vanno definiti utenti in quel gruppo E’ stato installato un Radius server (freeradius.0.8.1) su un PC linux RedHat 7.3, client nel dominio NIS di sezione e AFS client nella cella infn.it (kerberos 4) Netgroup Roma 19-20/02/2003

Autenticazione verso Radius (cont.) Il Radius server va configurato per accettare come client il VPN server, specificando la stessa chiave (usata per criptare la comunicazione) E’ stato configurato il Radius server per utilizzare PAM, e via PAM per autenticare via NIS o via AFS L’autenticazione funziona specificando, all’atto della connessione, sia utenti NIS che utenti AFS della cella infn.it Netgroup Roma 19-20/02/2003

Autenticazione verso Radius (cont..) E’ stato installato anche un Radius server (freeradius.0.8.1) su un PC linux RedHat 7.3 AFS client nella cella le.infn.it (kerberos 5) Il Radius server e’ stato configurato nello stesso modo del precedente L’autenticazione ha funzionato correttamente Netgroup Roma 19-20/02/2003

Protocolli di tunnelling Sono state effettuate prove di connessione in VPN utilizzando i protocolli IPSEC (Cisco client) IPSEC/UDP e IPSEC/TCP (Cisco client) PPTP (Windows client e linux client) Netgroup Roma 19-20/02/2003

Protocolli di tunnelling (cont.) E’ possibile specificare, a livello di gruppo, se il client deve far passare attraverso il tunnel tutto il traffico o solo il traffico verso alcune network (configurabili) La configurazione non e’ modificabile dal client La cosa e’ stata testata, e funziona correttamente Netgroup Roma 19-20/02/2003

Protocollo IPSEC Si deve abilitare sul VPN server il protocollo IPSEC tra quelli accettati dal gruppo che viene utilizzato dal client Il client attiva una connessione IPSEC sulla porta 500 UDP dell’interfaccia pubblica del VPN server Le prove hanno verificato la funzionalita’ con i tre meccanismi di autenticazione gia’ visti Netgroup Roma 19-20/02/2003

Protocollo IPSEC/TCP e IPSEC/UDP E’ possibile configurare il VPN server ed il client per incapsulare la connessione IPSEC sia su TCP che su UDP Le porte TCP ed UDP per l’incapsulamento sono configurabili (ma il client deve sapere su quale porta connettersi) E’ stata testata la connessione con entrambi i protocolli anche a partire da client situati dietro reti filtrate o nattate (incapsulamento necessario) Netgroup Roma 19-20/02/2003

Protocollo PPTP Il protocollo PPTP non consente dal lato client di definire il gruppo per la connessione Puo’ essere definita sul VPN server una lista di server di autenticazione, anche di tipo diverso Il VPN server, con questo protocollo, tenta di verificare l’autenticazione solo con il primo server di autenticazione della lista Sono state effettuate prove con il client PPTP sia su Windows che su Linux Netgroup Roma 19-20/02/2003

Protocollo PPTP (cont.) Se non viene richiesta autenticazione, tutto OK Se viene richiesta autenticazione senza criptazione (PAP e MSCHAP v1), funziona con i tre meccanismi di autenticazione Se viene richiesto il cripting (MSCHAP v1 e v2) l’autenticazione funziona solo sul gruppo locale (ma la documentazione dice che funziona anche la autenticazione via Radius) Netgroup Roma 19-20/02/2003

Piattaforme client Per il protocollo PPTP, sono stati effettuati con successo test con client Windows e Linux Per il protocollo IPSEC (client Cisco) sono stati effettuati con successo test con client W2K Professional, Linux Rh 7.*, MacOsX (darwin kernel 5.5) Il client non compila sulla RedHat 8.0 Netgroup Roma 19-20/02/2003

Prove di throughput E’ stato effettuato un test di throughput utilizzando client linux connessi attraverso un link a 10 Mb/s Throughput con un client: 3.4 Mb/s Throughput con due client: 2*1.69 Mb/s In entrambi i casi l’utilizzo della CPU del VPN server va al 100% Netgroup Roma 19-20/02/2003

Cosa non e’ stato provato Autenticazione via certificati Protocollo L2TP/IPSEC con client Windows Netgroup Roma 19-20/02/2003

Cosa non funziona Non si e’ riusciti a configurare il VPN server con le due interfacce sulla stessa LAN (configurazione sconsigliata) Protocollo PPTP con criptazione (la documentazione dice che l’autenticazione via Radius funziona...) Netgroup Roma 19-20/02/2003

Layout ad una LAN Netgroup Roma 19-20/02/2003