[RFC] Per-subnet Foreman URL: native multi-homing support for Foreman server

Development
1

Problem

Foreman currently has a single global foreman_url setting. When the Foreman server has multiple network interfaces connected to different VLANs/subnets, there is no native way to tell hosts in each network to reach Foreman via the correct interface IP/hostname.

Real-world scenario: A Foreman server sits in a datacenter with interfaces in multiple VLANs:

eth0 (VLAN 10 - Infrastructure):      192.168.10.5  -> foreman-infra.example.com
eth1 (VLAN 20 - Development):  192.168.20.5  -> foreman-dev.example.com
eth2 (VLAN 30 - Production):           10.30.0.5     -> foreman-prod.example.com
eth3 (Management):               10.0.0.5      -> foreman.example.com

Each VLAN is isolated (no inter-VLAN routing, or routing is firewalled). Hosts in VLAN 10 can only reach Foreman via 192.168.10.5, hosts in VLAN 20 via 192.168.20.5, etc. Each interface has its own DNS name.

The problem: Foreman has only one global foreman_url (e.g. https://foreman.example.com). This URL is baked into:

  • Provisioning templates (kickstart/preseed URLs)
  • PXELinux/iPXE/GRUB2 templates (next-server, callback URLs)
  • Global Registration curl commands
  • Puppet/Salt/Ansible callback URLs
  • finish/user-data scripts

So a host in VLAN 10 gets a kickstart URL pointing to foreman.example.com — which it cannot reach. The host needs foreman-infra.example.com instead.

Today’s workaround: Deploy a separate Smart Proxy in each VLAN, even though the Foreman server already has direct connectivity to all of them. This means extra certificates, extra services, extra maintenance — all for what is essentially a URL routing problem.

Prior art

This has been requested repeatedly since 2015:

The common thread: it does not make sense to deploy a separate proxy for every VLAN when the Foreman server itself has direct connectivity to all of them.

Proposal

Add a per-subnet foreman_url override — a minimal, targeted change that solves the core problem.

What changes

  1. Subnet model: Add an optional foreman_url field to Subnet (IPv4 & IPv6).

  2. Template URL resolution: Modify the foreman_url() template helper — if the host’s primary subnet has foreman_url defined, use it; otherwise fall back to the global Setting[:foreman_url].

  3. Registration: Global Registration templates use the subnet-specific URL so the curl command points to the right Foreman interface.

  4. PXE / TFTP: For PXE boot, next-server (TFTP) should point to the Foreman/Proxy interface IP on the provisioning subnet. Could use the subnet URL or a separate tftp_server field.

  5. Certificates: The Foreman server SSL certificate needs SANs for all interface hostnames. The installer could accept multiple --certs-foreman-server-san entries.

What does NOT change

  • Smart Proxy architecture — this is purely additive
  • Global foreman_url remains as default fallback
  • Simple single-network deployments are unaffected
  • Foreman-to-Proxy communication is unaffected

Example configuration

Subnet: "VLAN 10 - Infrastructure"
  Network:     192.168.10.0/24
  Foreman URL: https://foreman-infra.example.com
  Gateway:     192.168.10.1
  DNS:         192.168.10.2

Subnet: "VLAN 20 - Development"
  Network:     192.168.20.0/24
  Foreman URL: https://foreman-dev.example.com

Subnet: "VLAN 30 - Production"
  Network:     10.30.0.0/24
  Foreman URL: https://foreman-prod.example.com

Global Setting (fallback):
  foreman_url: https://foreman.example.com

When a host in VLAN 10 is provisioned or registered, all templates render URLs pointing to foreman-infra.example.com. VLAN 20 hosts get foreman-dev.example.com. Hosts without a subnet-specific override get the global default.

Implementation phases

Phase 1 — Minimal viable (templates & registration):

  • Add foreman_url column to subnets table
  • Modify foreman_url() template helper to check host’s subnet first
  • UI: add the field to subnet edit form
  • Update registration template to use subnet-aware URL

Phase 2 — Provisioning (PXE/TFTP/DHCP):

  • PXELinux/iPXE/Grub2 templates use subnet-aware URLs
  • Handle next-server / TFTP server IP per subnet
  • DHCP module respects per-subnet Foreman address

Phase 3 — Installer & certificates:

  • foreman-installer support for multi-SAN certificates
  • Option to configure Apache to listen on specific interfaces
  • Documentation for multi-homed setups

Questions for the community

  1. Is a simple per-subnet foreman_url field sufficient, or should this be a more general “endpoint” concept (as proposed in the 2017 RFC)?
  2. Should this extend to Smart Proxy URLs too, or keep it focused on the Foreman server for now?
  3. How should certificate management work? Automatic SAN collection from configured subnets?
  4. Would anyone else benefit from this and be willing to test?

This is a real pain point for anyone managing hosts across multiple isolated VLANs. Having to deploy a full Smart Proxy in each network, when Foreman already has direct connectivity, adds unnecessary complexity and overhead.