[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OpenVPN HOWTO (no me funciona).



On Wednesday 21 December 2005 19:13, Iñaki wrote:
> El Miércoles, 21 de Diciembre de 2005 18:42, Iñaki escribió:
> || El Miércoles, 21 de Diciembre de 2005 17:52, Alfonso Pinto Sampedro
>
> escribió:
> || || > || > || Esto no es correcto, tienes que aceptar lo que venga del
> || || > || > || puerto 1194 en la interface real (por ejemplo eth0). Todo
> || || > || > || lo que venga de ese puerto se pasa a la interface virtual
> || || > || > || tunX, asi que dependiendo de tu firewall puede ser que
> || || > || > || tengas que añadir reglas para esa interface.
> || || > || >
> || || > || > No, esto no es cierto, aunque el tráfico de TUN vaya
> || || > || > evidentemente sobre la única interfaz real de red que existe
> || || > || > (eth0) para Iptables son dos interfaces totalmente
> || || > || > independientes. No necesitas aceptar el tráfico al puerto 1194
> || || > || > en eth0, de hecho yo no lo admito y me funciona. Tan sólo
> || || > || > debes permitir el INPUT, OUTPUT y FORWARD (tal vez -i y -o)
> || || > || > por tun0.
> || || > ||
> || || > || Tal y como yo comentaba, son dos interfaces independientes, de
> || || > || ahí que dijese que las reglas que tenía no funcionaban. Si usas
> || || > || un escenario de vpn de servidor-cliente y tienes el servidor
> || || > || detras de un firewall con politicas por defecto DROP (o el
> || || > || servidor está en el propio firewall) como no abras el puerto en
> || || > || el que escucha el demonio de openvpn te aseguro que no funciona,
> || || > || bastante me he pegado con esto.
> || || >
> || || > Son dos cosas distintas, si tienes el servidor OpenVPN detrás de un
> || || > firewall evidentemente necesitas permitir el tráfico por el puerto
> || || > UDP 1194 en el firewall, y además redirigirlo a la máquina donde
> || || > tengas el servidor OpenVPN.
> || || >
> || || > Pero si tienes el servidor OpenVPN y el firewall (Iptables) en la
> || || > misma máquina NO es necesario permitir el tráfico por el puerto UDP
> || || > 1194 en eth0 o ppp0 (o por donde se salga por defecto a Internet).
> || || > Tan sólo debes permitir la entrada por el interfaz tun0.
> || || >
> || || > Te garantizo que he instalado OpenVPN en una máquina que a su vez
> || || > hace de firewall y NAT a la red local, y en esos Iptables tengo por
> || || > defecto DROP en INPUT y FORWARD, pero añado la reglas para que sí
> || || > se acepte el tráfico por tun0.
> || ||
> || || Pues o tienes mal configurado el firewall o estas aceptando el
> || || tráfico en el puerto correspiente a openvpn en la interface real sin
> || || que te hayas dado cuenta:
> || ||
> || || Sacado de http://openvpn.net/faq.html, seccion My OpenVPN client and
> || || server say "Connection Initiated with x.x.x.x" but I cannot ping the
> || || server through the VPN. Why?, último parrafo
> || ||
> || || Also note that firewalling the TUN/TAP interface is a completely
> || || separate operation from firewalling the internet-facing interface.
> || || For example, suppose an OpenVPN client is sending email via SMTP over
> || || the OpenVPN tunnel. The OpenVPN server firewall will need to allow
> || || both incoming encrypted data on TCP/UDP port 1194 via the
> || || internet-facing interface as well as incoming SMTP connections via
> || || the TUN/TAP interface.
> || ||
> || || Además tengo un equipo de pruebas que es firewall y servidor de
> || || openvpn. Si quito la regla que permite la entrada de paquetes por el
> || || puerto 1194, obtengo una bonita lista de paquetes descartados en mis
> || || logs y la vpn no levanta. La interfaz tunX es una interfaz virtual.
> || || El cliente se conecta al servidor Openvpn en el puerto 1194. Este
> || || proceso se encarga de pasar todos los paquetes correspondientes a la
> || || interfaz tunX. Si tu no aceptas los paquetes por el puerto 1194 ¿como
> || || establecen conexión el cliente y el servidor Openvpn? Es imposible.
> ||
> || Esto se pone muy interesante. Creo que intuyo lo que pasa:
> ||
> || En realidad mi experiencia se limita a OpenVPN pero NO en modo
> || client-servidor, sino en modo ¿simétrico? (no sé como decirlo).
> ||
> || En este modo al arrancar OpenVPN cada extremo inicia una comunicación y
> || hace un ping cada 15 segundos (en mi caso), por lo que por eso no hace
> || falta abrir el puerto 1194 UDP para la entrada, ya que al lanzar un ping
> || cada 15 segundos lo que viene se considera "ESTABLISHED" o "RELATED" (me
> || supongo).
> ||
> || En modo servidor entiendo que SI que hay que abrir el puerto 1194 pues
> || dicho servidor no ha iniciado por su cuenta la comunicación con el otro
> || extremo, sino que es el cliente quien la inicia.
>
> Extraído del manual de OpenVPN:
>
>
> FIREWALLS
> ***********
>  OpenVPN's usage of a single UDP port makes it fairly firewall-friendly.
> You should add an entry to your firewall rules to allow incoming OpenVPN
> packets. On Linux 2.4+:
>
>   iptables -A INPUT -p udp --dport 1194 -j ACCEPT
>
>  would be adequate and would not render the host inflexible with respect to
> its peer having a dynamic IP address.
>
>
>  OpenVPN also works well on stateful firewalls. In some cases, you may not
> need to add any static rules to the firewall list if you are using a
> stateful firewall that knows how to track UDP connections. If you specify
> --ping n, OpenVPN will be guaranteed to send a packet to its peer at least
> once every n seconds. If n is less than the stateful firewall connection
> timeout, you can maintain an OpenVPN connection indefinitely without
> explicit firewall rules. You should also add firewall rules to allow
> incoming IP traffic on TUN or TAP devices such as:
>
>   iptables -A INPUT -i tun+ -j ACCEPT

Bingo, tu sospecha era correcta, al lanzar un ping cada X tiempo considera que 
la conexión está establecida. No se como afectará esto en el modo servidor, 
aunque tengo la sensación de que no funcionará, ya que en la configuración 
del servidor no se indica nada sobre las ips de los clientes (o nombres de 
host de tipo dyndns por ejemplo, muy útil si tienes ips dinámicas), con lo 
que no puede enviar un ping a ningún cliente y la conexión no se considera 
establecida. En el modelo cliente-servidor, hasta donde yo se, quien 
establece la comunicación es el cliente, así que me temo que toca poner una 
regla en el servidor para permitir el tráfico en el puerto de Openvpn.

Y por cierto, gracias a ti por la información de ip_conntrack para UDP. Es un 
tema que me trajo de cabeza mucho tiempo y que tuve que solucionar duplicando 
reglas, unas para las de entrada y otras para las de salida.

Un saludo y felices fiestas a toda la lista.

Attachment: pgp5fkohIo1rc.pgp
Description: PGP signature


Reply to: