Project

General

Profile

Actions

Bug #725

closed

DHCP Relay missing logic for dynamic routes

Added by Jesse Peterson over 14 years ago. Updated almost 14 years ago.

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

0%

Estimated time:
Plus Target Version:
Release Notes:
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.

Actions #1

Updated by Jesse Peterson over 14 years ago

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

Actions #2

Updated by Chris Buechler over 14 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'];").

Actions #3

Updated by Jesse Peterson over 14 years ago

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

Actions #4

Updated by Jesse Peterson over 14 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.

Actions #5

Updated by Ermal Luçi over 14 years ago

  • Status changed from New to Feedback
Actions #6

Updated by Chris Buechler over 14 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.

Actions #7

Updated by Chris Buechler over 14 years ago

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

Updated by Ermal Luçi over 14 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.

Actions #9

Updated by Chris Buechler over 14 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.

Actions #10

Updated by Ermal Luçi over 14 years ago

  • Status changed from New to Feedback

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

Actions #11

Updated by Chris Buechler almost 14 years ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF