No forward-proxy ports configured

En el 2013, publicamos una serie llamada  Squid Cache, donde nos adentramos en el manejo del proxy  Squid, con algunos ejemplos de cómo debería configurarse en diversos escenarios.

A raíz de estas publicaciones, recibimos muchos comentarios y hemos continuado actualizando los contenidos de estos posts con las últimas novedades y errores relacionados, siguiendo nuestra política de "menos posts nuevos y más actualizaciones de los temas ya publicados".

Sin embargo, recientemente nos ha llegado una avalancha de comentarios relacionados con un mensaje misterioso del Squid, en /var/log/squid3/cache.log que dice "No forward-proxy ports configured", el cual  está afectando a los usuarios que utilizan  Endian,  Zentyal, y otras distros y aplicaciones que usan Squid. Inclusive, algunos usuarios han reportado que, una vez se produce el error, Squid se detiene o trabaja mal, teniendo que llegar al punto de crear alertas que vigilen el servicio de Squid para notificar al administrador en caso de caerse.

Lo que más nos llamó la atención es que este error no le salía a aquellos usuarios que habían configurado Squid3 para trabajar con dos tipos de tráfico diferente (transparente y caché manual), sugerido en  Firewall

Pruebas

Primero, esculcamos la Wiki de Squid para buscar alguna referencia y esto fue lo que encontramos:

Resumiendo la Wiki de Squid, este error se produce cuando se utiliza el puerto 3128 en modalidad intercept (http_port 3128 intercept), o sea en proxy transparente.
El paso siguiente fue montar un servidor y simular varios tipos de tráfico (caché manual y transparente). Pusimos el puerto well-known 3128 con la cláusula 'intercept' (para versiones anteriores a 3.1 se llamaba 'transparent') y voilá; generó el error No forward-proxy ports configured.

Sin embargo, al cambiar el número del puerto con esta cláusula, el error también se replicaba y la Wiki no menciona nada al respecto. Por otro lado, nos percatamos de que este error no es nuevo y viene presentándose desde la versión 3.3x.

Solución

Después de varias pruebas, concluimos que (por alguna razón que desconocemos) las nuevas versiones de Squid3, deben llevar siempre un puerto para el trabajo de proxy en modo caché manual (por default es 3128) y sin importar si dicho puerto se vaya a utilizar o no, siempre debe permanecer en el archivo de configuración squid.conf (/etc/squid3/squid.conf). No necesariamente debe ser 3128, pero sí alguno en ese modo de trabajo.
Y si el operador del proxy decide cambiarlo a modo transparente (cláusula 'intercept'), deberá crear un nuevo puerto para este tipo de tráfico, sin eliminar el puerto del proxy manual. Por default el puerto más utilizado para proxy transparente es el NAT 8080, pero puede ser cualquier otro puerto, siempre y cuando no sea reservado.
En otras palabras, el archivo squid.conf del proxy Squid3 (/etc/squid3/squid.conf), cuando va a trabajar en modo manual (los navegadores de los usuarios apuntando a la ip y puerto del proxy), deberá llevar una configuración similar al siguiente ejemplo:

http_port 3128

Y si va a trabajar en modo transparente (los navegadores de los usuarios están en modo automático o sin proxy), el archivo  squid.conf del proxy Squid3 (/etc/squid3/squid.conf), deberá incluir ambos puertos, similar al siguiente ejemplo:

http_port 8080 intercept
http_port 3128

Es importante destacar que, para mayor seguridad se recomienda poner la ip del proxy. Ejemplo:

http_port 192.168.1.10:3128
http_port 192.168.1.10:8080 intercept

Pero dos puertos abiertos en el Squid, aceptando tráfico, eventualmente puede (o no) representar un problema de seguridad dentro de nuestra red interna. En este caso, crearemos una regla en nuestro firewall que active y redireccione el tráfico al puerto donde queremos que el Squid3 trabaje y el otro puerto se cierra.
Ejemplo de iptables: (donde eth1 es el adaptador de la red local):

# variable iptables
iptables=/sbin/iptables
# ACCESO AL PROXY LAN ---> PROXY ---> INTERNET (3128 AND NAT 8080)
$iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 3128 # si es transparente cambiar a 8080
$iptables -A INPUT -i eth1 -p tcp --dport 8080 -j ACCEPT # activar si es proxy transparente
$iptables -A INPUT -i eth1 -p tcp --dport 3128 -j ACCEPT # activar si es proxy manual

También puede cambiar eth1 por el rango y mascara de la red interna. Esta regla es más común en escenarios donde existen varias subredes; cada una con un rango, puerto y modalidad diferente de trabajo.

iptables=/sbin/iptables
$iptables -t nat -A PREROUTING -s 192.168.1.0/24 -p tcp --dport 80 -j REDIRECT --to-port 3128 # si es transparente cambiar a 8080
$iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 8080 -j ACCEPT # activar si es proxy transparente
$iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 3128 -j ACCEPT # activar si es proxy manual

Actualización 2022

Y cuando termine de aplicar todas las reglas en su script, se recomienda usar una regla Ipset para cerrar los puertos o cerrar todas las conexiones:

$iptables -A INPUT -s 0.0.0.0/0 -j DROP
$iptables -A FORWARD -d 0.0.0.0/0 -j DROP

Imagen cortesía de Wikimedia