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

bellera

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.

bellera

@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'.

gromero

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.

Proxy_block.JPG_thumb

Proxy_block_bad.JPG_thumb

bellera

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.

gromero

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…

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.

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.

bellera

@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?

bellera

@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

@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.

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.

gromero

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

@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é.

bellera

Ojo con la caché del navegador.

Bórrala a cada prueba.

Ayer hubo un usuario que se volvía loco con las pruebas de error de ClamAV y al final resultó ser la caché del navegador, con tantos cambios.

gromero

active https en el gui y el redirect del gui a https cuando se intenta acceder por http, active el modo transparente del proxy y vuala todo funcionando sin la modificación del squidguard_configurator.inc (lo deje como era originalmente), eso si el mensaje de error sale por https….