Bueno resucito este tema, porque la semana pasada me he encontrado un firewall de esos que no permiten el tunel ssh por el 443
Osea que estamos ante un firewall DPI (Deep Packet Inspection) y por tanto puede filtrar por protocolos/tipos de archivos específicos, como SOAP o XML (por ejemplo en entornos transaccionales).
Bien, 4 días después de joderme el tunel ssh, y de darle vueltas al tarro, me lo he vuelto a saltar
obviamente no con un tunel ssh. No he probado si un tunel dns seria efectivo, pero dado que es un método sumamente lento a la hora de navegar, no me planteo utilizarlo.
Bueno, desplegando mi medios en la red del proxy pude constatar que el firewall en primera instancia te da acceso, y que pasado un tiempo al no encontrar lo que busca, bloquea la conexión.
Por eso en Bitvise da error, puede con suerte negociar la clave pero enseguida se corta la conexión.
En un principio pensé que era porque detectaba la negociación ssh que hemos comentado en los anteriores post que va en claro, y utilice métodos de ofuscación tanto del propio bitvise en sus versiones mas recientes, como de otros programas, y nada vuelta la burra al trigo.
Entonces decidí intentar una conexión tcp pura y dura, sin cifrar, y pude constatar que la conexión se establecía perfectamente en un inicio, pero enseguida bloqueaba el trafico saliente, la verdad que con el entrante no probé. Durante esa conexión tcp recibí una bonita llamada de identificación de servicio, entiendo que seria un IPS escaneandome

pues entonces la cosa estaba clara,el firewall permite el trafico http/https mientras que el resto de conexiones tcp eran bloqueadas en milisegundos.
Pues que tiene el trafico http?
las cabeceras
wifiway ~ # curl -I https://google.es
HTTP/1.1 301 Moved Permanently
Location: https://www.google.es/
Content-Type: text/html; charset=UTF-8
Date: Tue, 29 May 2018 16:58:30 GMT
Expires: Thu, 28 Jun 2018 16:58:30 GMT
Cache-Control: public, max-age=2592000
Server: gws
Content-Length: 219
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Alt-Svc: hq=":443"; ma=2592000; quic=51303433; quic=51303432; quic=51303431; quic=51303339; quic=51303335,quic=":443"; ma=2592000; v="43,42,41,39,35"
wifiway ~ # curl -I http://google.es
HTTP/1.1 301 Moved Permanently
Location: http://www.google.es/
Content-Type: text/html; charset=UTF-8
Date: Tue, 29 May 2018 16:58:55 GMT
Expires: Thu, 28 Jun 2018 16:58:55 GMT
Cache-Control: public, max-age=2592000
Server: gws
Content-Length: 218
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
wifiway ~ #
Tanto si el trafico es http, como si el trafico es https, las cabeceras van en claro con un bonito HTTP, la verdad que es una regla bastante eficiente para un firewall, en vez de buscar una serie de protocolos, solo buscan la cabecera del paquete http si esta, pasa, si no esta, bloqueo de conexión.
luego el resultado esta claro, tienes que utilizar http/https si o si, ahora ya solo falta montarte tu tunel http
