Requerimientos en firewall para conexión de OpenVPN client??
-
En el cliente, desista la todo lo que corresponda a la vpn, en caso linux instala como root y proba hacer que corra con SU, en win instala como administrador, y ejecuta como administrador. Proba con eso, me suena a que viene por ahí.
los clientes no necesitan abrir puertos, son clientes no servidores, los clientes necesitan que le liberen el trafico, si se lo han bloqueado.
la vpn si esta por defecto usa el puerto 1194, y aleatorios para transferencias, usa algún puerto pasivo del 50xxx o por ahí hasta el 63xxx. -
Gracias por tu respuesta, haré las pruebas que mencionas, me llama la atencion lo que comentas sobre el uso de "puertos aleatorios para transferencias" y tu recomendación de uso de "puertos pasivos". Como comentaba la red donde está el cliente tiene varias medidas de seguridad y existe mucho tráfico que es bloqueado, es posible que estos errores se deban a que sólo solicitamos abrir el tráfico por el puerto IDO 1194? Si esto fuera correcto, que otro rango de puertos debo pedir que abran para mi cliente pueda conectarse? Son puertos uso o son cto?
-
si, TLS Error: cannot locate HMAC in incoming packet from [AF_INET]"IP publica Firewall del cliente":63734 ese error indica lo siguiente.
https://translate.google.com.ar/translate?hl=es-419&sl=en&u=https://www.digitalocean.com/community/questions/help-with-the-following-error-tls-error-cannot-locate-hmac-in-incoming-packet-from-af_inet&prev=search
https://translate.googleusercontent.com/translate_c?depth=1&hl=es&prev=search&rurl=translate.google.com.ar&sl=en&sp=nmt4&u=https://serverfault.com/questions/194769/unable-to-logon-to-vpn&usg=ALkJrhiY4Ws4ooDQf6sFDKMhrNd4P7P9gQ
un problema de la configuración en el server supuesta mente. descarto que sea eso ya que decis que otros clientes funcionan correctamente. o es configuración de cliente o los puertos aleatorios, están con trafico restringido, en el caso del error 63734. por lo menos eso se me viene en mente. -
desde mi punto de vista descarto al server, ya los clientes se pueden conectar usando el puerto UDP 1194 desde cualquier otra red, solo en esta red particular no es posible hacer la conexión ¿es posible hacer alguna configuracion especial al cliente para evitar estas restricciones? o ¿es necesario configurar algo en el server para sobrepasar este problema?
Como mencionas, esto puede ser debido al tráfico restringido en los "puertos aleatorios", ¿es posible saber que rango de puertos es necesario abrir para lograr esta comunicación? ¿son puertos UDP o TCP los que debo solicitar?
-
Dentro de un rato me siento a leer lo que tengo y te informo, no lo recuerdo.
De igual manera revisa el cliente, hay una linea que puede hacer generar ese error. Te mando una foto de una configuración mía.
revisa que lo mencionan en los link que te pase, los comentarios.![Captura de pantalla de 2017-09-12 16:37:43.jpg](/public/imported_attachments/1/Captura de pantalla de 2017-09-12 16:37:43.jpg)
![Captura de pantalla de 2017-09-12 16:37:43.jpg_thumb](/public/imported_attachments/1/Captura de pantalla de 2017-09-12 16:37:43.jpg_thumb) -
Estoy totalmente de acuerdo que en un cliente, no es para nada necesario tener puertos abierto, ya que NO es el servidor. Los puertos que estas mencionando, son los que necesita OpenVNP para escuchar y un cliente no es el servidor.
Algo así me pasó con un cliente y era por el programa cliente que estaba usando que se debía ejecutar como administrador. ¿Que programa ciente está usando ese PC? Si es OpenVPN, asegurate que sea la última versión y que el archivo de configuración, esté bien generado. Es más probá el archivo de configuración antes de enviárselo para ver si funciona.
-
Sabemos que el lío esta del lado del cliente (detrás de X firewall) y no de tu pfsense.
Tu con abrir (en el pfsense) que reciba conexiones udp por el 1194 es mas que suficiente, adicional tienes la referencia de que otros clientes excepto uno solo se pueden.
Por ahora solo se me ocurre:
-
problemas con el retorno de la conexión (algun IPS o sistema de protección que corte la conexión).
-
No están ejecutando como admnistrador el OpenVpn-client.
-
Firewall de windows, antivirus u otro programa que bloquee la conexión.
Por cierto, el cliente es Windows, Linux o Mac?
Saludos.
-
-
El día de hoy realizamos varias pruebas
- El equipo del cliente es Windows, se probó reinstalando la aplicación
- Se ejecuto la aplicación como admnistrador
- Se verificó en el cliente que ninguna aplicación del cliente, firewall o antivirus, este bloqueando la conexión
- Se llevó otra PC Windows y se ejecutó el cliente que se usa en ese equipo normalmente en otras redes
- Se tienen dos servidores OpenVPN funcionando, uno en UDP 1194 y otro en TCP 443, se probó un cliente en cada servidor
- Como última prueba se utilizó el cliente instalado en un smartphone Android, donde de manera regular se hacen conexiones
En todos los casos anteriores no es posible establecer la conexión.
Por las pruebas anteriores y tomando como referencia los equipos, PC adicional y Android, que normalmente se conectan por OpenVPN en otras redes sin ningún problema y solo estando dentro de esta red detras de este "X Firewall" no logran establecer esta conexión, es que podemos decir que el problema está asociado por sus "sistemas de protección" implementados en esa red.
Llegando a este punto es que sigo sin encontrar referencias que me indiquen que debo solicitar al departamento de seguridad para lograr estas conexiones, como mencionas me parece que el problema está asociado a los "puertos de control" en los retornos de conexión que son cerrados y por tanto generan errores del tipo "TLS Error", existe algún rango de puertos o protocolos de control que pudiera ser necesarios habilitar en el firewall de esta red?? o como preguntaba…...Que debo solicitar a los administradores de esta red para que permitan el tráfico y poder establecer esta conexión.
Pensando en alternativas que pueda yo manejar del lado del pfsense, podría evitar estos "cortes de conexión" utilizando un "Server Mode" distinto al que usamos actualmente (SSL/TLS + User Auth), podría ser una opción usar opciones como "User Auth" o "SSL/TLs"??
-
Si investigas, te vas a dar cuenta que no se abren puertos del lado del cliente ya que NO es el servidor.
En la documentación de OpenVPN (Troubleshooting OpenVPN Connectivity Issues), podrías encontrar una solución y una cosa interesante que dice ahí, es que debes tener cuidado que la red donde está ese cliente, NO tenga ni trabaje en el mismo rango de IPs que distribuye el servido OpenVPN.
Si no es eso, lee todo lo demás a ver si encuentras donde está el error. Hay dispositivos de hardware que se pueden bloquear aplicaciones y puede que también eso esté interfiriendo.
-
Bueno la prueba de fuego la podes realizar con una notebook, instala en cualquier lado el cliente que tiene que usar esa maquina. Probar que funcione, si funciona y podes ir a la oficina donde tiene que funcionar ese cliente y que la gente de sistema te permirta el trafico en la note, probar que tengas conexión. Tal ves de esa manera te conecte. Si es así, ya descartas un problema de la otra pc, firewal de win, antivirus o la creación del socket que usa el cliente openvpn.
Y si, yo por ej en el caso de una empresa lo tengo como remote access ssl/tls, cuando realice las configuraciones note un mejor rendimiento de parte de la vpn, no se si por que el equipo es chico o que pero funciona de 10.
-
SOLUCIONADO!!!!!!!!!!!
Gracias a todos por sus comentarios, finalmente y después de programar pruebas con la gente de seguridad, encontraron el origen del problema, este estaba asociado a reglas de filtrado de contenido, con poner una excepción en este filtrado para "OpenVPN" la conexión se pudo establecer.
Como comentaban del lado del cliente no había mucho que hacer o revisar, la regla en el firewall donde está ubicado el cliente estaba bien aplicada permitiendo la salida por el puerto UDP 1194, por eso en el pFsense alcanzaba a registrar los intentos de conexión del cliente y por el bloqueo de filtrado es que se generaban los errores del TLS y finalmente no se terminaba de lograr la conexión.