Por lo que entiendo, queres que todo lo que salga de la LAN con destino la LAN remota, se natee con la ip de la interfaz. Si es asi, depende del tipo de vpn que sea, En ipsec, basta con poner en la phase 2 que levanta ambas LAN, en el campo NAT/BINAT la ip de la interfaz Si es OVPN, requiere tocar los nateos de salida y crear un alias con la ip que quieras que te vean del otro lado

Esto puede ser un problema del cliente, hay aplicaciones (me paso con Viscosity para Mac) que asumen que por defecto tienen que enviar todo por el tunel o que la configuracion del cliente tenga el parametro redirect-gateway o un push de la red 0.0.0.0

Si los clientes se conectan por la ip de la WAN, no deberías empujarle esa red en la configuración de OVPN, al margen de eso y si las reglas de acceso estan correctas, deberia funcionar. Podrias hacer una captura de paquetes en la interfaz ovpn1 y ver si los intentos de acceder a la LAN por lo menos alcanzan al pfsense, si lo hacen, ver en el destino si estos llegan. Si no llegan a pfsense, no esta tomando la ruta empujada Si llegan a pfsense pero no al destino, hay una regla en el pfsense mismo que no lo permite Si llegan a pfsense, llegan al destino pero igual sigue sin haber respuesta, puede haber un problema de ruteo en el destino, le llegan los paquetes de la red OVPN pero los intenta sacar por otro equipo que no es el pfsense.

Las reglas en la WAN (por lo menos la de la imagen) esta mal. Igual las reglas de NAT deberían generar la correcta. El NAT de salida esta bien, eso ignoralo. Pone una imagen de las reglas en la WAN actuales y aseguráte que la puerta de enlace del equipo con Jabber sea el pfSense también. Adjunto como deberían quedar esas reglas por las dudas.    

Squid no filtra https por defecto. El problema es que al activarlo, varios sitios que usan https van a dejar de funcionar (sitios de google si se usa chrome por ejemplo). Squid se mete entre el sitio y el navegador, encripta entre el navegador y si mismo con un certificado propio y con el sitio web con el del sitio mismo. Chrome es bastante quisquilloso con esto porque asume un MITM (técnicamente es exactamente eso) y da unos hermosos carteles rojos. Yo usuaria limitadores para todo lo que tenga como destino el puerto 443. Mas simple, menos potencialmente destructivo.

Hola, lo mejor para estos casos es utilizar ipsec, lee algún tutorial que no es difícil montarlo. Eso si, debes tener ips fijas en las sucursales para establecer el túnel entre ellas. Yo lo uso desde hace tiempo y va de lujo. Saludos.

Hola, nosotros damos soporte de pfsense. Estamos en Sevilla. andeswifi.com, si quieres puedes contactar conmigo en soporte@andeswifi.com saludos.

Nosotros teníamos ese problema. Lo que veíamos es que el servicio inicia correctamente, pero el script de arranque después va y lo para.  :o Lo resolvimos con un watchdog. Hay un hilo en inglés https://forum.pfsense.org/index.php?topic=87441.msg546710#msg546710 Instalas el paquete "Service Watchdog" Te vas a Services - Service Watchdog y añades el servicio freeradius a la lista de servicios monitorizados. El Watchdog vigila que los servicios en su lista estén arrancados siempre. Si no los ven arrancados los arranca. De esta forma al iniciar el sistema, como el watchdog detecta el freeradius no está iniciado, te lo arranca. Nosotros tenemos este servicio monitorizado  por lo mismo que dices tu, y el DNS Forwarder porque con la cantidad de usuarios que tenemos, en ocasiones nos cruje.

Pero no puedes ingresar a esos servicios vía web, o por las aplicaciones, si es por las aplicaciones lo mas probable sean problemas de puertos que están cerrados

