I'm just asking this for my understanding, am I still going to want
to use Client-IP-Address even though from what I can see here, the
NAS-IP-
Address attribute is appearing within the output of debugging?
I would suggest using Client-IP-Address, unless you know that the
NAS will always
Jonathan De Graeve wrote:
How do you explain this then?
I have a NAS that DOESN'T sent NAS-IP-Address attribute to the radius
server (only nas-identifier) but all my huntgroups based on
NAS-IP-Address work without any problem...
Is this then somewhere in the code?
If (!NAS-IP-Address
Curt LeCaptain [EMAIL PROTECTED] wrote:
I'm just asking this for my understanding, am I still going to want to use
Client-IP-Address even though from what I can see here, the NAS-IP-Address
attribute is appearing within the output of debugging?
I would suggest using Client-IP-Address,
Curt LeCaptain [EMAIL PROTECTED] wrote:
From what I understand, if people come from the NAS-IP-Address of
ip.add.re.ss, it should be stopping everything, giving them their IP
and not continuing on due to the Fall-Through = No. Perhaps I'm
getting this wrong, but I'm trying to make it so that
As always, run it in debugging mode. You would see the answer.
In this case, NAS-IP-Address is an attribute in the RADIUS packet.
So if the NAS doesn't send it, it doesn't match that entry.
Okay, so I'm looking at my radiusd -X output and here's what I get on a
access-request:
rad_recv:
5 matches
Mail list logo
