Freeradius, bind addresses, and multihoming
I've compiled freeradius with the --with-udpfromto directive. Everything works as expected when I bind to all IPs: listen { ipaddr = * port = 1812 type = auth } listen { ipaddr = * port = 1813 type = acct } However, if I specify multiple IPs to bind to (rather than just one or all), it reverts to the the behaviour of responding to all requests with a source IP of the first bind directive listed. For example: listen { ipaddr = 192.168.1.250 port = 1812 type = auth } listen { ipaddr = 192.168.1.250 port = 1813 type = acct } listen { ipaddr = 1.2.3.4 port = 1812 type = auth } listen { ipaddr = 1.2.3.4 port = 1813 type = acct } In this configuration, freeradius will always respond from 192.168.1.250, even if the initial request was sent to 1.2.3.4. This is obviously breaking things for me, as I'd rather not have freeradius listen on every interface on the server (and there are a number of them). Am I doing something wrong? Am I expecting the wrong behaviour? Or is this a bug? GG
Dear All why radius is not bind auto MAC from user in first time use?like mikrotik user manager have this option... is there any way? Thanks in Advance On Tue, May 3, 2011 at 3:20 AM, Gary T. Giesen <giesen@snickers.org> wrote:
I've compiled freeradius with the --with-udpfromto directive. Everything works as expected when I bind to all IPs:
listen { ipaddr = * port = 1812 type = auth }
listen { ipaddr = * port = 1813 type = acct }
However, if I specify multiple IPs to bind to (rather than just one or all), it reverts to the the behaviour of responding to all requests with a source IP of the first bind directive listed. For example:
listen { ipaddr = 192.168.1.250 port = 1812 type = auth }
listen { ipaddr = 192.168.1.250 port = 1813 type = acct }
listen { ipaddr = 1.2.3.4 port = 1812 type = auth }
listen { ipaddr = 1.2.3.4 port = 1813 type = acct }
In this configuration, freeradius will always respond from 192.168.1.250, even if the initial request was sent to 1.2.3.4. This is obviously breaking things for me, as I'd rather not have freeradius listen on every interface on the server (and there are a number of them). Am I doing something wrong? Am I expecting the wrong behaviour? Or is this a bug?
GG - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- -- Syed Tanjil Ahmed Chairman Netgate Online Ltd Oval Communication Ltd. SNS CNG & Convertion Ltd Network Solution Ltd. ARSHI (Non Government Organizations) 20,Siddeswari Lane,1st Floor,Dhaka 483/a,DIT Road,Dhaka-1217 Ph:8333315,9352029,9350458 Ph:9361083,9346890,9342514 Email:info@tanjil.net,tanjil@email.com
Tanjil Ahmed <tanjil@tanjil.net> wrote:
why radius is not bind auto MAC from user in first time use?like mikrotik user manager have this option...
...dear user, why do people keep hijacking mailing list threads and use the *Reply-To* button rather than *Compose* in their email clients?
is there any way?
Indeed. Regards -- Alexander Clouter .sigmonster says: Talk is cheap because supply always exceeds demand.
Gary T. Giesen wrote:
I've compiled freeradius with the --with-udpfromto directive. ... However, if I specify multiple IPs to bind to (rather than just one or all), it reverts to the the behaviour of responding to all requests with a source IP of the first bind directive listed. For example:
That's weird. Please try the v2.1.x branch from http://git.freeradius.org. It has some fixes to the udpfromto code which should help. Alan DeKok.
Built latest git and still the exact same results. GG On Tue, May 3, 2011 at 8:23 AM, Alan DeKok <aland@deployingradius.com> wrote:
Gary T. Giesen wrote:
I've compiled freeradius with the --with-udpfromto directive. ... However, if I specify multiple IPs to bind to (rather than just one or all), it reverts to the the behaviour of responding to all requests with a source IP of the first bind directive listed. For example:
That's weird. Please try the v2.1.x branch from http://git.freeradius.org. It has some fixes to the udpfromto code which should help.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
My apologies, it does seem to be working correctly now... I found part of the problem was that I hadn't specified a source IP address for proxying, but direct clients were broken as well too so I'm going to drop back to the old version and see if I still have the same problem GG On Tue, May 3, 2011 at 3:01 PM, Gary T. Giesen <giesen@snickers.org> wrote:
Built latest git and still the exact same results.
GG
On Tue, May 3, 2011 at 8:23 AM, Alan DeKok <aland@deployingradius.com> wrote:
Gary T. Giesen wrote:
I've compiled freeradius with the --with-udpfromto directive. ... However, if I specify multiple IPs to bind to (rather than just one or all), it reverts to the the behaviour of responding to all requests with a source IP of the first bind directive listed. For example:
That's weird. Please try the v2.1.x branch from http://git.freeradius.org. It has some fixes to the udpfromto code which should help.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Gary T. Giesen <giesen@snickers.org> wrote:
In this configuration, freeradius will always respond from 192.168.1.250, even if the initial request was sent to 1.2.3.4. This is obviously breaking things for me, as I'd rather not have freeradius listen on every interface on the server (and there are a number of them).
Am I doing something wrong? Am I expecting the wrong behaviour? Or is this a bug?
What's the: * OS * output of 'ip route' and 'ip route get <src-ip-of-request>' If you are multihomed (can get to the same IP via more than one interface/gateway) then it should work. If you have miconfigured the server so that it does not how to route to src-ip-of-request via the interface it saw the packet come in on, then you will have a problem (although I would have expected no reply at all). Cheers -- Alexander Clouter .sigmonster says: Vax Vobiscum
participants (4)
-
Alan DeKok -
Alexander Clouter -
Gary T. Giesen -
Tanjil Ahmed