FreeRADIUS sends proxy packets out the proper interface, but with the wrong source IP (simple udpfromto problem?)
Quick summary: I have RADIUS servers that are performing authentication and accounting for various NAS devices. I recently set up a new accounting proxy, to put a copy of my accounting files on remote hosts via a private network. I've created an additional detail writer, and created a reader. With radclient, this works. With radiusd, it does not. Problem: The detail reader, when sending the accounting packets, sends them out the *correct* interface, but with the *wrong* source IP address. (It will send out eth2, but have the source IP of eth0.) I proxy to other hosts as well, so I cannot simply force a single proxy ip address, since that will break other things. (As far as I can tell.) All my routing is good, no firewalls are in the way, etc. When I send a packet from the RADIUS servers to the new proxy hosts via radclient, it works perfectly. When radiusd tries, it doesn't work (and the new proxies show up as zombies, and then dead.) I've dug through the mailing list, the release notes, and dug through bugzilla, and about the closest thing I found was this bug: https://bugs.freeradius.org/bugzilla/show_bug.cgi?id=38 The mailing list shows some results, but not quite what I'm looking for. Is my problem a simple lack of 'udpfromto'? My RADIUS servers bind on specific IP addresses, and not '*', so they aren't listening on INADDR_ANY. Attempting to get the server reading the detail files to also bind to an IP address and port doesn't fix it, nor does configuring the server to have an interface in addition to an ipaddr. Creating a 'middleman' - a local proxy, listening on the private IP address, which then proxies to the final accounting servers - doesn't work either. (I had hoped that if it were receiving packets on an interface, that it would know where they were accepted, and then proxy out that same interface, with the same source IP.) The 'fix' I found was a mixture of arptables and iptables. It works but I'm not happy with having to mangle any proxied packets. I'm on freeRADIUS 2.1.10, and I know there's a newer version. Should I simply build a new version, and make sure that I change my spec file to include '--with-udpfromto' (in the current one doesn't?) -- Adam
Adam Bultman wrote:
Problem: The detail reader, when sending the accounting packets, sends them out the *correct* interface, but with the *wrong* source IP address. (It will send out eth2, but have the source IP of eth0.)
You're running Linux, right? And both interfaces are on the same network? It's a Linux bug. The Linux people think it isn't a bug, so it hasn't been fixed for 10+ years. As a hint, FreeRADIUS uses the standard socket calls to send/recv packets. There's no magic "send packets out the wrong interface" code in it. All of the routing is handled by the kernel. So... blame the kernel for routng problems.
I proxy to other hosts as well, so I cannot simply force a single proxy ip address, since that will break other things. (As far as I can tell.) All my routing is good, no firewalls are in the way, etc.
You can set "src_ipaddr" for each home server. See raddb/proxy.conf. This is documented.
The mailing list shows some results, but not quite what I'm looking for. Is my problem a simple lack of 'udpfromto'?
No. Alan DeKok.
On 10/18/2011 10:02 PM, Alan DeKok wrote:
Adam Bultman wrote:
Problem: The detail reader, when sending the accounting packets, sends them out the *correct* interface, but with the *wrong* source IP address. (It will send out eth2, but have the source IP of eth0.)
You're running Linux, right? And both interfaces are on the same network?
It's a Linux bug. The Linux people think it isn't a bug, so it hasn't been fixed for 10+ years.
Yeah, I'm running linux, but all my networks are on distinct interfaces, and none are duplicated. eth0 = 10.x.x.x, eth1 = public IP, eth2 = 192.168.x.x .
As a hint, FreeRADIUS uses the standard socket calls to send/recv packets. There's no magic "send packets out the wrong interface" code in it. All of the routing is handled by the kernel. So... blame the kernel for routng problems.
I did just about everything I could think of to make sure that any packets had the correct source IP via routing - 'ip route 192.168.x.x/24 via 192.168.x.1 dev eth2 src 192.168.x.155', but it made no difference. I didn't think there was any specific code to send things out the wrong interface, but I did wonder perhaps there was something like 'whatever IP I'm told to listen on first, that will be my source IP' type thing.
I proxy to other hosts as well, so I cannot simply force a single proxy ip address, since that will break other things. (As far as I can tell.) All my routing is good, no firewalls are in the way, etc.
You can set "src_ipaddr" for each home server. See raddb/proxy.conf. This is documented.
This isn't in the copy of the proxy.conf file on my RADIUS servers, which explains why I've had trouble at all. If my version (2.1.10) doesn't support src_ipaddr, then I'll upgrade. Thanks for your help, Alan. It is much appreciated. -- Adam
Adam Bultman wrote:
Yeah, I'm running linux, but all my networks are on distinct interfaces, and none are duplicated. eth0 = 10.x.x.x, eth1 = public IP, eth2 = 192.168.x.x .
Well... then it's still a Linux problem. The server doesn't choose the source IP of proxied packets. It lets the kernel take care of that.
You can set "src_ipaddr" for each home server. See raddb/proxy.conf. This is documented.
This isn't in the copy of the proxy.conf file on my RADIUS servers,
You've upgraded from an earlier version of the server which didn't support it.
which explains why I've had trouble at all. If my version (2.1.10) doesn't support src_ipaddr, then I'll upgrade.
See raddb/proxy.conf in the 2.1.10 distribution. Though you should probably upgrade to 2.1.12, too... Alan DeKok.
participants (2)
-
Adam Bultman -
Alan DeKok