The macvlan + bridge detour

The print server, the RODC, and the device sidecars each get their own LAN IP via macvlan, and they also attach the samba bridge with a single /32 route back to the DC. That dual-homing looks redundant until you hit the problem it solves.

Why macvlan at all

A real Windows client should mount \\print1 on native port 445, with no NAT, exactly as it would mount a physical print server. Macvlan gives the container its own MAC and IP directly on the LAN, so to every other machine on the subnet it is a separate host. No port mapping, no rewriting, no surprises in the referrals. That realism is the whole reason these services exist.

The problem macvlan creates

Macvlan has one sharp edge: a macvlan child cannot address its own parent host’s IP. The kernel short-circuits that path. And in this lab the parent host is the machine running the host-networked DC. So the print server, sitting on macvlan, cannot reach dc1 over the LAN, because dc1 is the parent.

That is fatal on its own: a member server that cannot reach the DC cannot join the domain, cannot get Kerberos tickets, cannot authenticate anything.

The detour

So each macvlan service also attaches the shared samba bridge and pins a host route: traffic to the DC’s IP specifically (a /32) goes over the bridge, while everything else (Windows clients, the LAN gateway) rides the macvlan side. The entrypoint sets this up automatically on startup.

flowchart LR
  svc["print1 / rodc1 / sidecar<br/>(macvlan child)"]
  client["LAN clients + gateway"]
  dc["dc1<br/>(macvlan parent = host)"]
  svc -->|"everything else,<br/>via macvlan (own LAN IP, native 445)"| client
  svc -. "traffic to dc1 only:<br/>/32 route over 'samba' bridge" .-> dc
  svc -x|"direct macvlan to parent<br/>(blocked by kernel)"| dc

The result: clients see a clean LAN peer, and the service can still reach the DC to join and authenticate. Two paths, each used for what it is good at.

The knock-on effects

This detour ripples into a couple of other design choices you will see referenced elsewhere:

• Publishing printers does not use net ads printer publish, because that tool RPC-connects to the print server by name to read spooler data, which triggers the macvlan self-hairpin and hangs. The lab writes the printQueue object straight to the DC over LDAP instead. See Run and publish the print server.
• GSSAPI over the detour needs udp_preference_limit = 1 in krb5.conf: the UDP Kerberos reply gets dropped on the bridge detour, but TCP gets through.
• Validation from the host fails for the sidecars: the host-networked DC is the macvlan parent, so it cannot reach the macvlan children. The make validation targets exec into the sidecars instead.

The takeaway

Macvlan buys realism (real LAN identities) at the cost of one limitation (no parent self-addressing). The /32 bridge detour pays that cost precisely, for just the one destination that needs it, leaving the realistic path intact for everyone else.