@JAyanami:

he reconfigurado los dyndns reiniciado el servidor pero no actualiza de forma automatica!!  :-\

Un hilo donde se habló de dyndns:

http://forum.pfsense.org/index.php?topic=55489.0

FTP no pasa, en principio, por squid.

Sobre logs, usa clog en consola. Un hilo donde se habló de clog:

http://forum.pfsense.org/index.php/topic,20999.msg108000.html#msg108000

¿PPTP?

https://doc.pfsense.org/index.php/What_are_the_limitations_of_PPTP_in_pfSense%3F

@ncolunga:

Si por usuario te refieres a IP puedes usar ntop.

Ok, gracias.
Una vez lo probe hace tiempo en una maquina linux, no lo vi en las opciones a instalar sobre el pfsense.
Insatalando…
Atte.

Antonio

Gracias, ya lo tengo andando. No como necesitaba exactamente pero la OpenVPN anda (y motivo de la consulta).
Ahora veo el pfsense estaba bien configurado, el problema era de las direcciones…

Gracias georgeman por tu tiempo, efectivamente comenzare a re-pensar mi red, aunque con 30 sucursales no es algo muy trivial que digamos...

Saludos.
Atte.

Antonio

Si el tal "media converter" te provee una IP publica estática directamente, entonces esa IP iria sobre la WAN del pfSense, y el gateway sería el gateway del ISP. Pero si te provee una IP privada detrás de un NAT o algo así, habria que evaluar como configurarlo (firewall transparente, o doble NAT, etc)

Georgeman, eres un genio!!!, ahora funciona correctamente. Puedo llegar a mi dmz sin problema y mis usuarios salen por la wan-adsl, y mis servidores en la dmz salen y entran por mi wan-dedicada. Te agradezco mucho toda tu ayuda.

Saludos.

Hola, que version estas manejando?
Saludos.

Para que los clientes reciban/visualicen mensajes deben tener un servicio de mensajería instalado. O sea que eso no depende de pfSense.

La excepción es navegación mediante portal cautivo, donde sí es posible enviar mensajes. Pero creo que sólo en la operación de desconexión. A verificar.

@joselms02:

en realidad no se en que momento realice esa configuración

Revisa la configuración de la/s Interface/s/DHCP Server, etc.

chuso…gracias por el dato

Creo que he encontrado la respuesta:
http://forum.pfsense.org/index.php/topic,24681.msg128277.html#msg128277

Esto me valdría?

Gracias.

no ninguna, aunque de preferencia que este limpio :P

Una disculpa, creo que no me explique, hay un tutorial que me muestra como hacerlo, pero el problema esta que cuando en le portal cautivo me pide usuario y pass, le coloco el usuario y pass de active directory, el portal cautivo solo me dice credenciales no validas, pero cuando hago un test sobre ese mismo usuario en el apartado de autentificacion de pfsense la autentificacion es satisfactoriapero en el portal cautivo no me mlo reconoce.@hani9:

Te dejo un link con un tema similar aquí en el foro y otro de gran ayuda.

acudo al foro porqeu ya busqeu en la red y mencionan qeu si se puede .

Concuerdo con ptt, periko tiene hasta una empresa de soporte, ve ahí al link de su profile, y el te puede ayudar, aparte es un usuario bastante experto.

A ver, tienes dos rangos privados separados por internet, ¿no?

http://es.wikipedia.org/wiki/Red_privada

¿Qué te conecta de un punto a otro? ¿Tienes una VPN funcionando?

A priori no veo forma directa de hacer ver que eres un equipo de la Oficina2 conectándote a otro de la Oficina2.

¿Por qué tiene que ser así? ¿No puede ser un equipo de la Oficina1 conectándose a otro de la Oficina2?

Al dimensionar instalaciones hay que tener en cuenta:

Cantidad de usuarios. Simultaneidad de uso. Hábitos de los usuarios. Cuellos de botella.

El uso de un cortafuegos junto a un filtrado de navegación web permite "acotar" los hábitos de los usuarios. Es decir, que los recursos de la red se empleen para las tareas que precisa la organización.

Los cuellos de botella pueden estar en puntos distintos de nuestra red. Cableado, dimensionado de cortafuegos y/o proxy y ancho de banda de la conexión.

En la sección de Hardware (arriba) tenemos algunos datos de rendimiento.

DNS resolution not functioning - the clients on the captive portal interface must either be using the DNS forwarder on pfSense, on the IP of the interface where the client resides (which is the default configuration), or if using some other IP for DNS, it must be an allowed IP entry. If DNS fails, the browser never issues the HTTP request, hence it cannot be intercepted and redirected.

Para que se cumpla esto, lo más simple es que los clientes tomen su IP con el DHCP de pfSense y que, a su vez, pfSense sea su servidor DNS. Verifica la configuración IP otorgada a tus clientes mediante comandos:

Linux
ifconfig
nmcli dev list iface eth0 | grep IP4
nm-tool

Windows
ipconfig /all

Firewall rules on the captive portal interface do not allow the initial HTTP request - if the user is trying to browse to google.com, but you're not allowing HTTP to google.com, the HTTP request will be blocked and hence cannot be redirected. Under Firewall>Rules, on the interface where captive portal is enabled, you must be allowing the traffic that you want to be redirected (most commonly HTTP to any destination).

Tus reglas deben permitir el tráfico http. Deshabilita el portal cautivo y prueba que sea así.

SI que existen….

Tienes ISO / IMG i386 --> 32bits

Tienes ISO / IMG amd64 --> 64Bits

http://pfsense.org/index.php@option=com_content&task=view&id=43&Itemid=44.html

Architectures

Starting with pfSense 2.0, there are versions for both i386 (32-bit) and amd64 (64-bit)  architectures. This architecture is noted in each of the filenames for download. If you are unsure which version to use, then use i386. It is the most mature and well-tested architecture, and it will work on both 32-bit and 64-bit capable systems. The amd64 architecture (which does work even on Intel 64-bit CPUs) can address more memory and may have other performance advantages, but requires a compatible CPU.