pfSense

Why would you need to relay to a server in the same subnet as the clients it serves and the firewall? They can get a reply from it directly.

Using -i could re-introduce problems like #9466 and some others which were also solved by that change.

Alternately, we could add separate boxes for interfaces selection to pick upstream and downstream interfaces, defaulting to the current automatic behavior.

Either way, changes must be submitted as pull requests on Github: https://docs.netgate.com/pfsense/en/latest/development/submitting-a-pull-request-via-github.html

Jim Pingle wrote:

Why would you need to relay to a server in the same subnet as the clients it serves and the firewall? They can get a reply from it directly.

Yes, from the in-subnet server you can, of course. However, the FO peer (in another subset), will never see the DHCPDISCOVER packet. For ISC DHCP failover (see https://tools.ietf.org/html/draft-ietf-dhc-failover-12), both servers need to the see the discover packet, then they both hash the client-ID to compute which one responds. The “losing” peer won’t respond. So, the current behavior, since it doesn’t relay in that scenario, breaks DHCP FO.

Using -i could re-introduce problems like #9466 and some others which were also solved by that change.

Agreed, which is why the change wasn’t just reinstating the “-i” behavior across the board, but only for interfaces that had overlapping behavior, hopefully to help mitigate.

Alternately, we could add separate boxes for interfaces selection to pick upstream and downstream interfaces, defaulting to the current automatic behavior.

That still wouldn’t fix the behavior, unfortunately, as a “global” setup. The really “right” answer, which is beyond my coding ability, is the option for separate instances of dhcrelay for each interface, such that, for this situation, you would only specify the one off-network server for relay, but specify different server lists for other networks. This would actually be a feature enhancement, of course, but a welcome one. That could also be problematic, though, as you’d most likely need multiple dhcrelay instances binding to the same interface/port.

Either way, changes must be submitted as pull requests on Github: https://docs.netgate.com/pfsense/en/latest/development/submitting-a-pull-request-via-github.html

The patch was just me trying to be overly helpful, as I had to get this to work anyway. Apologies for breaking protocol.

John Steele wrote:

Jim Pingle wrote:

Why would you need to relay to a server in the same subnet as the clients it serves and the firewall? They can get a reply from it directly.

Yes, from the in-subnet server you can, of course. However, the FO peer (in another subset), will never see the DHCPDISCOVER packet. For ISC DHCP failover (see https://tools.ietf.org/html/draft-ietf-dhc-failover-12), both servers need to the see the discover packet, then they both hash the client-ID to compute which one responds. The “losing” peer won’t respond. So, the current behavior, since it doesn’t relay in that scenario, breaks DHCP FO.

I thought of that after but not using DHCP Relay much I wasn't sure if that was really viable or allowed. It seems like a strange design choice but if that's how it works, so be it.

Using -i could re-introduce problems like #9466 and some others which were also solved by that change.

Agreed, which is why the change wasn’t just reinstating the “-i” behavior across the board, but only for interfaces that had overlapping behavior, hopefully to help mitigate.

I get that but there are multiple issues we've had in the past reported with -i on its own, so I think no matter how we try to guess automatically, it's going to be problematic for the user.

Alternately, we could add separate boxes for interfaces selection to pick upstream and downstream interfaces, defaulting to the current automatic behavior.

That still wouldn’t fix the behavior, unfortunately, as a “global” setup.

Having separate choices for upstream and downstream would give the user manual control over which one is used for each role and if an interface is chosen for both roles, then -i could be used instead of the more specific option. It lets the user determine what happens rather than making the backend code guess which is what it does now (and what your patch also does, but with -i).

The really “right” answer, which is beyond my coding ability, is the option for separate instances of dhcrelay for each interface, such that, for this situation, you would only specify the one off-network server for relay, but specify different server lists for other networks. This would actually be a feature enhancement, of course, but a welcome one. That could also be problematic, though, as you’d most likely need multiple dhcrelay instances binding to the same interface/port.

IMO, the best possible answer is to run IP Helper/DHCP Relay on the L2 -- switches, AP, etc, not the firewall/router. But not everyone has that choice.

Jim Pingle wrote:

Having separate choices for upstream and downstream would give the user manual control over which one is used for each role and if an interface is chosen for both roles, then -i could be used instead of the more specific option. It lets the user determine what happens rather than making the backend code guess which is what it does now (and what your patch also does, but with -i).

That would actually be pretty cool. Like you said, my patch does that, just keeping in line w/ the "guessing" concept, computing the "right" option. Whether it's manual (as you defined), or automatic (ref my patch), it's the behavior that's important. No ego on the patch (again, was just my fix to get my network back up), just need the -i behavior potential.

IMO, the best possible answer is to run IP Helper/DHCP Relay on the L2 -- switches, AP, etc, not the firewall/router. But not everyone has that choice.

I completely agree, when it's doable, but like you said, it isn't always, especially on smaller sites, which is what burned me, actually.