Puerta de enlace o Gateway en la misma subnet (Cortafuegos, proxy, etc) Parte 1

Escenario

Para controlar mejor una red casera se implementa el cortafuegos y/o proxy en un equipo que está en el medio del router del ISP y de la LAN, ese equipo ha de tener al menos dos tarjetas de red (WAN-LAN). Para aprovechar la infraestructura típica de una red de hogar (en mi caso Movistar, con toda la complicación adicional de TV y Teléfono), y evitar tener que comprar o adaptar nuevos equipos, puntos de acceso wifi, etc, se trata de implementar el Cortafuegos/proxy en un equipo dentro de la misma subnet, haciéndolo funcionar como puerta de enlace para el resto de equipos y redirigiendo después todo al router:

(Nota, en mi caso, la Raspberry Pi actúa como servidor DNS, gracias al muy útil y recomendable Pi Hole https://pi-hole.net/)

El proceso tiene que ser el siguiente:

  • Configurar en los equipos conectados por WiFi la nueva puerta de enlace (podremos hacerlo por dhcp)
  • Configurar la nueva puerta de enlace con ip forwarding (y quitando ICMP Redirect, como veremos, para evitar que los equipos usen el router principal)
  • Añadir ruta estática en el router principal para que todo el tráfico destinado a los equipos wifi pase por la nueva puerta de enlace
  • Instalar en la nueva puerta de enlace un proxy web, IDS/IPS, cortafuegos, etc.
  • Aplicar reglas (iptables) en el router principal para permitir sólo tráfico desde la nueva puerta de enlace.

Pruebas con máquina virtual como Puerta Enlace

Antes de implementar todo, he hecho pruebas con una máquina virtual como Puerta de Enlace y el host como equipo conectado.

Tras las pruebas, necesariamente la máquina virtual tiene que tener una interfaz de red física propia, es decir, todo el montaje no funciona usando las tarjetas de redes virutales (modos NAT o bridge), así que para la prueba voy a usar un portátil con Windows 10, conectado por WiFi al Router, que ejecuta en VMWare una máquina virtual (Ubuntu) conectada a la WiFi mediante un adaptador Wifi USB, que captura VMWare para ella.

Puerta enlace subnet VM

Es un poco lioso, pero válido para la prueba. La Máquina Virtual (VM, Ubuntu), se conecta a la WiFi mediante un adaptador usb wifi, conectado exclusivamente para ella (nada funciona con tarjetas virtuales), mientras que el portátil lo hace mediante su propia tarjeta de red wifi integrada.

El adaptador usb que he usado es el edimax ew-7711usn (muy antiguo) para que funcine en ubuntu hay que poner en el blacklist (/etc/modprobe.d/blacklist.conf) los módulos rt2x00usb y r2x00lib, el módulo con el que funciona es el rt2800usb.

Una vez conectados a la wifi el portátil y la máquina virtual procedemos a la configuración:

Configurar Portátil y Máquina Virtual

La máquina virtual tiene la siguiente conexión (ip 192.168.1.43):
VM ifconfig

Habilitamos Ip Forwarding (como root)

# echo 1 > /proc/sys/net/ipv4/ip_forward

Cambiamos la ip en el portátil, le ponemos una ip fija y como puerta de enlace la ip de la VM (el servidor DNS uso el de mi Raspberry Pi) (ip 192.168.1.44, puerta de enlace 192.168.1.43)

ipconfig

 

Capturas de paquetes de red

Una prueba previa para comprobar que el enrutamiento en el portátil es correcto:

Comprobamos que el tráfico externo (ping a google) pasa por la máquina virtual, que es la puerta de enlace, sin embargo el tráfico local LAN es directo (como es de esperar, es capa de enlace, nivel 2 de OSI).

En este momento podemos hacer pruebas, arrancamos sendos WireShark en el portátil y en la máquina virtual, ambos con el filtro de la ip de nuestro portátil (192.168.1.44) para ver qué es lo que va ocurriendo.

Y lo que ocurre es que no funciona la cosa como queremos, pues la máquina virtual (puerta de enlace) está enviando ICMP Redirects para decirle al portátil que mande el tráfico externo a través del router principal.

En las siguientes capturas de wireshark en ambas máquinas vemos el proceso:

Primero el envío del ICMP redirect para una determinada conexión (incluye ip’s y puertos)

icmp redirect GW

En el portátil se reciben multitud de paquetes de este tipo,

icmp redirect W10

(nota: la mac de la máquina virtual la identifica Wireshark como EdimaxTE y la del portátil como LiteonTe)

Una muestra del tráfico al solicitar este blog mediante el portátil muestra que la primera conexión TCP SYN (handshake de tres etapas) la realiza a la puerta de enlace nueva (src: Liteon, dst: Edimax), pero la respuesta del servidor web TCP SYN ACK viene ya del router de movistar (src: mitrastar)

TCP SYN

TCP SYN ACK

Por último, para verificar todo, comprobamos que la máquina virtual, puerta de enlace, sólo captura el tráfico de ida del portátil, pero no el de vuelta (lógico, ya que nos falta decirle al router principal que el tráfico a nuestro portátil ha de redirigirlo por la nueva puerta de enlace, lo haremos después )

Desactivar ICMP Redirect en la Máquina Virtual, nueva puerta de enlace

Escribir los dos como root:

#echo 0> /proc/sys/net/ipv4/conf/wlan0/send_redirects
#echo 0> /proc/sys/net/ipv4/conf/all/send_redirects

Si volvemos a realizar las capturas con wireshark, ahora todo el tráfico icmp desaparece, aunque tenemos red e internet porque seguimos en la LAN y el router principal nos responde.

no icmp redirect

Ruta estática en el router principal

Añadimos ahora la ruta estática en el router principal para que todo el tráfico dirigido al portátil pase por la máquina virtual, su nueva puerta de enlace:

Añadimos en este caso sólo la ip del portátil (máscara 255.255.255.255 o bien /32)

(Nota, la otra ruta estática que tengo para la subred 192.168.2.0/24 es para el decodificador TV de movistar, que lo tengo por wifi, explicado en otro post)

ruta estatica

Ahora ya nos aseguramos de que todo el tráfico externo de nuestro portátil de ida y vuelta va a pasar por la máquina virtual. Realizando las capturas con wireshark se comprueba esto, es decir ahora sí vemos en la máquina virtual el tráfico de vuelta, aunque vemos el tráfico duplicado (tráfico de vuelta) y retransmitido (tráfico de ida), para atravesar la máquina virtual en ambos sentidos, es decir vemos los paquetes en los dos saltos:

portátil <--> máquina virtual (puerta de enlace) <--> router principal

Primer tramo: portátil a máquina virtual (src Liteon, dst: edimax)

trafico portatil-GW

Segundo tramo (TCP Retransmision) (src Edimax, dst: Mitrastar)

Esto, que parece un poco raro es normal (en un cortafuegos típico, esta retransmisión y duplicación de paquetes se hace entre las dos interfaces de red WAN<->LAN. Realizando alguna búsqueda por internet, puede encontrarse casos similares:

https://osqa-ask.wireshark.org/questions/17859/router-retransmitting-packets

https://community.cisco.com/t5/application-networking/wireshark-shows-tcp-retransmission-dup-ack-packet-on-wccp/td-p/2736436

Conclusiones

De esta manera todo funciona correctamente, y el tráfico SSL no se rompe. Sólo he encontrado un inconveniente, originado por el hecho de realizar la prueba usando sólo WiFi: es que se ralentiza muchísimo la navegación en el portátil, de los 100Mbps de bajada de mi internet, en la máquina virtual obtengo unos 25-30Mbps (el adaptador Edimax es WiFi bgn, se conecta a la de 2.4GHz, y estos son valores normales), y en el portátil la velocidad se ralentiza hasta unos 2-3Mbps, ridículo, ocasionado seguro por el trasiego WiFi entre los equipos router principal, puerta de enlace y portátil.

Un paso siguiente que he dado ha sidousar una máquina real a modo de Puerta de Enlace en lugar de la máquina virtual,  (un ubuntu live en otro portátil conectado también por WiFi), el mismo hecho se repite, la velocidad de bajada se degrada bastante (ahora obtengo unos 10-15Mbps)

Router ppal ) ) ) ) ( ( ( ( ( Puerta de enlace ) ) ) ) ( ( ( ( Portátil

100Mbps       WiFi           70-80 Mbps           WiFi          10 Mbps

Por último, la prueba usando el mini PC, conectado esta vez al router principal por cable (repitiendo exactamente los mismos pasos), evita todos los problemas y por fin obtengo en el portátil la velocidad de descarga de 100Mbps, como tiene que ser…

Router ppal ———- Puerta de enlace        ( ( ( ( Portátil

100Mbps      eth          100 Mbps               WiFi   100 Mbps

Una vez comprobado que es posible esta configuración, en la parte 2, trataré de extenderlo a toda la red local (todos los dispositivos que se conecten por WiFi), modificando el router principal para añadir las rutas estáticas para un segmento de red y el dhcp para indicar la nueva puerta de enlace. Y en la puerta de enlace instalar un IDS/IPS y un web proxy.

 

 

 

 

Leave a Reply

Tu dirección de correo electrónico no será publicada.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.