FR 3.0 doesn't return Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id in Access-Accept

[Nick Porter]

Hi Alex,

I'm glad that has worked.

FreeRADIUS's configuration is actually driven by the file radiusd.conf - 
if you look in there, you'll see various $INCLUDE lines which pull in 
files from other sub directories, including sites-enabled.

So, the default configuration that ships with FreeRADIUS has a bunch of 
example virtual servers in sites-available with just a limited number 
(usually only "default" and "inner-tunnel") symlinked into sites-enabled.

Ultimately it doesn't matter whether the files in sites-enabled are 
symlinks to those in sites-available, or whether they are just plain 
files - as long as the "$INCLUDE sites-enabled/" line is in 
radiusd.conf, FreeRADIUS will read whatever is in that directory as it 
is reading its configuration.

The same approach is used with modules - sample modules configurations 
are in mods-available, with the commonly used ones then symlinked into 
mods-enabled in the default configuration.

Nick

On 07/01/2022 09:57, Alex Zetaeffesse wrote:
> Thanks Nick,
>
> it works. I have just a question about the organization of the directory
> sites-available,I don't know if you can answer or comment on it: I see
> there all the FR components.
> I guess the  sites-available/sites-enabled takes it from the way Apache is
> structured but it's a bit misleading, isn't it? Because since FR uses
> virtual servers I would expect to find ust the definition of the virtual
> servers. By creating symlinks to sites-available can I enable/disable FR
> components? Or how does it work?
>
> Thanks again for your help,
>
> Alex
>
> On Thu, Jan 6, 2022 at 10:02 AM Nick Porter <nick at portercomputing.co.uk>
> wrote:
>
>> Hi  Alex
>>
>> There are two changes I think you need to make:
>>
>> 1. In the inner-tunnel virtual server there is a block wrapped in "if
>> (0)" - change that to "if (1)" to ensure copy the appropriate reply
>> attributes from the inner tunnel to the outer session list.
>>
>> Then in the default virtual server, in the post-auth section, ensure you
>> have
>>
>> update {
>>       &reply := &session-state
>> }
>>
>> 2. Remove the call to the files module in the authorize section of the
>> default virtual server - that is what is putting the attributes in the
>> Access-Challenge packets.
>>
>> If you are authenticating other types of users which are not using a
>> tunnelled EAP method, and that authentication relies on data in the
>> users file, then I would define a different instance of the files module
>> for the EAP-PEAP user and use that instance in the inner-tunnel.
>>
>> Nick
>>
>> On 06/01/2022 00:07, Alex Zetaeffesse wrote:
>>> Hi,
>>>
>>> I configured a user as follows in /etc/freeradius/3.0/users
>>>
>>> # PEAP Cisco
>>> cisco at realm.local  Cleartext-password := realm123
>>>        Tunnel-Type=VLAN,
>>>        Tunnel-Medium-Type=IEEE-802,
>>>        Tunnel-Private-Group-Id = "VLAN103"
>>>
>>> I see FR sends such attributes in the second Access-Challenge but not in
>>> the Access-Accept.
>>> Therefore our 9800 puts the client in the default VLAN.
>>> Most probably it's a FR misconfiguration but I wouldn't know why and
>> where
>>> in the config to fix it.
>>>
>>> I have attached the debugs from freeradius -X and the captures.
>>>
>>> Hope somebody can point me in the right direction.
>>>
>>> Alex
>>>
>>> -
>>> List info/subscribe/unsubscribe? See
>> http://www.freeradius.org/list/users.html
>>
>> --
>> Nick Porter
>>
>> Porter Computing Ltd
>> Registered in England No 12659380
>>
>> -
>> List info/subscribe/unsubscribe? See
>> http://www.freeradius.org/list/users.html
>>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

-- 
Nick Porter

Porter Computing Ltd
Registered in England No 12659380


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20220107/bc4b41da/attachment.sig>