Bug #725
closed
DHCP Relay missing logic for dynamic routes
Added by Jesse Peterson over 14 years ago.
Updated almost 14 years ago.
Description
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.
Forgot to add that this is 1.2.3-RELEASE on nanobsd platform.
- 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'];").
I concur that your proposed solution would address the issue. Thanks!
Arg.. just when I hit send I think of it...
I assume that when you say "reachable via any static route" you mean any subnet in the route table? Routes learned via routing protocols (RIP, etc.) would ideally get searched, too.
- Status changed from New to Feedback
- Status changed from Feedback to New
this doesn't take dynamic routing into account, it probably should just use a routing table lookup to determine the interface.
- Subject changed from DHCP Relay missing logic for static routes to DHCP Relay missing logic for dynamic routes
The problem is that in pfSense currently there is no even generated on changed routes.
So if the underlying route changes dhcrelay will never get restarted!
If that is not an issue just doing a route lookup is feasible.
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.
- Status changed from New to Feedback
Check out with latest snapshot.
We now check the routing table too.
- Status changed from Feedback to Resolved
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by Ermal Luçi