¡Hola! A ver si lo entiendo bien. Estás hablando de un portal cautivo con pfSense, con usuario y contraseña para pasar por él. Y lo que quieres es que tu portal cautivo reconozca además del usuario/contraseña (que debe ser personal e intransferible -como todos los usuario/contraseña-) la máquina asociada a ese usuario/contraseña para que el usuario/contraseña no se pueda emplear desde otra máquina. En el portal cautivo tienes unos primeros acercamientos a la resolución de tu problema: *** [Concurrent user logins], que permite asegurar que un usuario/contraseña sólo sirva para UNA conexión simultánea. *** [Pass-through MAC], para poner MAC que se "saltan" el portal cautivo. *** [Allowed IP addresses], para autorizar o denegar determinadas IPs en el portal cautivo. Para ir más lejos tendrías que pensar en una autentificación con un servidor FreeRadius externo, cuestión prevista en el portal cautivo. En http://www.onlamp.com/pub/a/onlamp/excerpt/radius_5/index1.html se explica cómo montar FreeRadius sobre FreeBSD. En la segunda página de este tutorial hay un usuario de prueba en el que parece (no lo he probado) que se controla la IP desde donde se conecta: steve  Auth-Type := Local, User-Password == "testing"        Service-Type = Framed-User,        Framed-Protocol = PPP,        Framed-IP-Address = 172.16.3.33,        Framed-IP-Netmask = 255.255.255.0,        Framed-Routing = Broadcast-Listen,        Framed-Filter-Id = "std.ppp",        Framed-MTU = 1500,        Framed-Compression = Van-Jacobsen-TCP-IP Si no tienes muchos usuarios no te merece la pena montar todo este tinglado. Simplemente asegúrate de dos cosas elementales en seguridad: *** El usuario/contraseña es personal e intransferible. Legalmente es un tema "serio". Informa a tus usuarios de ello. Por su seguridad (y por la tuya). *** No conviene que servicios tan dispares como el acceso al ordenador personal y el acceso a un servicio de portal cautivo tengan el mismo usuario/contraseña. Ya sé que esto es un engorro para usuarios y administradores, pero las "llaves maestras" son un mal asunto. Saludos, Josep Pujadas

Hola! Teoricamente como dices es compatible y ademas desde la Release 6.1 de FreeBSD. Prueba de entrar en el shell y ejecuta el comando dsmeg | more  o descargarte  este archivo  /var/log/system.log  y mirarlo con un editor de texto. Igualmente, cerciorate que funciona correctamente la tarjeta de red. Saludos

Hola, ya entiendo ahora si el camino a seguir. Tenia desde hace tiempo esta duda, pero ya estoy ahora si suguro de lo que tengo que hacer. Muchas gracias  ;D ;D ;D!!!

¡Buenas noches! Estas cosas pasan, ya se sabe … ¡De nada! ¡Hasta otra! Saludos, Josep Pujadas

¡Hola! WebGUI sólo está, por defecto, accesible desde la LAN. Si quieres prohibir el acceso desde la LAN, pon una regla de bloqueo. Por ejemplo, si bloqueas de LAN a LAN el puerto TCP 80 (o TCP 443 si has puesto tu WebGUI en modo https), nadie de la LAN podrá acceder a tu WebGUI. Si después de esto (¡ojo, no actualices hasta estar seguro!) deseas dar permiso a una máquina de la LAN para acceder a tu WebGUI bastará que pongas por delante de la regla de bloqueo una que autorice el tráfico desde la IP de la máquina de administración hacia la IP de la LAN de tu pfSense en el puerto que tengas tu WebGUI. Si deseas acceder desde la WAN a la WebGUI de pfSense creo recordar que hay que emplear un puerto que no sea ni el 80 ni el 443 y poner la regla de paso correspondiente … Todo esto también es aplicable a la consola SSH (TCP 22) que tiene pfSense. Y en caso de dudas, pinchar una máquina en el lado supuestamente problemático y probar que no haya ningún cabo suelto ... Saludos, Josep Pujadas

¡Hola! Pienso que tendrías que usar la opción PPPoE en la interfase WAN (tu módem ADSL): http://www.bellera.cat/josep/pfsense/config_base_cs.html#interfaces_WAN Y, por supuesto, asegurarte que tu módem ADSL es compatible con FreeBSD 6.2: http://www.freebsd.org/releases/6.2R/hardware-i386.html#MISC-NETWORK El módem es visto como una tarjeta de red más, mediante el driver sbsh: http://www.freebsd.org/cgi/man.cgi?query=sbsh&sektion=4&manpath=FreeBSD+6.2-RELEASE No te puedo decir más porque nunca he realizado este montaje. No me gusta que las líneas telefónicas "entren" en los servidores. Las prefiero a parte, por razones de seguridad eléctrica. Saludos, Josep Pujadas

Hola Josep, Ya he encontrado el fallo, como siempre en estos casos era una tontería. En el interfaz WAN tenía marcada la opción "Block private networks" (la marqué porque los firewalls irán en un entorno con direcciones públicas). Esto me creaba una regla que me bloqueaba la sincronización CARP de los interfaces WAN. Gracias por todo. Un saludo. Pablo

