@jhumpf All I can say is that based on the two to three years of using that configuration for different fog admins, we haven’t needed to deviate from that configuration since dnsmasq is not giving out dhcp addresses the mask “should be” irrelevant. The remote subnets should just work as long as dnsmasq is being informed of them requesting a dhcp address.
If you want to debug deeper into the matter, I would suggest that you reset the configuration back to what I have in the article then follow this procedure to see if we can capture a bad remote proxydhcp request and then capture a good remote proxydhcp request so we can compare. There also may be some value in taking a computer on the remote “bad” subnet and loading wireshark on it. Start the capture filter of port “67 or port 68”. That would capture what the dhcp and dnsmasq are sending to the target computer, from the target computer’s point of view. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
Upload those 3 captures to a share file site and share them as public. Either DM me directly or post the links here and I will review them.
My gut feeling is that you have something not configured right in your infrastructure not related to FOG or dnsmasq.
