DHCP smart-proxy sending out wrong next-server IP address for TFTP. Said wrong IP address is also an external one for some reason

Support
, ,
1

Hi foreman community! So I just discovered this software and have been tinkering with it in the past few days. It really does have a steep learning curve.

Problem:
The foreman host which also has a dhcp and tftp smart-proxy is a fresh Centos 7.8.2003 KVM VM. A physical PXEbooting client in the network displays E32: TFTP Timeout after getting leased an ip address by the dhcp smart-proxy. I used a packet sniffer software to find out what was going on and I found out that the DHCP server is sending out a wrong next-server IP address. It should be 192.168.0.13(ip address of foreman host with dhcp proxy and tftp proxy) but it keeps sending out a wrong IP address of 49.57.50.46 for some reason.

Troubleshooting:

  1. Tried setting tftp_servername in tftp.yaml to IP address of foreman host.
  2. Tried setting supersede server.next-server = 192.168.0.13 in dhcpd.leases

Expected outcome:
DHCP should send out the right next-server address 192.168.0.13 (for my tftp proxy which is on the same machine as dhcp proxy) to pxebooting client.

Foreman and Proxy versions:
2.0
Foreman and Proxy plugin versions:

Distribution and version:
Centos 7.8.2003

Other relevant data:

2

We know! Sorry.

We are working on much improved documentation, this is still WIP but pay a visit:

https://docs.theforeman.org/web/

Get back to us with a feedback. We want to hear from you! Now.

  1. Foreman finds TFTP proxy you associated with your Subnet. If none is found, no filename option is created.
  2. It asks for tftp_servername setting via proxy API. It can be a hostname or a IP.
  3. If its not set, it takes smart proxy hostname.
  4. It returns this. UNLESS
  5. You use older version of proxy, in that case for compatibility reasons it uses this already deprecated trick which will be removed: it finds DNS PTR record for the hostname and that IP is added as DHCP option.
  def boot_server
    # if we don't manage tftp for IPv4 at all, we dont create a next-server entry.
    return unless tftp?

    # first try to ask our IPv4 TFTP server for its boot server
    bs = tftp.bootServer
    # if that failed, trying to guess out tftp next server based on the smart proxy hostname
    bs ||= URI.parse(subnet.tftp.url).host

    # only smart proxies with V2 API are supported
    if subnet.dhcp.has_capability?(:DHCP, :dhcp_filename_hostname)
      # we no longer convert the boot server to IPv4 - smart proxy modules are required to do so if they don't support hostname
      bs
    else
      begin
        Foreman::Deprecation.deprecation_warning('1.25', "DHCP proxy does not report dhcp_filename_* capability and reverse DNS search in Foreman will be removed.")
        ip = NicIpResolver.new(:nic => self).to_ip_address(bs) if bs.present?
        return ip unless ip.nil?
        failure _("Unable to determine the host's boot server. The DHCP smart proxy failed to provide this information and this subnet is not provided with TFTP services.")
      rescue => e
        failure _("failed to detect boot server: %s") % e, e
      end
    end
  end

So there you have it. Check which TFTP proxy have you associate with your subnet. If that’s correct, check PTR DNS record of the hostname you either set in TFTP setttings or you have in smart proxy URL. That could eventually turn into the IP address you see as it gets resolved on the Foreman server (not proxy!).

Does it make sense? :slight_smile:

3

I was having the same issue described here, and it turns out the the “supersede server.next-server” option in the lease needs to be the ip address in hexadecimal format. And instead of periods, each 8 bits of the address need to be separated by colons.

E.g, if my ip address is 192.168.0.11, then the “supersede server.next-server” setting should appear like this inside the lease:

supersede server.next-server = c0:a8:00:01;

In my case, this setting was set to the fqdn of my tftp server (Satellite). And it was converting the fqdn to an ip address that was completely unrecognizable in my environment.

Changing the value, and restarting the dhcpd service was enough to get my PXE boot pointing to the correct “next-server”.

Hope this information helps anyone else who stumbles across this thread :slight_smile: