Skip to content


Error PXE-E55 ProxyDHCP service did not reply to request on port 4011. Rembo detrás de cortafuego

“PXE-E55 ProxyDHCP service did not reply to request on port 4011” es el error que recibí después de una instalación de manual, limpia, de libro,… de Rembo versión 2 en un Fedora 12 con el servidor dhcp, versión 4.0, en el mismo equipo. El cortafuegos, activo por defecto en esta distribución, es el “culpable” del problema. La prueba es fácil, basta con deshabitarlo y todo va bien. Pero, si quiero o necesito tener activo el firewall ¿Qué puertos tengo que abrir para Rembo?.

Lo primero es comprobar que rembo está escuchando el puerto PXE (4011), con #>lsof -i udp, obtenemos un listado de las conexiones udp abiertas y por que proceso.

Cliente iniciando rembo

Cliente iniciando rembo

Para ver la configuración del cortafuegos podemos ejecutar #>system-config-firewall, o abrir la utilidad desde la interfaz gráfica en “Sistema->administración->cortafuego”. Esta utilidad escribe las reglas iptables en el archivo /etc/sysconfig/iptables. Tendremos que escribir una regla directamente en el archivo, ya que la utilidad gráfica se queda corta en este caso.

Este archivo tiene por defecto las siguientes reglas:

# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -j REJECT –reject-with icmp-host-prohibited
-A FORWARD -j REJECT –reject-with icmp-host-prohibited
COMMIT

La política por defecto para los paquetes de entrada es ACCEPT, pero no te engañes, sólo si los paquetes de entrada están relacionados o pertenecen a un flujo previamente establecido desde el servidor serán aceptados, para el resto, incluidas las conexiones nuevas, se devolvera un paquete ICMP con el código “Host Prohibited”.

Añadir la regla “-A INPUT -m state –state NEW -m udp -p udp –dport 4011 -j ACCEPT”, en principio, debería valer, aceptamos conexiones nuevas al puerto PXE, pero no es así.

No nos queda otra, para ver que está pasando, que instalar un sniffer de red y analizar los paquetes, por ejemplo con wireshark, sucesor del afamado ethreal. Ésto en fedora en bastante fácil, ejecutamos como root #>yum install wireshark wireshark-gnome, y listo. Ahora ejecutamos wireshark, “Aplicaciones->internet->wireshark”, y aplicamos un filtro para ver sólo los paquetes entre nuestro cliente y el servidor, este  puede valer “eth.dst == xx:xx:xx:xx:xx:xx || eth.src == xx:xx:xx:xx:xx:xx”, donde xx:xx:xx:xx:xx:xx, es la dirección ethernet del equipo cliente. Es decir, sólo capturamos los paquetes con origen o destino el equipo cliente.

Los paquetes capturados muestran la negociación dhcp entre el cliente y el servidor, una vez el cliente tiene ip, el servidor devuelve paquetes ICMP  destination unreacheable (host administratively prohobited).

En general esto puede ocurrir por dos motivos, según este tutorial de tcp/ip: http://ditec.um.es/laso/docs/tut-tcpip/3376c24.html,  que son:

  1. Si recibimos el paquete de un router, es porque el router no sabe que hacer con el paquete, como enrutarlo.
  2. Si lo recibimos de un equipo, significa que el protocolo especificado en el campo de número de protocolo del datagrama original no está activo, que ese protocolo no está activo en ese host o bien que es el puerto indicado el que no está activo.

Como sabemos que nuestro cortafuegos es el generador de estos paquetes, basta con buscar el puerto destino en el paquete anterior, para descubir los puertos a los que nuestro cliente pretende conectarse en el proceso de arranque con rembo. Sucesivamente son; 4012 (pda-gate), 4013(acl-manager), 69(tftp), 10008(octopus) y 10009(swdtp-sv).

Por último el cliente establece conxiones con puerto origen 1038 (mtqp) en un puerto arbitrario del servidor rembo.

Con esta información modificamos el fichero /etc/sysconfig/iptables, para permitir estas conexiones, quedando como sigue:

# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state –state NEW -m udp -p udp –dport 69 -j ACCEPT
-A INPUT -m state –state NEW -m udp -p udp –dport 10008 -j ACCEPT
-A INPUT -m state –state NEW -m udp -p udp –dport 10009 -j ACCEPT
-A INPUT -m state –state NEW -m udp -p udp –dport 4011 -j ACCEPT
-A INPUT -m state –state NEW -m udp -p udp –dport 4012 -j ACCEPT
-A INPUT -m state –state NEW -m udp -p udp –dport 4013 -j ACCEPT
-A INPUT -p udp –sport 1038 -j ACCEPT

-A INPUT -j REJECT –reject-with icmp-host-prohibited
-A FORWARD -j REJECT –reject-with icmp-host-prohibited
COMMIT

En negrita las nuevas reglas. Eso es todo, rembo detrás de un cortafuego restrictivo.

Posted in Sistemas.

Tagged with , , .


0 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.



Some HTML is OK

or, reply to this post via trackback.



Ir a la barra de herramientas