Que adaptadores de Red son (Marca / modelo) ?

Hola, desde la LAN a vpn externas

https://forum.netgate.com/topic/21817/recomendaciones-al-postear Con las correspondientes reglas de FW en el pfSense, y en el FW de cada Host, deberías tener "conectividad" entre los distintos segmentos de Red.... Revisa: https://docs.netgate.com/pfsense/en/latest/firewall/index.html

El Servidor DHCP para el Servicio VPN-Servidor, lo activas en la conf de la misma vpn del pfsense.

Problema resuelto. Teniamos todo correctamente pero el cliente tiene un un ISP por satelite (Viasat) y tienen un doble NAT creado internamente que no dejan acceder desde fuera hacia dentro. Lo que hemos hecho ha sido crear mandar las camaras por p2p a un dominio y salir por la oficina del servidor. Saludos y gracias,

Buenas tardes da uma olhada por aqui https://forum.netgate.com/topic/96893/howto-captive-portal-freeradius-local-mysql-user-friendly-single-step

@ptt said in No logro ver las cámaras desde fuera de mi red LAN: No, por default, pfSense tiene habilitado el FW, y el NAT La WAN de tu pfSense, tiene una IP pública ? Sí La LAN de tu pfSense es el GW del DVR ? Sííííí´....no diablos problema solucionado ptt estaba seguro que había configurado la puerta de enlace del DVR pero pues no hay que asegurar, te lo agradezco mucho ptt Ya puedo conectarme por web, ahora solo me falta por el IDMSS que usa el puerto 3777 y que supongo que tengo que hacer el NAT y su regla

@Yovanny en las opciones de free radius esta lo que buscas [image: 1557896906273-captura-de-pantalla-51.jpg]

@Joseguadalupe Si el servicio es por coaxial, ahora contrate uno por fibra óptica y hasta ahora ningún drama.

Captive Portal on pfSense 2.3/2.4 Captive Portal Si usas un producto determinado, lo más indicado es la documentación oficial. Saludos.

Pero asi me funciona ok, me da acceso a toda la red, simplemente me da ese error cunado trato de acceder a las SSL, comprendo lo que dices, pero antes de tener pfsense tenia un squid en ubuntu con las mismas caracter'isticas y funcionaba ok...

Buenos días, He conseguido hacer ping desde el cortafuegos a cualquier ip de la LAN, desde el servidor y desde el cliente. Pero de una maquina del server a una maquina del cliente, no tengo respuesta, si tengo respuesta desde el cliente al pfsense del servidor y veceversa. Alguien podría ayudarme? gracias.

@j-sejo1 cierto.... en ese caso te recomiendo que le heches un vistaso a estos enlaces: https://github.com/opnsense/core/issues/2238 https://github.com/pfsense/pfsense/pull/816 https://forum.netgate.com/topic/59570/dhcpd-with-multiple-ipv4-subnets-outside-of-local-interface-network-300us/42 https://happy-coder.com/2014/06/27/pfsense-custom-dhcpd-configuration/ https://blog.tinle.org/2013/01/09/single-dhcp-server-for-multiple-subnets-vlans-one-single-interface/ Suerte y si te sirve pues dejanos saber aca quizas a alguien mas le sirva. SAludos

debes crear un swich virtual al cual esta conectaro a la tarjeta fisica y tu switch fisico y configurar ese switch virtual con las vlan que van a pasar por el, yo uso vmware pero es el mismo principio

Quizas eliminaron o modificaron alguna regal en el nat portfordwarding... que no hace mas que capturar el trafico desde la lan hacia internet por puerto 443 y 80 hacia el puerto correspondiente en el localhost o ip donde esta escuchando squid, si no la tienen pues prueben crearla....

No se si esto te ayude, es para linux pero adecuandolo a pfsense o freebsd y tomando esa idea logica quizas te ayude, en lugar de reiniciar pues que haga un network restar o sequivalente #!/bin/sh # Script checks with ping 5 ICMP pings 10 times to DEF GW and if so # triggers networking restart /etc/inid.d/networking restart # Then does another 5 x 10 PINGS and if ping command returns errors, # Reboots machine # This script is useful if you run home router with Linux and you have # electricity outages and machine doesn't go up if not rebooted in that case GATEWAY_HOST='192.168.0.1'; run_ping () { for i in $(seq 1 10); do ping -c 5 $GATEWAY_HOST done } reboot_f () { if [ $? -eq 0 ]; then echo "$(date "+%Y-%m-%d %H:%M:%S") Ping to $GATEWAY_HOST OK" >> /var/log/reboot.log else /etc/init.d/networking restart echo "$(date "+%Y-%m-%d %H:%M:%S") Restarted Network Interfaces:" >> /tmp/rebooted.txt for i in $(seq 1 10); do ping -c 5 $GATEWAY_HOST; done if [ $? -eq 0 ] && [ $(cat /tmp/rebooted.txt) -lt ‘5’ ]; then echo "$(date "+%Y-%m-%d %H:%M:%S") Ping to $GATEWAY_HOST FAILED !!! REBOOTING." >> /var/log/reboot.log /sbin/reboot # increment 5 times until stop [[ -f /tmp/rebooted.txt ]] || echo 0 > /tmp/rebooted.txt n=$(< /tmp/rebooted.txt) echo $(( n + 1 )) > /tmp/rebooted.txt fi # if 5 times rebooted sleep 30 mins and reset counter if [ $(cat /tmprebooted.txt) -eq ‘5’ ]; then sleep 1800 cat /dev/null > /tmp/rebooted.txt fi fi } run_ping; reboot_f; http://www.pc-freak.net/blog/automatic-server-network-restart-script-reboot-script-based-ping-timeout-gateway/

Estas usando Man in the middle’ (MITM) ??? si es asi pues entonces esta frente al problema con el cert pinning o SSL pinning que usa google y algunos websites para evitar ataques de MITM lo que podrias hacer es evitar o saltar el acceso a google a travez de tu proxy prueba eso agregando el sitio en Bypass Proxy for These Destination IPs.. Alguien que me rectifique o aporte mas al tema estamos para aprender.... Algunos navegadores como Crome y Mozilla hacen uso de las llaves que luego de realizar la peticion como normalmente se hace pues adicionalmente usan llaves propias para este sitio en cuestion Una forma de detectar y bloquear muchos tipos de ataques MITM es la "cert pinning", tambien llamada "SSL pinning". Un cliente que realiza el anclaje de certificados agrega un paso adicional al protocolo TLS normal o al protocolo SSL: después de obtener el certificado del servidor de manera estándar, el cliente verifica el certificado del servidor contra los datos de validacion confiables. Normalmente, los datos de validacion de confianza se incluyen en la aplicacion, en forma de una copia de confianza de ese certificado, o un hash o huella digital de confianza de ese certificado o la clave pública del certificado. Por ejemplo, Chromium y Google Chrome incluyen datos de validación para el certificado * .google.com que detectó certificados fraudulentos en 2011. En otros sistemas, el cliente espera que la primera vez que obtenga un certificado de servidor sea confiable y lo almacene; durante las sesiones posteriores con ese servidor, el cliente verifica el certificado del servidor contra el certificado almacenado para protegerse contra los ataques MITM posteriores. *** algunos navegadores más nuevos (Chrome, por ejemplo) hacen una variación de la fijación de certificados utilizando el mecanismo HSTS. Precargan un conjunto específico de hashes de clave pública en esta configuración de HSTS, que limita los certificados válidos solo a aquellos que indican la clave pública especificada.