Proyecto para migrar de Netasq U70 a Pfsense (squid3-devel)



  • Hola amigos,

    Un saludo a todos antes de entrar en materia. Antes de nada decir que soy nuevo en FreeBSD y desde luego no soy ningún experto en el tema de firewalls. Espero encontrar en este foro algún entusiasta que pueda guiarme para poner en marcha esto.

    LLevo 3 semanas iniciándome y haciendo pruebas con Pfsense, después de mucho buscar por internet lo elegí como primera opción para sustituir al firewall que actualmente tenemos (Netasq U70), que tiene una raiz común con Pfsense pues creo que ambos provienen de monowall. Las razones del cambio son que actualmente el Netasq no filtra https y hay muy poca información disponible para soporte además del coste del servicio y licencia.

    Pfsense me ha gustado mucho por la facilidad de instalación, interface web, y variedad de servicios de que dispone, pero despues de 3 semanas intentando hacerlo funcionar me empiezo a desesperar…

    El proyecto es el siguiente:

    Se trata de la protección y seguridad de la red de un centro escolar, que dispone de un servidor web propio en el centro y varias redes: lan de administración, lan aulas, lan wifi, lan servidores y 2 conexiones de banda ancha wan.

    He montado una maquina con un intel G3220 4Gb de Ram, 6 Nic realteck (3pci+3pcie) además del incluido en placa, y un disco SSD 120Gb (porque no tenian de 64 cuando lo compré).

    Instale Pfsense 2.1 creando 2 particiones de 8Gb una de backup donde habrá una copia indéntica de la partición principal. activé las opciones para usar ramdisk para /var y /tmp para evitar el desgaste de la SSD.

    -La primera funcionalidad debe ser la cortafuegos y nat con snort para detección y bloqueo de ataques y balanceo Wan según origen o en caso de caídas, esto parece que esta funcionando salvo el balanceo para el caso del propio pfsense que me requiere predeterminar el gateway activo o por ejemplo no obtiene la información de paquetes ni los descarga.

    -Lo siguiente y que más dolores de cabeza me está dando es el http/https proxy transparente con filtrado web y antivirus, con distintos grupos de seguridad. Creí que el proyecto estaría mas maduro en esta parte, pero la veo más bien solo apañada...

    -También tendrá que servir como servidor dns principal del dominio que tenemos con Bind y hacer un proxy reverso para acceder a los distintos servicios web que tenemos (Esta parte probé a configurarla pero no la he probado aún)

    -Portal cautivo para el acceso wifi y filtrado de esta con distintos grupos de seguridad.

    -Acceso remoto VPN para tareas de mantenimiento.

    Empiezo aquí con las cuestiones con las que tengo problemas.

    1.- El hardware lo ha reconocido sin problemas aparentemente, pero el adaptador de red interno de la placa no me lo permite usar (aúnque de momento puedo prescindir de el ) a detectado de re0 a re6, pero re3 no me permite asignarlo como interface. esto es lo que me aparece con dmesg:

    |
    dmesg | grep re3
    re3: <realtek 8111="" 8168="" b="" c="" cp="" d="" dp="" e="" f="" pcie="" gigabit="" ethernet="">port 0xb000-0xb0ff mem 0xf7900000-0xf7900fff,0xf0000000-0xf0003fff irq 18 at device 0.0 on pci4
    re3: Using 1 MSI-X message
    re3: Chip rev. 0x4c000000
    re3: MAC rev. 0x00000000
    re3: Unknown H/W revision: 0x4c000000
    device_attach: re3 attach returned 6
    re3: <realtek 8111="" 8168="" b="" c="" cp="" d="" dp="" e="" f="" pcie="" gigabit="" ethernet="">port 0xb000-0xb0ff mem 0xf7900000-0xf7900fff,0xf0000000-0xf0003fff irq 18 at device 0.0 on pci4
    re3: Using 1 MSI-X message
    re3: Chip rev. 0x4c000000
    re3: MAC rev. 0x00000000
    re3: Unknown H/W revision: 0x4c000000
    device_attach: re3 attach returned 6
    re3: <realtek 8111="" 8168="" b="" c="" cp="" d="" dp="" e="" f="" pcie="" gigabit="" ethernet="">port 0xb000-0xb0ff mem 0xf7900000-0xf7900fff,0xf0000000-0xf0003fff irq 18 at device 0.0 on pci4
    re3: Using 1 MSI-X message
    re3: Chip rev. 0x4c000000
    re3: MAC rev. 0x00000000
    re3: Unknown H/W revision: 0x4c000000
    device_attach: re3 attach returned 6
    re3: <realtek 8111="" 8168="" b="" c="" cp="" d="" dp="" e="" f="" pcie="" gigabit="" ethernet="">port 0xb000-0xb0ff mem 0xf7900000-0xf7900fff,0xf0000000-0xf0003fff irq 18 at device 0.0 on pci4
    re3: Using 1 MSI-X message
    re3: Chip rev. 0x4c000000
    re3: MAC rev. 0x00000000
    re3: Unknown H/W revision: 0x4c000000
    device_attach: re3 attach returned 6</realtek></realtek></realtek></realtek> |

    Dicho esto voy al punto en que me encuentro estancado que tiene especial relevancia por ser nosotros un centro escolar que es el filtro y proxy web.

    Empezé con Squid3 y Dansguardian que después de algunos problemas, sobre todo por el Clamav incorporado con Dansguardian que se ejecutaba con un usuario erroneo, también quise cambiar la ruta de la base de datos de Clamav porque al usar ramdisk para \var ser perdia en el reinicio, y no conseguia que freshclam descargase automáticamente la base de datos además de que a veces le llevaba tiempo, por lo que cambié la ruta de \var\db\clamav a \usr\local\db\clamav. Está opción funcionó bien salvo que no conseguí que ser reescribieran las búsquedas para forzar el uso de safesearch pero encontré el problema de que no soportaba el filtrado de https por lo que decidí probar y cambiar a squid3-dev + squidguard.

    El problema en este punto es con squidguard que normalmente no arranca, pero a veces si, luego deja de funcionar… parece que el problema tiene alguna relación con ICAP que no se bien como funciona, pero tengo que desactivarlo o squid salta con mensajes de error bien de protocolo o bien de que no puede contactar con ICAP server. Debo decir que hice cambios respecto a la instalación estandar en cambiar la ruta de almacenamiento de la base de datos de clamav y la lista negra (shalla) de squidguard para que se almacene en /usr/local/db modificando manualmente los ficheros de configuración de paquetes en /usr/local/pkg y algún fichero de configuración. Desactivado el antivirus en proxy server veo que pasado un rato squidguard se inicia, pero no inmediatamente. En este punto veo que se fuerza safe search como lo tengo configurado pero parece ser que la redirección a la pantalla de bloqueo para sitios no permitidos con proxy transparente no puede ser a una página interna, sabe alguien la mejor manera de hacer esto en el propio pfsense de manera que de una información similar a como Dansguardian hace indicando motivo del bloqueo etc... Y por otro lado por donde empiezo para hacer funcionar el antivirus.

    Tendre más cosas según vaya avanzando y probando, pero de momento estoy en este punto.

    Saludos al grupo



  • @gromero:

    Dicho esto voy al punto en que me encuentro estancado que tiene especial relevancia por ser nosotros un centro escolar que es el filtro y proxy web.

    Empezé con Squid3 y Dansguardian que después de algunos problemas, sobre todo por el Clamav incorporado con Dansguardian que se ejecutaba con un usuario erroneo, también quise cambiar la ruta de la base de datos de Clamav porque al usar ramdisk para \var ser perdia en el reinicio, y no conseguia que freshclam descargase automáticamente la base de datos además de que a veces le llevaba tiempo, por lo que cambié la ruta de \var\db\clamav a \usr\local\db\clamav. Está opción funcionó bien salvo que no conseguí que ser reescribieran las búsquedas para forzar el uso de safesearch pero encontré el problema de que no soportaba el filtrado de https por lo que decidí probar y cambiar a squid3-dev + squidguard.

    El problema en este punto es con squidguard que normalmente no arranca, pero a veces si, luego deja de funcionar… parece que el problema tiene alguna relación con ICAP que no se bien como funciona, pero tengo que desactivarlo o squid salta con mensajes de error bien de protocolo o bien de que no puede contactar con ICAP server. Debo decir que hice cambios respecto a la instalación estandar en cambiar la ruta de almacenamiento de la base de datos de clamav y la lista negra (shalla) de squidguard para que se almacene en /usr/local/db modificando manualmente los ficheros de configuración de paquetes en /usr/local/pkg y algún fichero de configuración. Desactivado el antivirus en proxy server veo que pasado un rato squidguard se inicia, pero no inmediatamente. En este punto veo que se fuerza safe search como lo tengo configurado pero parece ser que la redirección a la pantalla de bloqueo para sitios no permitidos con proxy transparente no puede ser a una página interna, sabe alguien la mejor manera de hacer esto en el propio pfsense de manera que de una información similar a como Dansguardian hace indicando motivo del bloqueo etc... Y por otro lado por donde empiezo para hacer funcionar el antivirus.

    ~~¿ Te arranca squid3-devel + squidGuard-squid3 ?

    Hay un bug en squid3-devel, según el desarrollador…

    https://forum.pfsense.org/index.php?topic=73007.msg402082#msg402082~~

    Paquete pfSense 2.1 squid3-devel (moderador), https://forum.pfsense.org/index.php?topic=73007.msg402349#msg402349



  • squidGuard puede tomar su tiempo a arrancar…

    https://forum.pfsense.org/index.php?topic=73604.msg402093#msg402093



  • Hola Bellera,

    Gracias por tu aportación y estar ahí al pié del cañon…

    Finalmente creo que el problema es con el antivirus pues con el desactivado squidguard termina arrancando, aúnque puede tardar un buen rato y esto es lo que me confundía. El servicio c-icap y clamd estan en marcha pero si activo el antivirus en el proxy squidguard no arranca.

    estos son los mensajes que salian en el log

    |
    Mar 12 10:00:43 squid: Bungled /usr/pbi/squid-amd64/etc/squid/squid.conf line 152: icap_send_client_ip
    Mar 12 10:00:24 php: rc.start_packages: The command '/usr/pbi/squid-amd64/sbin/squid -f /usr/pbi/squid-amd64/etc/squid/squid.conf' returned exit code '1', the output was 'FATAL: Bungled /usr/pbi/squid-amd64/etc/squid/squid.conf line 152: icap_send_client_ip Squid Cache (Version 3.3.10): Terminated abnormally. CPU Usage: 0.009 seconds = 0.009 user + 0.000 sys Maximum Resident Size: 31472 KB Page faults with physical i/o: 0'
    Mar 12 10:00:24 squid: Bungled /usr/pbi/squid-amd64/etc/squid/squid.conf line 152: icap_send_client_ip
    Mar 12 10:00:14 squid: Bungled /usr/pbi/squid-amd64/etc/squid/squid.conf line 152: icap_send_client_ip
    Mar 12 10:00:07 squid: Bungled /usr/pbi/squid-amd64/etc/squid/squid.conf line 152: icap_send_client_ip
    Mar 12 09:59:59 php: /status_services.php: The command '/usr/local/etc/rc.d/c-icap stop' returned exit code '1', the output was 'c_icap not running? (check /var/run/c-icap/c-icap.pid).'
    Mar 12 09:53:35 kernel: pid 14512 (c-icap), uid 106: exited on signal 11
    Mar 12 09:53:35 kernel: pid 13735 (c-icap), uid 106: exited on signal 11
    Mar 12 09:53:25 kernel: pid 35565 (c-icap), uid 106: exited on signal 11
    Mar 12 09:53:25 kernel: pid 11571 (c-icap), uid 106: exited on signal 11 |

    He buscado las opciones que indica marcelloc para comentar, pero no las encuentro. Pero he de decir que aparentemente está funcionando, el único problema es que cuando una página es bloqueada sale un error del proxy sin informacíon, como si no pudiese acceder a internet. Que supongo que esta relacionado con la configuración de la redirección en caso de bloqueo. Para esto quisiera usar una página entregada por el propio pfsense pero en las opciones de configuración dice que en caso de usar el modo transparente no se pueden usar paginas internas.. ¿Podeis confirmarme esto?



  • en las opciones de configuración dice que en caso de usar el modo transparente no se pueden usar paginas internas.. ¿Podeis confirmarme esto?

    Tiene lógica. El modo transparente es un redireccionamiento incondicional de la navegación. Si se envía a la misma máquina debe provocarse un bucle.



  • Eso tenía entendido pero (y ahí va supongo la perogrullada) ¿no es posible en vez de usar el modo transparente, crear redirecciones NAT que funcionen de forma similar al modo transparente que redireccionen todo menos a pfsense para que pfsense entrege la página?.

    Saludos



  • Es una idea…

    Declara el modo transparente en Custom Options y haz, efectivamente, el redireccionamiento "a mano"

    En Documentación (arriba), Forzar el uso de squid externo a pfSense

    Esto puede darte una idea de cómo redirigir, exceptuando la propia máquina.

    ¡Suerte!



  • Hola,

    He probado a desactivar el modo transparente, creando las redirecciones con reglas nat y bloqueando las salidas por 80 y 443 excepto a pfsense pero sale un error del proxy. (adjunto imágenes)

    ![Error proxy.gif](/public/imported_attachments/1/Error proxy.gif)
    ![Error proxy.gif_thumb](/public/imported_attachments/1/Error proxy.gif_thumb)
    ![reglas nat.gif_thumb](/public/imported_attachments/1/reglas nat.gif_thumb)
    ![reglas nat.gif](/public/imported_attachments/1/reglas nat.gif)
    ![reglas firewall.gif_thumb](/public/imported_attachments/1/reglas firewall.gif_thumb)
    ![reglas firewall.gif](/public/imported_attachments/1/reglas firewall.gif)



  • squid no transparente

    [2.1-RELEASE][admin@pfSense.localdomain]/root(6): pfctl -s rules > reglas_squid_no_transparente.txt
    [2.1-RELEASE][admin@pfSense.localdomain]/root(7): pfctl -s nat >> reglas_squid_no_transparente.txt
    [2.1-RELEASE][admin@pfSense.localdomain]/root(8): find / -name squid.conf
    /usr/pbi/squid-i386/etc/squid/squid.conf
    [2.1-RELEASE][admin@pfSense.localdomain]/root(9): cp /usr/pbi/squid-i386/etc/squid/squid.conf squid.conf_no_transparente.txt
    

    Activo squid transparente

    [2.1-RELEASE][admin@pfSense.localdomain]/root(10): pfctl -s rules > reglas_squid_transparente.txt
    [2.1-RELEASE][admin@pfSense.localdomain]/root(11): pfctl -s nat >> reglas_squid_transparente.txt
    [2.1-RELEASE][admin@pfSense.localdomain]/root(12): cp /usr/pbi/squid-i386/etc/squid/squid.conf squid.conf_transparente.txt
    

    Diferencias

    [2.1-RELEASE][admin@pfSense.localdomain]/root(13): diff reglas_squid_no_transparente.txt reglas_squid_transparente.txt
    77a78,79
    > pass in quick on em0 proto tcp from any to ! (em0) port = http flags S/SA keep state
    > pass in quick on em0 proto tcp from any to ! (em0) port = 3128 flags S/SA keep state
    89a92
    > rdr on em0 inet proto tcp from any to ! (em0) port = http -> 127.0.0.1 port 3128
    [2.1-RELEASE][admin@pfSense.localdomain]/root(14): diff squid.conf_no_transparente.txt squid.conf_transparente.txt
    4a5
    > http_port 127.0.0.1:3128 intercept
    
    


  • Por tanto, si en Custom Options del configurador de squid añades:

    http_port 127.0.0.1:3128 intercept
    

    squid pasa (si respeta eso) a modo transparente.

    y el redireccionamiento

    rdr on em0 inet proto tcp from any to ! (em0) port = http -> 127.0.0.1 port 3128
    

    debería ser, a mi entender:

    rdr on em0 inet proto tcp from !127.0.0.1 to ! (em0) port = http -> 127.0.0.1 port 3128
    

    si la sintaxis de rdr lo admite.

    Los rdr en el configurador de pfSense son los NAT Port Forward.

    em0 es mi LAN address (mi placa de red LAN).

    A ver si hay suerte…



  • Muy ilustrativo Bellera, ya se un poco más de como moverme con el pfsense. Lo probaré y comento… :o



  • Hola,

    Gracias Belera por la información, lo del certificado ya lo había leído y lo tenia claro, pero después de unos días dedicado a otras tareas y solo a ratos haciendo alguna prueba más con pfsense, he decidido desestimar de momento squidguard y aunque tenga que renunciar al filtrado ssl ir con dansguardian que me parece más fiable en el funcionamiento además de filtrar el contenido no solo urls y del que espero que en no mucho tiempo incorpore esa posibilidad. De hecho si aparece en las opciones de configuración ajustes para ello pero siempre recibo errores de conexión ssl en las distintas pruebas que he hecho, si alguien puede darme alguna orientación sobre ello le sería muy agradecido.

    Ahora mismo estoy en hacer funcionar clamav, manteniendo squid3-dev que dispone de clamav también, por lo que tengo un conflicto al tener dos instalaciones con clamav. ¿Alguien sabría decirme si es preferible sustituir squid3-dev por squid3 (teniendo que cuenta que quiero en un futuro próximo disponer de filtrado https), o trastear los ficheros de configuración para que se use el que incorpora dansguardian? y en este caso ¿como hacer las modificaciones de manera que no se pierdan en las actualizaciones?.

    Saludos  :D



  • Arriba, en Últimas aportaciones a Documentación tienes bastantes cosas de la situación actual.

    Quienes parecen estar en el tema son los usuarios (y desarrolladores)

    @ Eduardo Gonçalves

    y

    @ marcelloc

    http://forum.pfsense.org/index.php?topic=72872.0



  • Hola Bellera,

    Había leído ese hilo, lo que pasa es que no me quedo muy claro si funciona en la versión amd64 que yo uso. ¿Crees que sería conveniente pasarme a la i386 para evitar problemas? Busco la máxima fiabilidad y sencillez posible.

    Además me ocurre algo raro, freshclam -V mi informa de la versión de dansguardian (0.97) pero clamd -V me dice la de squid-dev (0.98). Quizás sea por un gazapo que haya metido yo pues estuve trasteando haciendo cambios pero aunque desinstale e instale parece que sigue igual.

    Por otro lado ¿me puedes decir si en squid la interceptación https se puede usar sin el modo transparente? porque por las pruebas que estoy haciendo parece que no.

    Saludos.



  • @gromero:

    ¿Crees que sería conveniente pasarme a la i386 para evitar problemas?

    Por lo que he leído, parece ser que clamav no es estable con 64 bit. Pero no he hecho pruebas.

    @gromero:

    Quizás sea por un gazapo que haya metido yo pues estuve trasteando haciendo cambios pero aunque desinstale e instale parece que sigue igual.

    Entre una cosa y otra es probable que tengas restos de instalaciones. Ante la duda, empezar de cero y hacer pasos limpios.

    Hago estas cosas con un VirtualBox, que permite ir guardando imágenes de todo el disco, no sólo de config.xml

    La pega es que mi VirtualBox es de 32 bit.

    @gromero:

    ¿me puedes decir si en squid la interceptación https se puede usar sin el modo transparente? porque por las pruebas que estoy haciendo parece que no.

    No. Cuando activas el modo SSL se ponen en marcha los procesos para SSL Bump y los rdr (NAT de PF). No está separado.

    Tocando el código seguro que se puede deshabilitar la generación de las reglas rdr.



  • Bueno he empezado casi de 0 migrando la configuración que tenia de pfsense sin los paquetes adicionales a la versión i386 en la otra partición que tengo creada. He instalado los siguientes paquetes y he seguido los correspondientes tutoriales que hay por ahí:

    -Snort
    -Snort widget
    -pfblocker
    -squid3-dev
    -cron
    -OPENVPN client export

    los servicios estan todos funcionando (en  verde)

    Snort y pfblocker funcionan
    squid3-dev sin antivirus funciona
    squid3-dev con antivirus –--> Error de protocolo ICAP

    Esto mismo me pasaba en la versión amd64 y no paso de aquí. he modificado en opciones del antivirus la linea del redirect al clwarn.cgi por en nombre y dominio del firewall y también he probado con la ip pero nada. ¿Puede tener que ver el que el webconfigurator escucha por https en el puerto 2345?

    Saludos.



  • Con tanto movimiento sobre squid3-devel en el foro veo que en este hilo no está:

    Antivirus Clamav en squid3-devel (i386)
    http://egoncalves.com.br/pfsense/pfsense-squid3-dev-clamav-i386/
    Para 64 bit (amd64), parece que no funciona, https://forum.pfsense.org/index.php?topic=72872.msg400869#msg400869

    No sé si seguiste este tutorial…



  • Si lo he seguido y creo que correctamente, los servicios clamd y icap están en marcha pero sale ese error, squid3-dev y squidguard funcionan pero con la opción antivirus desactivada. La diferencia en mi instalación es que al correr en ssd he configurado para que /tmp /var se monten en ramdisk. Para evitar que se pierdan las bases de datos en los reinicios configuré clamd y freshclam para que ubiquen las db en /usr/local/db/clamav. Lo que observo es que tengo que crear un script de inicio para crear el usuario clamav porque después de reiniciar no se porque se pierde.



  • No veo por qué esos cambios que dices deberían ser un problema.

    Pero ante la duda quizás deberías hacer las pruebas con /tmp y /var en el SSD.

    A ver si sucede lo mismo.

    En cuanto al usuario clamav, no deja de ser curioso. Igual se debe a que el usuario debería estar definido como administrador en el configurador de pfSense. En FreeBSD los usuarios que pueden llegar a root tienen que estar en el grupo wheel. Por eso digo de configurarlo como administrador.



  • Hola,

    Vamos avanzando, finalmente parece que están todos los servicios en funcionamiento y siguen funcionando entre reinicios (habia problemas con esto) el proxy funciona y filtra la web, pero el antivirus que antes no permitía la navegación (error de protocolo icap) ahora parece que no detecta nada pues me permite descargar el virus eicar sin advertirlo (http://www.eicar.org/85-0-Download.html). Habilite las opciones clamd_ip y clamd_port en squidclamav.conf y servername en c-icap.conf y creo que gracias a esto dejo de dar el error de protocolo pero como digo no detecta el eicar.

    Hay otras cosas que no termino de tener claras, tengo activado el proxy en modo transparente, y el webConfigurator esta configurado en el puerto 2345, por lo que entiendo que si las paginas de error o bloqueo se sirven con el mismo servidor web, no debería ser problema usar la página interna para anunciar los bloqueos sin embargo ocurre algo raro, si configuro el webconfigurator para que se sirva por http si funcionan la página interna de bloqueo del proxy, pero si configuro el webconfigurator para que vaya por https, no se muestra nada y el cliente no encuentra la página.

    Algo parecido pasa con el portal cautivo, si lo configuro para que use http, funciona y veo que direcciona al puerto 8000 para mostrar la página de identificación, si lo configuro para que use https, direcciona al puerto 8001 pero la página no es accesible y nunca carga.

    ¿Ideas?

    Saludos a todos.



  • Proxy Server: ACLs

    acl sslports	
    This is a space-separated list of ports to allow SSL "CONNECT" in addition to the already defined list: 443 563
    

    Tienes que añadir el puerto 2345 ahí, si no lo hiciste.

    A ver qué tal.



  • Gracias Bellera por tu paciencia,

    Efectivamente, no había añadido estos puertos, y por si acaso añadí para ver si se soluciona lo del portal cautivo también quedando la cosa así:

    acl safe ports : 2345 8000 8001
    acl ssl ports: 2345 8001

    Activé el web configurator y el portal cautivo para usar https, pero el resultado sigue siendo en el caso del bloqueo de squidguard sale el error del proxy diciendo que http://192.168.4.200:2345/sgerror.php? respuesta vacía(tamaño cero) y en el caso del portal cautivo sencillamente se queda esperando hasta que pasa el tiempo de espera y no carga nada.

    Un saludo



  • Discutimos esto ya. ¿Probaste lo comentado?

    @bellera:

    Por tanto, si en Custom Options del configurador de squid añades:

    http_port 127.0.0.1:3128 intercept
    

    squid pasa (si respeta eso) a modo transparente.

    y el redireccionamiento

    rdr on em0 inet proto tcp from any to ! (em0) port = http -> 127.0.0.1 port 3128
    

    debería ser, a mi entender:

    rdr on em0 inet proto tcp from !127.0.0.1 to ! (em0) port = http -> 127.0.0.1 port 3128
    

    si la sintaxis de rdr lo admite.

    Los rdr en el configurador de pfSense son los NAT Port Forward.

    em0 es mi LAN address (mi placa de red LAN).

    A ver si hay suerte…



  • Cuando me propusiste esto entendí que era para el caso de que no usase el modo transparente y yo quisiese controlar las redirecciones, pero como comencé de nuevo con la versión i386 y estoy usando el modo transparente, no lo creí necesario. Lo probaré.

    Saludos.



  • Ahora mismo no tenía activas las redirecciones, si intento añadir la que propones sale esto:

    [2.1-RELEASE][admin@firewall]/root(3): rdr on re4 inet proto tcp from !127.0.0.1 to ! (re4) port = http -> 127.0.0.1 port 3128
    127.0.0.1: Event not found.

    Saludos.



  • Lo he intentado hacer desde el webconfigurator y me sale esto(que no es lo mismo ¿o si?):

    
    [2.1-RELEASE][admin@firewall]/root(6): pfctl -s nat | grep re4
    rdr on re4 proto tcp from ! <localhost>to ! <localhost>port = http -> <localhost>port 3128 round-robin
    rdr on re4 proto tcp from ! <localhost>to ! <localhost>port = https -> <localhost>port 3129 round-robin
    rdr on re4 inet proto tcp from any to ! (re4) port = http -> 127.0.0.1 port 3128
    rdr on re4 inet proto tcp from any to ! (re4) port = https -> 127.0.0.1 port 3129</localhost></localhost></localhost></localhost></localhost></localhost> 
    

    Pero el resultado sigue siendo el mismo: si habilito https para el portal cautivo y webconfigurator, no se abre el portal, si habilito https para el webconfigurator y no para el portal cautivo, el cliente se conecta y navega, pero la redirección de pagina bloqueada interna no esta accesible, con el portal cautivo y el webconfigurator por http todo funciona.

    Saludos.



  • Sigo intentando pero he visto que al menos con https activado para el webconfigurator, squidguard siempre redirecciona los bloqueos a http://192.168.4.200:2345/sgerror.php? independientemente de lo que que ponga en modo de redirección y url de redirección. Creo esto porque el mensaje del proxy siempre es el mismo, indicando lo de respuesta vacia de esta dirección.



  • @gromero:

    Si intento añadir la que propones sale esto:

    [2.1-RELEASE][admin@firewall]/root(3): rdr on re4 inet proto tcp from !127.0.0.1 to ! (re4) port = http -> 127.0.0.1 port 3128
    127.0.0.1: Event not found.

    Cualquier acción desde consola sobre PF (Packet Filter) tienes que hacerla con el comando pfctl. Lo que pusiste es sólo una regla de PF.

    Lo que quería decir es que si es un rdr tienes que entrarlo en Firewall - NAT Port Forward del configurador web. Disculpa por no explicarme más claramente.



  • @gromero:

    Lo he intentado hacer desde el webconfigurator y me sale esto(que no es lo mismo ¿o si?):

    localhost es lo mismo que 127.0.0.1

    Recordemos a quien pueda leer esto que lo que se pretende es que squid3-dev + squidGuard-squid3 tengan los avisos de squidGuard-squid3 en el propio pfSense a pesar de estar en modo transparente. Cuestión que el configurador web de squidGuard dice que no puede ser:

    Redirect mode	
    Select redirect mode here.
    Note: if you use 'transparent proxy', then 'int' redirect mode will not accessible.
    Options:ext url err page , ext url redirect , ext url as 'move' , ext url as 'found'.
    


  • He visto que pfctl hay que estudiarlo con tranquilidad, por lo que lo dejo para otro momento, pero no me aclaraste si:

    1.-Las reglas que me indicas ¿Las debo introducir también si uso el proxy en modo transparente?.
    2.-Las que yo he creado desde el webconfigurator ¿son equivalentes a la que propones?
    3.-Sin haber hecho nada especial (sin crear ninguna redirección para ello ni regla) y a pesar de que el configurador indica que no es posible usar la página interna, si funciona cuando está establecido el acceso por http para webconfigurator ¿se debe a que uso el puerto 2345 para el webconfigurator?.
    4.-¿Porque no funciona lo mismo usando https para webconfigurator?, He probado ha cambiar en 'common acl' el modo y la url de redirección pero parece que no hace caso, porque el proxy siempre da el mismo error. Adjunto imágenes para ver la salida en uno y otro caso. Aclaro que el cliente no tiene configurado el proxy y esta siendo redireccionado por pfsense.






  • cd /usr/local/pkg
    cp -p squidguard_configurator.inc squidguard_configurator.inc-2014-04-03
    vi squidguard_configurator.inc
    

    La línia que dice

    $rdr_path = "http://$guiip:$guiport" . REDIRECT_BASE_URL;
    

    cambiala por

     $rdr_path = "https://$guiip:$guiport" . REDIRECT_BASE_URL;
    

    A ver si te funciona cuando estás en modo https.

    Parece un fallo (bug) bastante evidente en squidguard_configurator.inc no prever que el webserver de pfSense debe estar sólo en este puerto y en modo SSL.



  • Es extraño, con el cambio que has propuesto, ahora pasa el timeout de cargar la pagina del error, que intenta encontrar en la siguiente dirección:

    https://192.168.4.200:80/sgerror.php? cuando antes de añadir la 'S' era http://192.168.4.200:2345/sgerror.php?

    no se porque a cambiado el puerto…



  • Por lo que he podido ver tras hacer el cambio y reiniciar se modificaron todas las redirecciones en /usr/pbi/squid-i386/etc/squid/squidGuard.conf que apuntan ahora al puerto 80. Porque ni siquiera dejándolo como antes funciona ahora que en vez de hacer la redirección al puerto del gui lo hace al puerto 80.



  • Aunque modifique manualmente /usr/pbi/squid-i386/etc/squid/squidGuard.conf o /usr/pbi/squidguard-squid3-i386/etc/squidGuard/squidGuard.conf (que son iguales) al reiniciar lo vuelve a dejar como estaba.



  • @gromero:

    Por lo que he podido ver tras hacer el cambio y reiniciar se modificaron todas las redirecciones en /usr/pbi/squid-i386/etc/squid/squidGuard.conf que apuntan ahora al puerto 80. Porque ni siquiera dejándolo como antes funciona ahora que en vez de hacer la redirección al puerto del gui lo hace al puerto 80.

    Sería lo ideal, pues no es nada elegante que las páginas de error estén en modo SSL. Problemas con el certificado y "conocimiento" del puerto usado para administrar pfSense.

    Prueba:

    $rdr_path = "https://$guiip:2345" . REDIRECT_BASE_URL;
    

    Recordemos, no obstante, que en el configurador hay un aviso diciendo que si se está en modo transparente no se puede emplear la página de error interna.

    ¿No puedes tener un servidor web o incluso otro pfSense, virtualizado, para los avisos?



  • @gromero:

    Aunque modifique manualmente /usr/pbi/squid-i386/etc/squid/squidGuard.conf o /usr/pbi/squidguard-squid3-i386/etc/squidGuard/squidGuard.conf (que son iguales) al reiniciar lo vuelve a dejar como estaba.

    Evidente. Eso lo genera el configurador web. Es como trabaja pfSense.

    Tengo bloqueado eso en mis últimos pfSense porque necesito un squidGuard.conf que el configurador web no me da. Una vez ajustado, sólo preciso modificar las listas existentes. Lo tienes explicado en https://forum.pfsense.org/index.php?topic=73759.msg404367#msg404367



  • @bellera:

    Sería lo ideal, pues no es nada elegante que las páginas de error estén en modo SSL. Problemas con el certificado y "conocimiento" del puerto usado para administrar pfSense.

    Quería decir que el servidor web de pfSense debería funcionar en modo https para su administración y en modo http para el resto. Si no es así, es que algo no está bien.



  • Teniendo en cuenta lo último que dije, el código debería ser:

    $rdr_path = "http://$guiip" . REDIRECT_BASE_URL;
    

    Sin el puerto, pues. Ese debería ser el error en el paquete squidGuard.



  • Estoy de acuerdo, no me gusta la posibilidad de servir la página de error por https, pero menos me gusta tener que forzar al gui a funcionar por http. Lo intentaba hacer así porque creía que sería un requisito para que funcionase la página de error, pero es cierto que aúnque esté activo el https para el gui sigue siendo posible acceder por http (tengo deshabilitada la redirección a https cuando se accede por http) por lo que no entiendo porque no puede cargar la página…



  • @bellera:

    Teniendo en cuenta lo último que dije, el código debería ser:

    $rdr_path = "http://$guiip" . REDIRECT_BASE_URL;
    

    Sin el puerto, pues. Ese debería ser el error en el paquete squidGuard.

    Haz este cambio y [Apply] a la configuración de squidGuard. A ver qué.


Log in to reply