Project

General

Profile

Bug #725

DHCP Relay missing logic for dynamic routes

Added by Jesse Peterson about 9 years ago. Updated over 8 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
DHCP Relay
Target version:
Start date:
07/08/2010
Due date:
% Done:

0%

Estimated time:
Affected Version:
All
Affected Architecture:

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.

Associated revisions

Revision 6f9b154b (diff)
Added by Ermal Luçi almost 9 years ago

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.

Revision 1e1dd1f5 (diff)
Added by Ermal Luçi almost 9 years ago

Ticket #725. Add checking the routing table as a last resort to find the correct interface before falling back to the default one.

History

#1 Updated by Jesse Peterson about 9 years ago

Forgot to add that this is 1.2.3-RELEASE on nanobsd platform.

#2 Updated by Chris Buechler about 9 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'];").

#3 Updated by Jesse Peterson about 9 years ago

I concur that your proposed solution would address the issue. Thanks!

#4 Updated by Jesse Peterson about 9 years ago

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.

#5 Updated by Ermal Luçi almost 9 years ago

  • Status changed from New to Feedback

#6 Updated by Chris Buechler almost 9 years ago

  • 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.

#7 Updated by Chris Buechler almost 9 years ago

  • Subject changed from DHCP Relay missing logic for static routes to DHCP Relay missing logic for dynamic routes

#8 Updated by Ermal Luçi almost 9 years ago

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.

#9 Updated by Chris Buechler almost 9 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.

#10 Updated by Ermal Luçi almost 9 years ago

  • Status changed from New to Feedback

Check out with latest snapshot.
We now check the routing table too.

#11 Updated by Chris Buechler over 8 years ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF