¡Hola!
De todos modos, el origen del trafico seguirá siendo siempre la LAN ¿no?…
Auguraba que sería 127.0.0.1 (localhost) porque no tengo una instalación como la tuya delante. Por lo que veo, está montado basándose en la IP de la LAN de pfSense. En realidad viene a ser lo mismo. Si lo han hecho así tendrán sus motivos …
Trabajo con FreeBSD (en el que está basado pfSense) y suelo emplear 127.0.0.1 cuando un servicio está en la propia máquina, por si algún día la cambio de IP. Entiendo que en el caso de pfSense da lo mismo porque el configurador ya rehace todo si se llegan a cambiar las IPs del equipo.
Por otro lado, cuando hablaba de origen del tráfico quería decir que si se pasa por un proxy desde el lado WAN siempre ser verá como origen de la petición la IP del proxy (LAN de pfSense), no la IP de cada cliente (una IP cualquiera de la LAN).
Cuando se instala squid se crea automáticamente esta regla:
If Proto Source Destination Target Description
LAN->LAN TCP LAN address LAN net Port: 3128 qlanRoot/qlanRoot
Eso es bueno. Quiere decir que está previsto que squid y Traffic Shaper trabajen juntos. Y si no lo entiendo mal, por la regla, que el tráfico del proxy no es modelado en el lado LAN, ya que va a la cola-madre. Lo cual es lógico que sea así.
Si, si tengo proxy transparente, voy a seguir investigando…
Pues como ya se dijo en http://forum.pfsense.org/index.php/topic,10726.msg61226.html#msg61226 el tráfico de tu proxy (en el lado WAN) no debe pasar por Traffic Shaper. Nadie contestó a mi suposición pero por lógica creo que proxy transparente y Traffic Shaper no deben poder trabajar juntos.
No tengo una instalación como esta para probarlo …
Si dispones de presupuesto, aisla el proxy del cortafuegos+modelador. Algún compañero propuso en su día dos pfSense, uno detrás de otro. Es una buena solución. También lo es configurar una máquina con FreeBSD y squid+squidguard, pero eso requiere conocimientos de entornos UNIX/Linux.
Saludos,
Josep Pujadas