Hola. De la doc de pfSense, reglas para permitir tráfico de recursos compartidos Win, NETBIOS/MS-DS y acceder a ellos desde LAN a DMZ (otra red lan): https://doc.pfsense.org/index.php/Example_basic_configuration#Outbound_LAN To allow LAN to access windows shares on the DMZ, allow NETBIOS/Microsoft-DS from the LAN to the DMZ Allow TCP/UDP 137 from LAN subnet (NETBIOS) to DMZ subnet     Allow TCP/UDP 138 from LAN subnet (NETBIOS) to DMZ subnet     Allow TCP/UDP 139 from LAN subnet (NETBIOS) to DMZ subnet     Allow TCP 445 from LAN subnet (NETBIOS) to DMZ subnet Aunque para que funcione lo de resolver por nombre de máquina (formato smb \hostname, no dns), efectivamente, lo que te dice Bellera, solución: servidor WINs. Salu2

https://forum.pfsense.org/index.php?topic=23265.0 https://forum.pfsense.org/index.php?topic=72527.0

hola de nuevo, lo he vuelto a montar todo de nuevo y ahora si que funciona. pudo haber sido, como decías Bellera, que alguna ruta no estaba bien, pero después de tanto tiempo revisándolo opte por montarlo desde 0. Muchas gracias por la ayuda.

Como era de esperarse error mio, no me acordaba que instale squid desde el principio ahi es donde se configura las salidas, gracias por sunapoyo

Pues se arregló. Ayer descubrí que un switch de una de las WAN estaba defectuoso, hacía que los PFSense reportaran la interfaz con paquetes perdidos, siendo que el enlace está bueno. Luego de reemplazar el switch, reinstalé los paquetes de Squid y SquidGuard en el servidor de respaldo, actualicé la lista negra que uso para filtrar en el maestro y en el de respaldo,  luego arranqué los servicios y ya lleva todo un día funcionando bien. No sé si el problema era el switch o que la lista negra del maestro tal vez no estaba actualizada, eso no lo había hecho antes.

Es una tarjeta PCI-X? que miedo me dan…. imagino que la estaras usando en un bus PCI normal... SI tuviera que apostar diria que tiene pinta de un problema de hardware o del driver del pfsense. Probaria a forzar la velocidad a la mas baja posible y ver si los errores descienden, no se aun problema de autonegociacion que esas tarjetas de intel son muy especialitas

Hola. He instalado pfSense 2.2.6 amd64 en VMware WorkStation 12 player (ver. no comercial). Con las VMware Guest instaladas. Efectivamente, con fibra de 100Mbps de bajada, consigo como mucho un tercio de esa velocidad (33Mbps) (la subida es de 10Mbps la consigue al 100%) Con VirtualBox, el rendimiento es aún peor (bajadas entre 5Mbps y 15Mbps y subida entre el 50% y el 100%). Por lo que , a pesar del handicap del ancho de banda virtualiznando, migro a VMware. Con Cables Cat5 y 6 y NICs del anfitrión y switch: GigabitEthernet, pero … Imagino que la appliance CERTIFICADA VMware Ready Appliance de pfSense instaladola sobre ESXI, será otro cantar. Habrá que conseguirla :) Salu2

Tienes razón javcasta, acabo de probar y con la opción "allow default gateway switching" funciona. Lo que indico es necesario sólo cuando hay balanceo de carga. De todas formas para la pregunta de este hilo es necesario verificar si el pfsense que está como proxy tiene Internet.

Lo solucione poniendo todo en el mismo rango de ip del gateway. Radio 1: como AP, como Router. asigna dhcp, habilito puertos de las otras antenas sobre el rango de ip 192.168.6.xxx/24 Radio 2: como client, modo bridge, ip 192.168.6.xxz/24, port:802 Radio 3: como ap, modo bridge, ip 192.168.6.xxc/24 , port:803 Radio 4: como client, modo bridge, ip 192.168.6.xxv/24, port:804 pf: WAN 192.168.6.xxb/24 pf: Lan 192.168.1.1/24 Maquina conectada en la lan del pf: 192.168.1.15 Con esa configuracion de ejemplo funciona, llego a todas los radios, veo el modem de fiber. Puertos del PF, ninguno modificado, todo como esta en la foto de arriba posteadas. Muchas Gracias a los que aportaron!!!