Gostaria de me conectar a um servidor OpenVPN de um host Ubuntu que também serve como firewall para outras conexões internas (dois APs e várias máquinas virtuais em execução nesse servidor).
Minha conexão trava em
Sat Nov 19 22:09:41 2016 UDPv4 link remote: [AF_INET]185.145.38.234:1194
Sat Nov 19 22:10:41 2016 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sat Nov 19 22:10:41 2016 TLS Error: TLS handshake failed
Sat Nov 19 22:10:41 2016 SIGUSR1[soft,tls-error] received, process restarting
Sat Nov 19 22:10:41 2016 Restart pause, 2 second(s)
A tcpdumpda conexão mostra que
root@srv ~# tcpdump -i any host 185.145.38.234
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
22:35:38.933443 IP 192.168.0.10.41552 > 185.145.38.234.openvpn: UDP, length 42
22:35:40.116782 IP 192.168.0.10.41552 > 185.145.38.234.openvpn: UDP, length 42
22:35:44.849548 IP 192.168.0.10.41552 > 185.145.38.234.openvpn: UDP, length 42
Posso me conectar do mesmo prompt a qualquer serviço, todo o tráfego é permitido. Ao tentar conectar especificamente a essa porta, recebo
root@srv ~# nc -v -u 185.145.38.234 1194
Connection to 185.145.38.234 1194 port [udp/openvpn] succeeded!
Eu tenho o mesmo comportamento para tcpconexões OpenVPN (incluindo o bem-sucedido nc).
A primeira razão que posso pensar para tal comportamento (o cliente envia uma solicitação e não recebe nada de volta) é o roteamento ou firewall incorreto. Mas qualquer outra conexão do mesmo sistema (mesmo prompt, a curl www.google.compor exemplo) é bem-sucedida. Não há firewall desse local (o tráfego é totalmente aberto).
Outro motivo pode ser alguma filtragem upstream (do ISP). Este não é o caso, pois um cliente na LAN (que transita pela máquina acima e finalmente sai pela mesma interface) pode se conectar com sucesso.
O que poderia ser um outro motivo para esta falha de mensagem e conexão?
De alguma forma atrasado, mas o motivo foi que um firewall adaptativo estava bloqueando o tráfego assim que o "reconhecia" como OpenVPN (provavelmente com base em pacotes específicos)