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@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@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