¡Hola! Gracias por tus palabras de ánimo … A ver, es sencillo lo que quieres hacer. Está en el tutorial. *** Regla en la LAN que permita todo hacia la Wireless *** Regla en la Wireless que permita todo hacia la LAN (aunque yo no haría esto, lo limitaría a los servicios que realmente tienes que usar): http://www.bellera.cat/josep/pfsense/imatges/rules_Wireless_1.gif Eso es todo. No necesitas NAT para nada aquí.

Gracias, me queda claro que no lo incluirán en la versión 1.2 y que tampoco está en la lista de prioridades. Entiendo perfectamente, ya que como dicen existen otros temas mucho más importantes. Saludos, Maxi

¡Hola! No tengo nada claro que CP (Captive Portal) pueda funcionar en la LAN. Cuando un ordenador se conecta a la interfase donde está CP pfSense bloquea todo, no sólo la navegación. Y en LAN se encuentra, en principio, el acceso a pfSense por SSH y webGUI (http o https) … Si lo que estás usando es un PC yo añadiría una tarjeta de red y montaría CP en dicha interfase. Otra posibilidad sería emplear una LAN virtual, aunque no he explorado el comportamiento de pfSense empleando VLAN ... Saludos, Josep Pujadas

@nucleolan: Aca para modo transparente dice lo siguiente (If transparent mode is enabled, all requests for destination port 80 will be forwarded to the proxy server without any additional configuration necessary.) Que si lo activo tengo que hacer modificaciones ¿Sabes cual es la que tengo que hacer para que me tome el cache? ¡Hola! Hablamos de esto en http://forum.pfsense.org/index.php/topic,6077.msg35798.html#msg35798 Poner el proxy en modo transparente significa que no hay que hacer nada en los navegadores porque toda la navegación pasará por squid forzosamente. En http://forum.pfsense.org/index.php/board,26.0.html algunos usuarios dicen que squid transparente + Traffic Shaper no funciona. Yo no lo he probado, pero tal como ya te recomendé, mejor poner squid en otra máquina (más complejidad pero más potente y flexible). Saludos, Josep Pujadas

Miguel, Exacto. Sólo debes preocuparte de lo que entra. Si miras el tutorial que tengo publicado, el caso expuesto también tiene seis interfases: http://www.bellera.cat/josep/pfsense/cas_estudi_cs.html En pfSense inicialmente está todo prohibido, por lo que tendrás que ir autorizando el tráfico que quieras. No es posible alcanzar la red opt3 desde la red opt1 a no ser que en opt1 tengas puesta una regla que permita ese tráfico. Mira los ejemplos en: http://www.bellera.cat/josep/pfsense/regles_cs.html Fíjate bien también en las gateway (puertas de enlace), ya que el resultado es bien distinto si hay una u otra. A parte de autorizar el tráfico hay que indicar (o no) por donde debe ir. Extendiéndome en esto de las gateway, diré que jugar con ellas te permite incluso cambiar por dónde irá a Internet una determinada máquina y/o toda una red. Muy interesante … Saludos, Josep Pujadas

sos un capo ballera, FIXED close

¡Hola! Bloquear en la WAN cualquier tráfico ORIGINADO en una dirección IP (que debería ser) privada: http://es.wikipedia.org/wiki/Red_privada Por tanto, tu router ADSL no origina, en principio, nada para pfSense. Si te llegan paquetes ORIGINADOS en una dirección IP privada mejor descartarlos. Es lo que hace pfSense si tienes esto activado. Saludos, Josep Pujadas

¡Hola! Para el balanceo de carga puedes mirar: http://www.netlife.co.za/content/view/34/34/ El balanceo está pensado básicamente para navegación y debes cerciorarte que desde pfSense tus IPs públicas contesten a ping, ya que es el modo que tiene pfSense para saber si están "vivas". En cuanto a las restricciones puedes cortar servicions basándote en rangos de IPs (por ejemplo, prohibir todo MicroSoft -un poco drástico-), puertos (desgraciadamente hay servicios no deseables que trabajan con el puerto 80) o con un proxy. Si estás empleando la versión instalada en disco duro puedes usar el paquete squid como proxy. Esto te permitirá "acotar" contenidos. De todas maneras, si lo que deseas es llegar muy a fondo con este tema te recomiendo montar un squid + squidguard (o parecido) en una máquina a parte. Saludos, Josep Pujadas

¡Hola! Yo probarías desde cero, teniendo la configuración  XML tampoco es demasiado tiempo … Claro que si uno está tocando un cortafuegos en producción esto puede ser un problema. Aconsejo ir guardando los XML (pfSense los descarga con fecha y hora) para poder volver siempre a un XML que sabíamos seguro que funcionaba. La verdad es que conceptualmente el tema de los paquetes no me gusta. Yo metí pfSense en un PC monoplaca con una CF (Compact Flash) port razones de tamaño y no empleo paquetes (versión Embedded). Los servicios que pueden hacer los paquetes los tengo en máquinas externas (snort, squid, etc). No me gusta poner todos los huevos en la misma cesta ... En casa tengo un pfSense experimental montado en disco duro, con paquetes, y ntop me funciona sin problemas. Igual se ha liado tu configuración ... Saludos y ¡suerte! Josep Pujadas

Ok ….. Gracias me respondi solo, quizas fue un poco desesperada mi consulta, de todas fromas muchas gracias luego lo voy a molestar mas aun con la delimitacion de ancho de banda por cliente, bueno u  pard e reglitas que quiero aplicar ... Saludos