Raimund Sacherer wrote: > Here is a more detailed description of our scenario
[...] Thanks, it's a lot easier to undestand now. > For a Proxy Packet the Packet->src_ipaddr is empty. It's the normal behaviour. The RADIUS server doesn't have knowledge about the network routes so it's the kernel who chooses the source address of the outgoing packet. > In your scenario you are direct connected to the networks where > your proxyserver resides so you don't need to use a default gateway > to reach your servers. Indeed our previous scenario is different, but at least it shows that the udpfromto patch doesn't break the proxy functionality when the realm servers are connected on different network interfaces. > My previously posted patch adds configuration items for the proxy.conf > config file where you can define the ip_addr which should be used for > each Realm. > > I would be glad if someone can confirm this as problem and my patch as > the right solution ;-) It's just my opinion, but I'm not confident about putting elements related to the external network environnement inside the RADIUS server. But if you or the other people of the list can provide reasons it shoud be handled by radiusd, I'm interested to hear about it. > +--------------+ > +---+ | NAS/Roaming | (NAS/Roaming Partner may not be > | 1 | | RadiusServer | part of our Network and can have their > +---+ +--------------+ own Public/Private IP Networks) > | > | > | > +--------------+ > | Our | > +-------->-------| FireWall/ | > | | IPSEC | > | | Tunnel | > | | Endpoint | > | +--------------+ > | | > | +---+ | > | | 2 | +----+----+ > | +---+ | | > | Clients which Clients with > | comes from "direct" > | IPSec Tunnels Internet Access > | | | > | | | > | eth0:1 eth0 > | 10.0.0.10 62.62.62.62 > | | | > | +--------------+ > | | Our |-eth1-<->-[internal AdminLan] > | | RadiusServer | > | +--------------+ > | | | > | +---+ eth0:1 eth0 > | | 3 | 10.0.0.10 62.62.62.62 > | +---+ | | > +-------<----------+---<-----+ Now you gave us all the details about the problem in your setup, I'm thinking of a different approach: perhaps it could be easier to add a source NAT rule on the firewall rather than hacking the source IP inside radiusd. Did you try this ? Regards -- Nicolas Baradakis - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
