Incluye en lo que hay que eliminar rm -R /var/squidGuard después instala los paquetes de nuevo y todo funciona de nuevo. @bellera: @hatchivana: Saludos Señores. Tuve un problema similar con Squid y SquidGuard. Al final quite ambos Paquetes y elimine desde consola los directorios squid ubicados en /var/squid y tambien /var/db/squidGuard Reinicie y instale de nuevo ambos paquetes y comenzaron a funcionar de forma normal. Si es lo que dice… rm -R /var/squid rm -R /var/db/squidGuard reiniciar e instalar de nuevo los paquetes.

Muchas gracias por la respuesta. Amplío un poco más la información de mi propuesta. La idea que llevo en mente es tener una tarea automatizada (script) que descargue la lista de sitios dominios "maliciosos" de sitios como "http://www.malwaredomains.com/" y de forma automática actualice la zona en el unbound. Como alternativa, había pensado que todas las peticiones hechas al unbound en pfsense fuesen encaminadas a un mi servidor BIND en la DMZ y que este hiciese las peticiones recursivas a DNS públicos y también tuviese el listado de dominios bloqueados, pero me gustaría hacerlo todo en un único paso;  tal y como ya lo tengo implementado con la parte de "publicidad" habíendo creado sendos scripts que descargan y actualizan dos ficheros .conf de unbound para bloquear los dominios que contienen publicidad. Seguiré investigando y si encuentro la solución lo publicaré por aquí Gracias de nuevo por la respuesta.

Si antes no había problemas y los clientes no tienen cortafuegos por software que esté bloqueando el tráfico… Parece evidente que tienes un problema de enrutado en el sitio B. El enrutador que está en B no devuelve el tráfico que le viene de A por el túnel. Lo envía a internet. A –-> Juniper B ---> pfSense Revisa la configuración IPSEC pfSense. Postea, en todo caso, imágenes de lo que tienes en IPSEC y en Diagnostics: Routing tables ¡Ojo con los datos sensibles! MAC, direcciones públicas…

En migraciones anteriores pasaba esto: @bellera: https://redmine.pfsense.org/issues/4293 Comprueba que si es lo mismo.

@bellera: Extraño… Igual tienes un problema con el MTU. En hardware está explicado el tema, https://forum.pfsense.org/index.php?topic=23685.0 ¿Has hecho pruebas de MTU, tal como se explica?

Muchas gracias. Probaré de pasar de la GUI y lo configuraré en el Custom Options. Saludos.

Google VTI site:forum.pfsense.org https://forum.pfsense.org/index.php?topic=87386.msg483290#msg483290 No soportado. Lo siento. https://supportforums.cisco.com/blog/149426/advantages-vti-configuration-ipsec-tunnels Las últimas versiones de pfSense emplean https://www.strongswan.org para IPSEC. Google strongswan vti Alguien lo logró pero con Linux, https://lists.strongswan.org/pipermail/users/2014-December/007156.html

¿ 192.168.1.1/24 con DHCP parado junto a 192.168.30.0/23 con DHCP ? Raro, realmente muy raro que influya en lo que hacen los equipos 192.168.30.0/23 ¿No tendrás algún cable mal? ¿O algún bucle en el cableado?

Hola a todos He conseguido avanzar con este problema y lo he documentado todo en mi BLOG. Por si le puede servir de ayuda a alguien, este es el enlace: https://digimodes.wordpress.com/2015/03/23/tinc-vpn-en-pfsense-2-2-1-release/ Saludos

¡De nada y enhorabuena! Todos hemos aprendido… mucho. Puesto [SOLUCIONADO] en el Subject de la primera intervención. Puesto enlace a la solución en la primera intervención. Añadido también enlace al apartado Hardware, https://forum.pfsense.org/index.php?topic=23685.0

Creo que el problema que tienes es precisamente porque usas un repetidor… Recientemente discutido, https://forum.pfsense.org/index.php?topic=90304.msg499613#msg499613

@Antuan: Solo una observación, antes de pfSense tenia un Router DD-WRT usando el rango 169.254.x.x y este nunca tuvo problema alguno, me pregunto porque pfSense si tiene problemas. Pues parece que DD-WRT no cumple normas… https://forum.pfsense.org/index.php?topic=90951.msg503174#msg503174

@bellera: 169.254.0.0/16 es un rango para direcciones privadas, pero está reservado. Un equipo que esté configurado por DHCP toma una dirección aleatoria dentro de este rango si no consigue una dirección de un servidor DHCP en la red. No es recomendable trabajar dentro de este rango. (Véase http://www.ietf.org/rfc/rfc3330.txt y http://www.ietf.org/rfc/rfc3927.txt )

Es muy bueno lo que comenta Bellera en relacion a la resolucion por IPV4. Y tambien coincido en que una mala config del dansguardian puede provocar problemas de este tipo, me paso alguna vez con un ClearOS, la maquina que tenia no aguantaba el caudal de solicitudes que recibia y abria muchisimas instancias de dansguardian para tratar de darles servicio. Lo que provocaba que la navegacion fuera lentisima. Prueba sin filtrado y coméntanos que pasa. Saludos

No, lo siento. La instalación en cuestión tiene enlaces a 50/5. No a más, por costes. Google bridge ono 200 mbit Ponte serio y diles que si no dan una solución tendrás que cambiar, muy a pesar tuyo, de proveedor. ¡Suerte!

Tienes que marcar la casilla WebGUI redirect - Disable webConfigurator redirect rule Ver imagen When this is unchecked, access to the webConfigurator is always permitted even on port 80, regardless of the listening port configured. Check this box to disable this automatically added redirect rule. https://forum.pfsense.org/index.php?topic=70550.msg385726#msg385726 De todas maneras nunca he usado NAT Reflection, siempre DNS Split. Me parece mucho más coherente.  

Probando el segundo link, el primero descartado ya había realizado estas pruebas.. Gracias.. te cuento en un rato..