::[INTRO]::
Después de tanto tiempo de haber estado trabajando con FreeSwan como implementación de IPSec sobre Linux para el tema de VPNs (LAN-to-LAN) no se nos había ocurrido algo tan simple para solucionar el problema relacionado a continuación:
-
Cuando un paquete IP que nace en el VPN Gateway, y va con destino hacía la otra LAN con la que se establece el túnel VPN, el paquete IP se arma en el campo "source address" con la dirección IP pública que tenga asignado el VPN Gateway, lo cual genera un problema de enrutamiento porque este paquete no se va por el túnel IPSec. La forma correcta del paquete debe contener en el campo "source address" la dirección IP privada del VPN Gateway para que el paquete se enrute por el túnel y no por otro lado.
::[PROBLEMA Y SOLUCIÓN]::
Los que hayan tenido la experiencia de trabajar con FreeSwan como implementación de IPSec en Linux, seguro habrán tenido que hacer un ping desde el VPN Gateway dirigido a la LAN del otro extremo del túnel, forzando al PING para que se genere con la dirección IP privada del VPN Gateway y no con la dirección IP pública.
Veamos el caso gráficamente:
En esta situación tenemos dos VPNs Gateways conectando las LANs 10.1.0.0 y 10.2.0.0 (una topología LAN-to-LAN). Si queremos que un paquete que nace en el VPN Gateway de la izquierda se enrute a través del túnel con destino el VPN Gateway de la derecha o a cualquier estación de la LAN 10.2.0.0, tenemos que forzar a que el paquete IP salga con "source address" la dirección IP privada del VPN Gateway de la izquierda.
Suponga con la topología anterior que usted está parado en el VPN Gateway de la izquierda y ejecuta el siguiente comando (supongamos que en la LAN 10.2.0.0 existe la estación 10.2.0.1):
ping 10.2.0.1
Posiblemente el resultado será "Destintion unreachable" o quizá "Time to live exceeded". Cualquiera que sea el resultado, ese paquete nunca alcanzará el destino. ¿Porqué?, bien pues porque el paquete se arma en el campo "source address" con la IP Publica del VPN Gateway y en el campo "destination address" se arma con la IP destino, en este caso 10.2.0.1. Por lo tanto el paquete nunca llega. Para hacer que ese paquete llegue al destino, toca "forzar" a que el paquete IP salga en el campo "source address" con la IP privada del VPN Gateway.
Con el ping esto se puede lograr así (suponga que la IP privada del VPN Gateway de la izquierda es 10.1.0.254):
ping -I 10.1.0.254 10.2.0.1
De esta manera forzamos la dirección IP fuente en el paquete IP. Bien, eso está muy bien para el PING, pero ¿que pasa para las aplicaciones que necesitan enviar paquetes desde el VPN Gateway con destino una dirección IP privada de la otra LAN del extremo del túnel?.
He ahí el problema y he aquí la solución.
Para hacer que un paquete que nace en el VPN Gateway que va con destino una estación de la LAN del otro extremo del túnel, salga con la IP privada del mismo, pues hacemos NAT!!!...claro!, que idiotas, como no se nos había ocurrido!!!...
Suponga que la IP pública del VPN Gateway de la izquierda es 200.1.1.1 y la IP privada es la 10.1.0.254, el NAT que toca hacer para solucionar este problema es el siguiente:
iptables -t nat -A POSTROUTING -s 200.1.1.1 -d 10.2.0.0/16 -j SNAT --to 10.1.0.254
Con la regla de NAT anterior estamos diciendo: "Todo paquete que salga con IP fuente 200.1.1.1 y que tenga como destino la red 10.2.0.0/255.255.0.0, modifíquelo para que la IP fuente sea realmente la 10.1.0.254".
Para aquellos curiosos, les recomiendo leer sobre las cadena POSTROUTING y PREROUTING del componente de IPTables.