Mi escenario es un Fortigate con ip pública en un extremo, y un Cisco ASA con ip pública también en el otro. Entre ellos montan una vpn con ipsec, que falla más que una escopeta de feria. Mi idea era delegar la función que hace el Fortigate a un linux, una máquina virtual.
Monté entonces el servicio en una Debian 6 (detrás de un NAT) para que hiciera el papel del fortigate, en cuanto a la vpn se refiere, a ver si así consigo más estabilidad en la conexión…
Supongamos que el Cisco tiene la IP 1.2.3.4, cuya red privada a la que queremos acceder por vpn es 172.24.76.0/22. Supongamos también que la ip (privada, recordemos que está detrás de un NAT) del linux es 10.243.135.39, y que tenemos dos redes privadas que queremos conectar con la otra: 10.243.134.0/24 y 10.243.135.0/25.
Pasos a seguir en la Debian, como root:
apt-get update apt-get install racoon # elegir modo direct
Estos son los dos paquetes básicos (te instala también ipsec-tools).
Editamos/creamos el archivo que contiene la clave pre-compartida (no uso certificados):
cat /etc/racoon/psk.myKey.txt 1.2.3.4 m1Cl4v3Pr1v4d4!!
chmod 600 /etc/racoon/psk.myKey.txt
En mi caso, importé manualmente la config del fortinet (cifrado y demás) y lo adapté a la sintaxis de racoon:
cat /etc/racoon/racoon.conf
listen { isakmp 10.243.135.39; }
log info;
path pre_shared_key "/etc/racoon/psk.myKey.txt";
# phase 1
remote 1.2.3.4 {
exchange_mode main;
lifetime time 86400 second;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2;
}
}
# phase 2
sainfo address 10.243.134.0/24 any address 172.24.76.0/22 any {
lifetime time 86400 second;
encryption_algorithm 3des;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
}
sainfo address 10.243.135.0/25 any address 172.24.76.0/22 any {
lifetime time 86400 second;
encryption_algorithm 3des;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
}
sainfo address 172.24.76.0/22 any address 10.243.135.0/25 any {
lifetime time 86400 second;
encryption_algorithm 3des;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
sainfo address 172.24.76.0/22 any address 10.243.134.0/24 any {
lifetime time 86400 second;
encryption_algorithm 3des;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
}
Editamos /etc/ipsec-tools.conf
cat /etc/ipsec-tools.conf
flush;
spdflush;
spdadd 10.243.134.0/24 172.24.76.0/22 any -P out ipsec
esp/tunnel/10.243.135.39-193.145.206.140/require;
spdadd 172.24.76.0/22 10.243.134.0/24 any -P in ipsec
esp/tunnel/193.145.206.140-10.243.135.39/require;
Sólo queda abrir los puertos 500 y 4500 udp en nuestro firewall y redirigirlos a la máquina linux. Arrancamos dos servicios (los tenemos que incluir en el arranque de la máquina):
/etc/init.d/setkey start /etc/init.d/racoon start
Y vamos echando un ojo al log de racoon:
tail -f /var/log/racoon.log 2013-11-19 12:51:21: INFO: @(#)ipsec-tools 0.7.3 (http://ipsec-tools.sourceforge.net) 2013-11-19 12:51:21: INFO: @(#)This product linked OpenSSL 0.9.8o 01 Jun 2010 (http://www.openssl.org/) 2013-11-19 12:51:21: INFO: Reading configuration from "/etc/racoon/racoon.conf" 2013-11-19 12:51:21: INFO: 10.243.135.39[500] used as isakmp port (fd=6) 2013-11-19 12:51:21: INFO: 10.243.135.39[500] used for NAT-T 2013-11-19 12:51:24: INFO: IPsec-SA request for 1.2.3.4 queued due to no phase1 found. 2013-11-19 12:51:24: INFO: initiate new phase 1 negotiation: 10.243.135.39[500]<=>1.2.3.4[500] 2013-11-19 12:51:24: INFO: begin Identity Protection mode. 2013-11-19 12:51:24: INFO: received broken Microsoft ID: FRAGMENTATION 2013-11-19 12:51:24: INFO: received Vendor ID: CISCO-UNITY 2013-11-19 12:51:24: INFO: received Vendor ID: draft-ietf-ipsra-isakmp-xauth-06.txt 2013-11-19 12:51:24: INFO: received Vendor ID: DPD 2013-11-19 12:51:24: INFO: ISAKMP-SA established 10.243.135.39[500]-1.2.3.4[500] spi:9c475e50a42f9a9f:15b6f9161fc63a13 2013-11-19 12:51:25: INFO: initiate new phase 2 negotiation: 10.243.135.39[500]<=>1.2.3.4[500] 2013-11-19 12:51:25: WARNING: ignore RESPONDER-LIFETIME notification. 2013-11-19 12:51:25: INFO: IPsec-SA established: ESP/Tunnel 1.2.3.4[0]->10.243.135.39[0] spi=157528439(0x963b177) 2013-11-19 12:51:25: INFO: IPsec-SA established: ESP/Tunnel 10.243.135.39[500]->1.2.3.4[500] spi=2943122182(0xaf6c7b06)
Si queremos hacer un poco de troubleshooting, podemos usar tcpdump para ver la negociación IKE:
tcpdump -i any -nn proto 50 or proto 51
Y con este otro comando podemos ver si efectivamente se ha creado el túnel cifrado:
setkey -D
Sí, es una guía muuuuuy rápida y seguro que no funciona a la primera. Es lo que tiene una guía rápida 🙂 Y sí, también sé que no he explicado nada, ni conceptos ni nada.
Por internet hay mucha info, pero los enlaces más interesantes que me he encontrado son:
http://www.unixwiz.net/techtips/iguide-ipsec.html
https://wiki.debian.org/IPsec
http://www.kame.net/newsletter/20001119/
http://www.onlamp.com/pub/a/bsd/2003/01/09/FreeBSD_Basics.html?page=2
http://es.scribd.com/doc/7054317/IPsec-Advanced-Toubleshooting-Guide