Re : Failed to open socket
I had exactly the same message cause i was running radiusd -X via putty on another computer and forgot it. (2.0.2-3). i stop it on putty, then restart radiusd -X on server and everything was ok. maybe you are in the same case. MBA OYONE Joël Lot. El Firdaous Bât GH20, Porte A 204, Appt 8 2 Oulfa Casablanca - Maroc Tél. : +212 69 25 85 70 - Message d'origine De : Alan DeKok <[EMAIL PROTECTED]> À : FreeRadius users mailing list Envoyé le : Lundi, 5 Mai 2008, 8h28mn 51s Objet : Re: Failed to open socket Lemaster, Rob wrote: > I recently upgraded to 2.0.4, and now I'm seeing the following error when I > start FreeRADIUS: ... > Sat May 3 20:21:39 2008 : Error: ERROR: Failed to open socket: > Sat May 3 20:21:39 2008 : Error: > /opt/freeradius-2.0.4/etc/raddb/radiusd.conf[210]: Error binding to port for > 0.0.0.0 port 1812 > Sun May 4 01:37:24 2008 : Info: Ready to process requests. So it *does* eventually start. Do you change the configuration between the start attempts? If not, then it's difficult to say why it starts one time, and then not another. Maybe it's port re-use timers? Or something like the FreeBSD Jail issue? Is there a ktrace functionality on your system to see which system calls it's doing, and what the results are? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html __ Do You Yahoo!? En finir avec le spam? Yahoo! Mail vous offre la meilleure protection possible contre les messages non sollicités http://mail.yahoo.fr Yahoo! Mail - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Failed to open socket
Lemaster, Rob wrote: > I recently upgraded to 2.0.4, and now I'm seeing the following error when I > start FreeRADIUS: ... > Sat May 3 20:21:39 2008 : Error: ERROR: Failed to open socket: > Sat May 3 20:21:39 2008 : Error: > /opt/freeradius-2.0.4/etc/raddb/radiusd.conf[210]: Error binding to port for > 0.0.0.0 port 1812 > Sun May 4 01:37:24 2008 : Info: Ready to process requests. So it *does* eventually start. Do you change the configuration between the start attempts? If not, then it's difficult to say why it starts one time, and then not another. Maybe it's port re-use timers? Or something like the FreeBSD Jail issue? Is there a ktrace functionality on your system to see which system calls it's doing, and what the results are? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FS trying to authenticate accounting data
Jim L. wrote: > Alan, > > The modifications to event.c now allow the server to correctly log to > the detail file. That portion appears to be fixed. However, it appears > that FS is still attempting to authenticate the accounting packet. Ok.. I've put the fix in CVS. I've been having a confused few days... Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Run as non-privileged user
Lemaster, Rob wrote: > Some documentation I've read recommends running FreeRADIUS as user=radius > group=radius. It said that you shouldn't use "nobody" because that is > reserved for a special purpose (I think it was the Hassel book). You should run it as radius/radius. The problem with using "nobody" is that all of the other un-privileged accounts will then be able to read the radius configuation. > Around line 116 of radiusd.conf, I found the option for "user/group", but the > instructions say that you must be root to start the server. If I change this > setting, will it prevent the server from starting? Start it as root, and it will switch to the user/group you supply. > What is the official recommended way of running FreeRADIUS as a non-root user? user/group = radius/radius start it as root. It will switch uid/gid. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Run as non-privileged user
FreeRADIUS 2.0.4 Some documentation I've read recommends running FreeRADIUS as user=radius group=radius. It said that you shouldn't use "nobody" because that is reserved for a special purpose (I think it was the Hassel book). Around line 116 of radiusd.conf, I found the option for "user/group", but the instructions say that you must be root to start the server. If I change this setting, will it prevent the server from starting? What is the official recommended way of running FreeRADIUS as a non-root user? Thanks for your time! - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Failed to open socket
I recently upgraded to 2.0.4, and now I'm seeing the following error when I start FreeRADIUS: radiusd -X: /opt/freeradius-2.0.4/etc/raddb/radiusd.conf[210]: Error binding to port for 0.0.0.0 port 1812 radius.log: Sat May 3 20:21:39 2008 : Error: ERROR: Failed to open socket: Sat May 3 20:21:39 2008 : Error: /opt/freeradius-2.0.4/etc/raddb/radiusd.conf[210]: Error binding to port for 0.0.0.0 port 1812 Sun May 4 01:37:24 2008 : Info: Ready to process requests. I tried hardcoding the IP & Port in radiusd.conf, but it didn't make any difference. I reviewed posts to this list and found others have seen similar errors, but their fixes didn't apply to my situation. Any suggestinons? Thanks! - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FS trying to authenticate accounting data
Alan,
The modifications to event.c now allow the server to correctly log to the
detail file. That portion appears to be fixed. However, it appears that FS
is still attempting to authenticate the accounting packet.
Sending proxied request internally to virtual server.
server ImagineNet_Detail {
+- entering group accounting
expand: /var/log/radius/radacct/imaginenet/detail-%Y%m%d ->
/var/log/radius/radacct/imaginenet/detail-20080504
rlm_detail: /var/log/radius/radacct/imaginenet/detail-%Y%m%d expands to
/var/log/radius/radacct/imaginenet/detail-20080504
expand: %t -> Sun May 4 16:25:23 2008
++[detail.imaginenet] returns ok
} # server ImagineNet_Detail
Going to the next request
<<< Received proxied response from internal virtual server.
Login incorrect (Home Server says so): [EMAIL PROTECTED]/User-Password attribute>] (from client fw1.cle1.oh.imaginenet.net port 0)
Sending Access-Reject of id 0 to 192.168.0.10 port 62518
Finished request 0.
Jim Lohiser
- Original Message -
From: "Alan DeKok" <[EMAIL PROTECTED]>
To: "FreeRadius users mailing list"
Sent: Saturday, May 03, 2008 3:45 AM
Subject: Re: FS trying to authenticate accounting data
Jim L. wrote:
I recompiled with this patch, however, I am getting the same results as
before.
Sorry...
DEBUG2(">>> Sending proxied request internally to virtual server.");
radius_handle_request(fake, rad_authenticate);
Change this line to:
radius_handle_request(fake, fun);
DEBUG2("<<< Received proxied response from internal virtual server.");
It was a typo in the original patch.
Alan DeKok.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Weird shared secret issues
Hi Ivan, Really, I appreciate the information. I'm sure between the suggestions given I could do it. However, if it is more than a command line or script on the radius server itself, its too involved for the person I have to turn it over to. I just saw that radtest took nasname as an option and thought it would have a bearing on the secret. Not the case, so I know better. :) Thanks, Tuc > > If you have a spare box on a local network, switch that supports VLANs > and a router that can tag VLANs - you can spoof the whole outside > network with simple IP/VLAN configuration: > > configure a gateway IP interface for the network you want to spoof on > your router and tag it with testing VLAN ID - that will create a locally > connected routing table entry - no creative manual entries needed > > configure testing VLAN ID on the switchport to which you will connect the > testing box > > configure IP you want to spoof on the testing box > > That shouldn't take more than 5 minutes. Just make sure that you remove > the spoofed gateway interface from the router after testing in order to > be able to use the real network. > > Ivan Kalik > Kalik Informatika ISP > > > Dana 4/5/2008, "Tuc at T-B-O-H.NET" <[EMAIL PROTECTED]> pi?e: > > >> > >> Hi, > >> > >> > Tech calls in and say that he can't get an appliance working in the > >> > field. > >> > I ask him what secret he's using and the IP address of the appliance. I > >> > want to > >> > be able to be locally logged onto the radius server and use > >> > radtest/radclient/rad > >> > to be able to query radius asking "If I was IP, and I gave you SECRET, > >> > would you > >> > authorize me?". > >> > > >> > So I want to be on 1.2.3.4, but say I'm on 3.4.5.6 . Right now, If I > >> > say I'm on 3.4.5.6, it still wants the secret for 1.2.3.4 . > >> > >> you want to spoof the source address? tricky. one 'easy' way to do this > >> would > >> be to create a local VPN/GRE tunnel on the linux box under which you could > >> emulate a remote link. > >> > >> configure freeradius to also listen on that virtual address, run the > >> radclient with the destination being the end point of the VPN - the > >> linux routing tables would then come into play. you'd have to > >> reconfigure the VPN end addresses etc each time to emulate an > >> outside world link...but it would work. > >> > > Not worth it. All I'm looking to do is get programatic confirmation > >that the ip/secret combination in the field is correct. Since this is an > >appliance, not an OS, I don't have access to radtest on the appliance. To > >have someone start setting up VPN/GRE/etc is more hassle than its worth. > >I just have to tell the tech to RTFD closer. I was just hoping I could > >put together a local form on a webserver that could shell out to a script > >to make the test. > > > > We'll just have to suffer. :) (Or ask the manufacturer to include > >a utility in the "diagnostic" section) > > > > Thanks, Tuc > >- > >List info/subscribe/unsubscribe? See > >http://www.freeradius.org/list/users.html > > > > > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Weird shared secret issues
If you have a spare box on a local network, switch that supports VLANs and a router that can tag VLANs - you can spoof the whole outside network with simple IP/VLAN configuration: configure a gateway IP interface for the network you want to spoof on your router and tag it with testing VLAN ID - that will create a locally connected routing table entry - no creative manual entries needed configure testing VLAN ID on the switchport to which you will connect the testing box configure IP you want to spoof on the testing box That shouldn't take more than 5 minutes. Just make sure that you remove the spoofed gateway interface from the router after testing in order to be able to use the real network. Ivan Kalik Kalik Informatika ISP Dana 4/5/2008, "Tuc at T-B-O-H.NET" <[EMAIL PROTECTED]> piše: >> >> Hi, >> >> >Tech calls in and say that he can't get an appliance working in the >> > field. >> > I ask him what secret he's using and the IP address of the appliance. I >> > want to >> > be able to be locally logged onto the radius server and use >> > radtest/radclient/rad >> > to be able to query radius asking "If I was IP, and I gave you SECRET, >> > would you >> > authorize me?". >> > >> >So I want to be on 1.2.3.4, but say I'm on 3.4.5.6 . Right now, If I >> > say I'm on 3.4.5.6, it still wants the secret for 1.2.3.4 . >> >> you want to spoof the source address? tricky. one 'easy' way to do this >> would >> be to create a local VPN/GRE tunnel on the linux box under which you could >> emulate a remote link. >> >> configure freeradius to also listen on that virtual address, run the >> radclient with the destination being the end point of the VPN - the >> linux routing tables would then come into play. you'd have to >> reconfigure the VPN end addresses etc each time to emulate an >> outside world link...but it would work. >> > Not worth it. All I'm looking to do is get programatic confirmation >that the ip/secret combination in the field is correct. Since this is an >appliance, not an OS, I don't have access to radtest on the appliance. To >have someone start setting up VPN/GRE/etc is more hassle than its worth. >I just have to tell the tech to RTFD closer. I was just hoping I could >put together a local form on a webserver that could shell out to a script >to make the test. > > We'll just have to suffer. :) (Or ask the manufacturer to include >a utility in the "diagnostic" section) > > Thanks, Tuc >- >List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Weird shared secret issues
> > Hi, > > > Tech calls in and say that he can't get an appliance working in the > > field. > > I ask him what secret he's using and the IP address of the appliance. I > > want to > > be able to be locally logged onto the radius server and use > > radtest/radclient/rad > > to be able to query radius asking "If I was IP, and I gave you SECRET, > > would you > > authorize me?". > > > > So I want to be on 1.2.3.4, but say I'm on 3.4.5.6 . Right now, If I > > say I'm on 3.4.5.6, it still wants the secret for 1.2.3.4 . > > you want to spoof the source address? tricky. one 'easy' way to do this would > be to create a local VPN/GRE tunnel on the linux box under which you could > emulate a remote link. > > configure freeradius to also listen on that virtual address, run the > radclient with the destination being the end point of the VPN - the > linux routing tables would then come into play. you'd have to > reconfigure the VPN end addresses etc each time to emulate an > outside world link...but it would work. > Not worth it. All I'm looking to do is get programatic confirmation that the ip/secret combination in the field is correct. Since this is an appliance, not an OS, I don't have access to radtest on the appliance. To have someone start setting up VPN/GRE/etc is more hassle than its worth. I just have to tell the tech to RTFD closer. I was just hoping I could put together a local form on a webserver that could shell out to a script to make the test. We'll just have to suffer. :) (Or ask the manufacturer to include a utility in the "diagnostic" section) Thanks, Tuc - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Weird shared secret issues
Hi, > Tech calls in and say that he can't get an appliance working in the > field. > I ask him what secret he's using and the IP address of the appliance. I want > to > be able to be locally logged onto the radius server and use > radtest/radclient/rad > to be able to query radius asking "If I was IP, and I gave you SECRET, would > you > authorize me?". > > So I want to be on 1.2.3.4, but say I'm on 3.4.5.6 . Right now, If I > say I'm on 3.4.5.6, it still wants the secret for 1.2.3.4 . you want to spoof the source address? tricky. one 'easy' way to do this would be to create a local VPN/GRE tunnel on the linux box under which you could emulate a remote link. configure freeradius to also listen on that virtual address, run the radclient with the destination being the end point of the VPN - the linux routing tables would then come into play. you'd have to reconfigure the VPN end addresses etc each time to emulate an outside world link...but it would work. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Weird shared secret issues
> > Hi, > > > It still leaves one item open. I can't seem to get radclient to > > be able to take the NAS-IP-Address and then the secret for that > > NAS-IP-Address. > > It seems no matter what, it wants to use the secret for the localhost. Is > > this how its supposed to work, or is there a bug somewhere? > > man radclient > > Packet-Dst-IP-Address - if this attribute is present in the request then > the packet will be sent to that address. ie it wont go to 127.0.0.1 > if you specify the real IP of the server. alternately, use the IP address > of the server and not its canonical 'localhost' which will always be 127.0.0.1 > unless you've played with the systems IP stack. > > alan > I guess I'm not clear in what I was attempting to accomplish, maybe subsequently I went about it the wrong way. Tech calls in and say that he can't get an appliance working in the field. I ask him what secret he's using and the IP address of the appliance. I want to be able to be locally logged onto the radius server and use radtest/radclient/rad to be able to query radius asking "If I was IP, and I gave you SECRET, would you authorize me?". So I want to be on 1.2.3.4, but say I'm on 3.4.5.6 . Right now, If I say I'm on 3.4.5.6, it still wants the secret for 1.2.3.4 . Thanks, Tuc - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Weird shared secret issues
Hi, > It still leaves one item open. I can't seem to get radclient to > be able to take the NAS-IP-Address and then the secret for that > NAS-IP-Address. > It seems no matter what, it wants to use the secret for the localhost. Is > this how its supposed to work, or is there a bug somewhere? man radclient Packet-Dst-IP-Address - if this attribute is present in the request then the packet will be sent to that address. ie it wont go to 127.0.0.1 if you specify the real IP of the server. alternately, use the IP address of the server and not its canonical 'localhost' which will always be 127.0.0.1 unless you've played with the systems IP stack. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Weird shared secret issues
> > hi, > > are you sure that there isnt a legacy secret entry in clients.conf > file? > Nope... [EMAIL PROTECTED] sbin]# more /usr/local/etc/raddb/clients.conf #** #** #** #** #** #** # THIS FILE IS NO LONGER USED. UPDATE ALL NAS IN NOC #** #** #** #** #** #** [EMAIL PROTECTED] sbin]# I did find the problem (Error between eyes and brain of the tech installing the units. Put the secret as the community and visa versa.) that caused me to look into using radtest... It still leaves one item open. I can't seem to get radclient to be able to take the NAS-IP-Address and then the secret for that NAS-IP-Address. It seems no matter what, it wants to use the secret for the localhost. Is this how its supposed to work, or is there a bug somewhere? Thanks, Tuc - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Strategy Advice
Hi, > Don't know if this is an issue for you, but: Cisco equipment does not > support command authorization via RADIUS (*any* RADIUS...) [for pure > business greed reasons]. So if you really need per-command > authorization, you'll have to stick with TACACS+ which, sadly, is well > catered by ACS. you can still ditch the ACS and use tac_plus daemon on the same box that freeradius is running on.. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Weird shared secret issues
hi, are you sure that there isnt a legacy secret entry in clients.conf file? alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FR failing
Hi, > We have two FR servers (running 1.1.15) on Red Hat machines. 1.1.5 ? upgrade to 1.1.7 to fix lots of known bugs/issues alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: freeradius 2.0.4 and peap
Hi, > Ivan Kalik escribió: >> You have experlty deleted all the relevant information from the debug and >> your configuration. Post the complete debug. >> > I solved the problem commenting the line >virtual_server = "inner-tunnel" > in the peap section of eap.conf which means you are not using the inner-tunnel virtual server - which is the best way of doing things. ensure that the inner-tunnel config is in $raddb/sites-enabled directory so that the server can use it...and then USE it alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
