El Viernes, 23 de Diciembre de 2005 17:48, Alfonso Pinto Sampedro escribió: || 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. Pues me alegro de haber mantenido este hilo contigo, ya que parece que ambos hemos sacado provecho ;) Felices fiestas. -- y hasta aquí puedo leer...
