DHCP Relay missing logic for dynamic routes
In my environment the DHCP relay server is across another router on the LAN interface, and I'm relaying through the OPT1 interface. Because the IP address is not directly routable no interface is found in /etc/inc/services.inc:409 (in services_dhcrelay_configure()) and thus it simply "picks" the WAN interface. However, in my static routes that IP is addressable and it is routed through a router on the LAN interface. Thus the WAN DHCP relay is erroneous and a possible security risk. While I suppose I could firewall DHCP on the WAN interface I think pfSense should at least have the option to not guess or fallback on the WAN interface.
Ticket #725. Before falling back to the default gw interface search even static routes. Also catch up with routing code on how to find the default gw.
#2 Updated by Chris Buechler almost 10 years ago
- Subject changed from DHCP Relay "guessing" the WAN interface to DHCP Relay missing logic for static routes
- Category set to DHCP Relay
- Target version set to 2.0
- Affected Version set to All
The problem is it's missing checks for static routes, so it picks the wrong interface. This issue exists in m0n0wall as well. Having it fall back to WAN is actually needed for it to function properly for usage cases where the DHCP server is reachable via WAN, but it shouldn't get to that point if the DHCP server is reachable via an internal interface on a static route. That would completely resolve it for m0n0wall, and our most common usage where the default gateway resides on WAN. Since the default gateway can reside anywhere now that complicates things.
The logic should be: if the server is not on a locally attached subnet, and not reachable via any static route, then use the interface where the default gateway resides (rather than "$destif = $config['interfaces']['wan']['if'];").
#9 Updated by Chris Buechler almost 10 years ago
Yeah that's a problem we can't easily accommodate right now, the solution for the time being is to just do a routing table lookup when it starts, and if the routes change to a different interface, well that's just something we can't accommodate right now. That's a rare scenario.