PPTP, GRE y VPN múltiples con firewalls Stonegate (2 de 2)

Sigo con lo de antes.

Me logo al appliance con SSH y analizo con tcpdump un intento de abrir túneles como el explicado en el artículo de antes. Y veo algo así:

...
00:04:41.953787 IP 192.168.192.100 > 80.58.117.49: GREv1, call 19314, seq 0, length 37: LCP, Conf-Request (0x01), id 0, length 23
00:04:42.042053 IP 80.58.117.49 > 192.168.192.100: GREv1, call 49152, seq 0, ack 0, length 76: LCP, Conf-Request (0x01), id 0, length 58
00:04:42.044755 IP 192.168.192.100 > 80.58.117.49: GREv1, call 19314, seq 1, ack 0, length 55: LCP, Conf-Reject (0x04), id 0, length 37
00:04:42.045949 IP 80.58.117.49 > 192.168.192.100: GREv1, call 49152, seq 1, length 37: LCP, Conf-Ack (0x02), id 0, length 23
00:04:42.109984 IP 80.58.117.49 > 192.168.192.100: GREv1, call 49152, seq 2, ack 1, length 45: LCP, Conf-Request (0x01), id 1, length 27
00:04:42.110487 IP 192.168.192.100 > 80.58.117.49: GREv1, call 19314, seq 2, ack 2, length 29: LCP, Conf-Nack (0x03), id 1, length 11
...


Se comprueba lo que explicaba la nota de Stonesoft: GRE no utiliza el concepto de puerto que sí utilizan TCP o UDP. Nos dicen que esto impide que el firewall sea capaz de mapear/mantener el estado de más de una conexion con origen LAN al mismo destino WAN, que para el mundo exterior tendrán IPs públicas iguales. En cualquier cortafuego, mantener un estado para cada conexión es imprescindible, por ejemplo para permitir el paso de los paquetes de respuesta (acceso implícito, sin regla de acceso asociada) a las peticiones que haya enviado el originador de una conexión (para las que sí que hay reglas de acceso explicitas que permiten el paso).

De acuerdo, no hay src-port ni dst-port en los paquetes GRE. Pero, aún sin haberme leído los RFC correspondientes, veo lo que parece un id. de llamada (call) y otro de secuencia (seq) que, desde la ignorancia, parecen suficientes para mantener los estados de los que hablábamos antes.

Así que me da por intercalar un GNU/Linux con iptables (una Debian) entre la LAN y el Stonegate. El Linux actúa de dispositivo nateador, de forma que cualquier paquete que pase a través de él, sale con idéntica IP de origen (la del propio Linux, o sea 192.168.192.2). Establezco este equipo como puerta de enlace de los equipos desde los que intento abrir los túneles PPTP. Este es el nuevo dibujo:



La prueba también falla en el segundo túnel, pero al menos en el Stonegate ya no veo las denegaciones "Requested NAT cannot be done" (Esto es debido al NAT previo que está haciendo el Linux, que provoca que el Stonegate reciba un único origen y no se queje de nada).

Sniffo el Linux con un tcpdump y veo que el NAT sólo lo está haciendo para los paquetes de aquella máquina que ha sido la primera en abrir la conexión PPTP. Hasta aquí, más o menos, mismo comportamiento que el visto en el Stonegate.

Pero sigo sin creerme que el router de mi casa sea capaz de hacer más cosas que una distro Debian. Me doy un paseo por netfilter.org, me voy a Google y al final aterrizo en éste link.

Aquí me dicen que iptables dispone de dos helpers (ip_nat_pptp y ip_conntrack_pptp) que cargados en el kernel en forma de módulos permiten mantener los estados necesarios en las conexiones PPTP.

Aplico lo que proponen y pruebo de nuevo. Y todo empieza a funcionar. Mi GNU/Linux maneja correctamente los estados de las conexiones basadas en paquetes GRE, que de salida tienen la misma tupla origen-destino.

Este es el script iptables definitivo que he utilizado en el GNU/Linux (único propósito: natear la IP de origen, no actúa como cortafuegos):

#/bin/bash
export MYSELF="192.168.192.2"
export ANY="0.0.0.0/0"
iptables -F
iptables -X
iptables -Z
iptables -t nat -F
iptables -P INPUT ACCEPT
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
modprobe ip_nat_pptp || exit -1
modprobe ip_conntrack_pptp || exit -2
iptables -t nat -A POSTROUTING -s $ANY -d $ANY -j SNAT --to-source $MYSELF
echo 1 > /proc/sys/net/ipv4/ip_forward


Como ya he explicado en otras ocasiones, Stonesoft basa el SO de sus firewalls en la distribución Debian. ¡Vaya! La misma que he utilizado yo en mi prueba.

También veo que la versión de kernel que incorpora es suficiente para cargar los dos helpers iptables necesarios, según el link de wlug.org.nz

Conclusión: No estoy seguro de si Stonegate utiliza iptables, pero queda claro que manejar el contexto descrito aquí es perfectamente viable. Mientras Stonesoft no me lo aclare mejor, su firewall no soporta múltiples PPTP (misma combinación origen-destino en el lado público) porque a ellos no les da la real gana.