Source IP address for proxy requests

[Alan DeKok]

Phil Mayers <p.mayers at imperial.ac.uk> wrote:
> All IP protocol servers should offer each type of socket a configurable 
> bind address (or list of such). That is quite aside from the specifics 
> of this issue - that is, it solves other, much much harder to solve 
> problems than just this issue, and is required for absolutely 
> deterministic behaviour.

  Yes.  For 2.0, I wouild like to have a configurable "proxy" section.
The difficulty is that it should really be configurable
per-home-server.  That's a fair amount of work.

> There are legitimate reasons to want to bind to a *specific* IP for 
> sockets sinking and sourcing datagrams (and in fact for stream 
> protocols, though these tend to be less of an issue). Bind, a venerable 
> (if crufty) and EXTREMELY widely deployed datagram protocol 
> client/server, has found this out repeatedly (see transfer-source, 
> query-source, notify-source - those options weren't added for giggles).

  Yes, I've worked with Bind, and done exactly that.  The difference
with RADIUS is that there have been relatively few complaints about
the current behavior, which means it's a low priority to change it.

  And changing it means most likely that people will configure
proxying on IP X to home server at IP Y... which is not routable from
X.  The kernel UDP socket code will ensure that no error is returned
to the server, meaning that it's impossible to figure out what's going
wrong.

  I really would prefer to have the proxy sockets bind to "*", and to
have the kernel do the right thing for sending packets.  I'd like to
see compelling reasons why this behavior needs to be change before
updating the code.  (See the comment about about there being few
complaints...)

> I'm currently running into a problem with ISC dhcpd related to it's 
> failure to offer IP-specific bind options and offering service to 
> overlapping address space on a single server, which is impossible for 
> the want of this micro-option.

  That's come up on the ISC list.  The answer is to create multiple
interfaces, set up routing, and to have multiple servers listening,
each on one interface.

  There has to be a better way...

  But for dhcpd, the issue isn't the packets it's originating, but
which IP's it's listening on.  FreeRADIUS already supports listening
on multiple IP's, so it's already a step ahead of DHCPD.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog