Problema con acceso a bancos online
-
All is open from lan to internet and NAT is being doing in the router with internet access, not in pfsense.
Cheers
-
Hola,
Soy nuevo en pfsense y me pasa lo mismo. Al final, he configurado el outbound NAT de la forma que indica Bellera y sigue negando la conexión https.Entiendo que no es cuestión de habilitar una regla (al igual que no la hay para el puerto 80), dado que la sesión se inicia en LAN y el pfsense reconoce la respuesta como perteneciente a una sesión iniciada desde dentro.
Por cierto, tampoco tengo squid activado. ;)
Se agradece cualquier ayuda.
Jose Angel
-
¡Hola!
¿Qué versión de pfSense estais empleando?
Una regla para la LAN que permita el tráfico hacia el puerto 443 debería bastar.
En mi instalación "de producción" hacemos habitualmente compras en Internet y accedemos a los portales de "La Caixa" y "Caixa de Catalunya" sin problemas.
¿Estais haciendo balanceo de carga? ¿Teneis algún proxy -el de pfSense u otro-? ¿Teneis una o varias WAN -gateway- de salida? ¿Teneis snort en pfSense?
Más datos, por favor, a ver si podemos encontrar la causa.
Saludos,
Josep Pujadas
-
Gracias por contestar, Josep.
En mi caso, no tengo proxy (squid) instalado en el pfsense, tengo la versión 1.2-RC2 (built on Fri Aug 17 17:46:06 EDT 2007).
La regla de acceso desde WAN a LAN para el 443 está puesta (me conecto por ssh desde el trabajo y tengo el servidor ssh escuchando en el puerto 443 para saltarme el proxy y firewall de mi empresa, tunelizando a través de PUTTY), y tiene la forma : Proto TCP / Source * / Port * / Destination LAN address / PORT 443 / Gateway * .Tengo además un NAT de la forma If WAN / Proto TCP / Ext. port range 443 / NAT IP 192.168.1.100 (la máquina en LAN desde la que intento ir al banco) /Int. port range 443 permitiendo el NATting desde mi IP pública hacia la máquina que tiene el ssh server.
El acceso al puerto 443 del ssh es posible desde fuera (el ssh se ve y los paquetes llegan), pero entiendo que no es necesaria una regla permitiendo las peticiones https, ya que la sesión https la hago yo al servidor del banco, saliendo por el puerto mío que toque y dirigido hacia el 443. En cualquier caso, he creado una regla en LAN para permitir la salida "LAN any to 443" y tampoco.
No hago CARP (sólo tengo un Dell PII dedicado al pfsense) ni balanceo de carga. No tengo proxy alguno en el pf (salvo el squid corriendo en esa máquina -192.168.1.100-, que es el que me recoje las peticiones http cuando entro desde el trabajo tunelizando http por ssh con PUTTY), pero que no está recogiendo mis peticiones https (escucha en el puerto 3128) y el navegador no está usando el proxy local. Sólo tengo una WAN (el ADSL) y no tengo instalado snort ni en la máquina 192.168.1.100 ni en el firewall.
Antes tenía un router linksys y un firewall software en el PC e iba todo bien. Seguro que es alguna chorrada, pero no doy con ella.
Muchísimas gracias por tu ayuda y siento el retraso en la contestación.
Jose Angel
-
Hola,
Siguiendo con el problema anterior, tras hacer n^k pruebas, veo que la conexión https no está siendo bloqueada por el pfsense, porque sino debería aparecer una línea en el log indicando el "drop" de la llamada saliente….. y no aparece nada "dropado" intentando establecer comunicación con la IP del banco al puerto 443.
Curioso......
-
¡Hola!
A ver si lo entiendo …
"Sales" del trabajo por TCP 443 con una conexión SSH. Con ello estás en la máquina de casa.
Tu conexión SSH con PuTTY tuneliza el puerto 3128 de la máquina de tu trabajo hacia el puerto 443 de la IP de tu banco.
Metes en el navegador de tu trabajo localhost:3128 y estás en tu banco.
Conexión: trabajo:XXXX --> casa:443
Túnel: trabajo:3128 ---> banco:443¿Qué sistema operativo tienes en la máquina de casa? Igual hay otra solución ...
Sobre tú último post: No, por supuesto, pfSense no ve tu tráfico https. Está tunelizado dentro de SSH. Y SSH está encriptado, o sea, que no hay manera de ver qué hay dentro de la comunicación.
Yo estoy haciendo algo parecido, pero al revés. Me conecto por SSH a uno de los servidores FreeBSD del trabajo, con varios túneles. Y accedo por RDP y/o VNC a las máquinas del trabajo.
Saludos,
Josep Pujadas
-
Josep,
Gracias por tu contestación. Te respondo sobre tu texto:
"Sales" del trabajo por TCP 443 con una conexión SSH. Con ello estás en la máquina de casa.
si
Tu conexión SSH con PuTTY tuneliza el puerto 3128 de la máquina de tu trabajo hacia el puerto 443 de la IP de tu banco.
NO. Salgo del trabajo hacia casa por el 443 (haciendo una sesión ssh por PUTTY hacia IP_DE_CASA:443). Ese puerto es el que no pueden cerrar -ni "proxear"- en el trabajo, por razones obvias.
Una vez establecida la sesión ssh desde el trabajo a casa, utilizo el PUTTY como inicio de tunel, con la regla en PUTTY L10000->192.168.1.100:3128. Además configuro el navegador a que utilice el localhost:10000 como proxy de salida.Con esto, hago que el navegador en el PC del trabajo "tire" todo el tráfico hacia el proxy localhost:10000, que es la boca del tunel del PUTTY que acaba en el "sshd" del PC de casa. Además, el servidor del túnel en casa sabe que el tráfico ese lo tiene que redireccionar hacia 192.168.1.100:3128 (a causa de la regla de PUTTY), convirtiéndose esta dirección en el pc de casa en localhost:3128, que es puerto del squid en casa que está escuchando. Este squid es el proxy "real" que desde casa navega, y que me devuelve las páginas de vuelta desde casa a través del túnel hacia el PC del trabajo.
Metes en el navegador de tu trabajo localhost:3128 y estás en tu banco.
Conexión: trabajo:XXXX –> casa:443
Túnel: trabajo:3128 ---> banco:443No es así, ya he aclarado este punto.
¿Qué sistema operativo tienes en la máquina de casa? Igual hay otra solución ...
Esa máquina tiene un XP, pero no creo que sea de la máquina, ya que sin el pfsense funcionaba perfectamente. Tengo una debian, un OpenBSD, un SunOS y un IRIX, pero no quiero dejar más que dos máquinas encendidas ;) ( el PC de XP y el FW )
Sobre tú último post: No, por supuesto, pfSense no ve tu tráfico https. Está tunelizado dentro de SSH. Y >SSH está encriptado, o sea, que no hay manera de ver qué hay dentro de la comunicación.
Lo sé. Me refería al tráfico hacia el puerto https que genera el proxy en casa y que es la "navegación real" de acceso a una página https. Es imposible ver el tráfico https en claro, pero una vez que el squid lo recoje y hace la "navegación real" hacia la página del banco, si el pf me tirara esta conexión, vería en el log una entrada de una sesión saliente "dropada" hacia la ip del banco y hacia el puerto 443, y no está en el log.... con lo cual asumo que sale.... Esta noche usaré el wireshark para ver si esa conexión se hace (si consigo salir antes de la 22h del trabajo).
Yo estoy haciendo algo parecido, pero al revés. Me conecto por SSH a uno de los servidores FreeBSD del >trabajo, con varios túneles. Y accedo por RDP y/o VNC a las máquinas del trabajo.
vaya,vaya..... trabajando desde casa ;D ;D ;D a quién te parecerás.... mal de muchos, ¡ epidemia !
En primer lugar, gracias mil por tu ayuda e interés. Espero haberte explicado todo de forma clara
Un abrazo
Jose Angel
-
Entiendo …
Conexión SSH: localhost:XXXX ---> casa:443
Túnel: localhost:10000 ---> casa:3128 (squid)
Navegación en localhost empleando localhost:10000 como proxy.Tampoco veo porqué no tendría que ir ...
Otra solución sería abrir una sesión RDP en tu WinXP, dentro del túnel SSH con PuTTY.
Saludos,
Josep Pujadas
-
Querido Josep,
Si señor. Has cogido el modelo. Como ves es muy simple y sin complicación…... Seguro y fácil, usando certificados para el tunel ssh...
Gracias por tu consejo. Seguiré probando y analizando porque TIENE QUE FUNCIONAR !!!!. Si se te ocurre algo, por favor dímelo.
Pensé que era una tontería mía hasta que ví el primer post de "usuarioforum" en el que le pasaba lo mismo.
Un gran abrazo ;D ;D ;D ;D
José Angel
-
Hola,
Sigo perdido con lo mismo.
He capturado paquetes intentando acceder por https a "oi.cajamadrid.es" en el interface LAN y obtengo:
Interface LAN:
23:15:58.839890 MAC-WAN > MAC-LAN, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 48385, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.100.8541 > 213.164.164.68.443: S, cksum 0x9b0c (correct), 3982002084:3982002084(0) win 65535 <mss 1460,nop,wscale="" 1,nop,nop,sackok="">23:15:58.840553 MAC-LAN > MAC-WAN, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 56656, offset 0, flags [DF], proto: TCP (6), length: 52) 213.164.164.68.443 > 192.168.1.100.8541: S, cksum 0xf7d7 (correct), 4044469310:4044469310(0) ack 3982002085 win 65228 <mss 1460,nop,wscale="" 8,sackok,eol="">23:15:58.841016 MAC-WAN > MAC-LAN, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 64, id 48387, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.1.100.8541 > 213.164.164.68.443: ., cksum 0x3b86 (correct), 1:1(0) ack 1 win 64240
23:15:58.842762 MAC-WAN > MAC-LAN, ethertype IPv4 (0x0800), length 132: (tos 0x0, ttl 64, id 48388, offset 0, flags [DF], proto: TCP (6), length: 118) 192.168.1.100.8541 > 213.164.164.68.443: P, cksum 0x663c (correct), 1:79(78) ack 1 win 64240
23:15:58.843059 MAC-LAN > MAC-WAN, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 64, id 8764, offset 0, flags [DF], proto: TCP (6), length: 40) 213.164.164.68.443 > 192.168.1.100.8541: ., cksum 0x3529 (correct), 1:1(0) ack 79 win 256
23:15:58.957647 MAC-LAN > MAC-WAN, ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 64, id 39184, offset 0, flags [DF], proto: TCP (6), length: 64) 213.164.164.68.443 > 192.168.1.100.8541: P, cksum 0x18c5 (correct), 1:25(24) ack 79 win 256
23:15:58.958212 MAC-wAN > MAC-LAN, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 64, id 48399, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.1.100.8541 > 213.164.164.68.443: F, cksum 0x3b2b (correct), 79:79(0) ack 25 win 64228
23:15:58.958475 MAC-LAN > MAC-WAN, ethertype IPv4 (0x0800), length 73: (tos 0x0, ttl 64, id 63787, offset 0, flags [DF], proto: TCP (6), length: 59) 213.164.164.68.443 > 192.168.1.100.8541: P, cksum 0xb86a (correct), 25:44(19) ack 80 win 256
23:15:58.958911 MAC-WAN > MAC-LAN, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 64, id 48400, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.1.100.8541 > 213.164.164.68.443: R, cksum 0x35f9 (correct), 80:80(0) ack 44 win 0pero si hago lo mismo en el interface WAN, no obtengo nada…..
¿No debería ver los paquetes pasar por WAN ?
Gracias por vuestra atención
José Angel</mss></mss>
-
José Ángel,
No ves nada en la WAN porque está tunelizado dentro de SSH. Esta es la gracia de hacer un túnel dentro de SSH, no se puede ver nada de lo que pasa por dentro de SSH:
http://es.wikipedia.org/wiki/Protocolo_tunelizado
Estás haciendo una doble encriptación, que no creo que sea el problema. Igual es una cuestión de tiempo de respuesta entre encriptar y desencriptar …
Saludos,
Josep Pujadas
-
Querido Josep,
Siento muchísimo (infinito, rotundo, humildemente) haberte mareado a tí y al que leyera esto.
Al final, tras mucho tocar no he reparado en la configuración del pequeño catalyst que tengo para enrutar todos los equipos.
Era una estupidez absurda. Me "pego un tiro en el pié" como castigo. :P
Un abrazo y gracias mil por el apoyo. ;D
José Angel
-
¡Buenas noches!
Estas cosas pasan, ya se sabe …
¡De nada!
¡Hasta otra!
Saludos,
Josep Pujadas
