dot1x, MAB and EAP-TLS/PEAP with Freeradius
Alan DeKok
aland at deployingradius.com
Wed Sep 7 13:41:40 UTC 2022
On Sep 7, 2022, at 7:02 AM, Vieri Di Paola <vieridipaola at gmail.com> wrote:
> I would like to allow host access to the network according to these
> restrictions (I am listing only those that require a RADIUS server):
>
> 1) wireless clients that connect to a specific SSID are required to
> either use EAP-TLS or PEAP. If they pass the authorization and
> authentication they will be dynamically assigned to vlan 112 (base on
> a local SQL lookup of their MAC addresses). Rejected otherwise.
>
> 2) wired clients:
>
> a) If they support dot1x, use either EAP-TLS or PEAP and pass then
> they will be dynamically assigned to vlan 20 (base on a local SQL
> lookup of their MAC addresses).
Are these from different NASes? i.e. are the RADIUS packets for WiFi coming from a different IP address than RADIUS packets for wired?
If so, just read sites-available/README, especially section 5. You can use completely different virtual servers for the two cases.
It's often difficult to design correct if / then / else logic for complex cases like this. So the simple solution is "don't do that, use a different approach".
> b) If dot1x fails try MAC Authentication Bypass. The MAC address
> received by the Freeradius server will be looked up in a local DB, and
> a VLAN ID will be dynamically assigned accordingly (different vlan IDs
> except '1').
>
> c) If the MAC address involved in MAB is not found in the local DB
> then allow access but dynamically assign another vlan ID (eg. 1).
That "fail over to MAB" is a done by the switch. You just configure FreeRADIUS to allow both 802.1X and MAB.
> I have a FreeRADIUS server and a mix of Cisco and D-Link switches (but
> I'll be focusing on Cisco because I don't think the D-Link models I
> have support MAB).
>
> Step 1 (wireless clients) has been working fine for years now.
That's good.
> I managed to get step 2 working, but then step 1 fails.
Likely because something for step 1 changed.
> The configuration is quite long so I hope no one minds if I paste here
> some sections.
The configuration is generally not helpful. What matters is how it's used, which is the debug output.
> So the host HM2214.domain.local is now within vlan 112 and has the
> expected network access rights.
>
> I then tried to modify the Freeradius configuration to allow wired
> hosts access to the network. Again, to simplify things at first I did
> not connect a client with dot1x - I just wanted to use MAB. Thus the
> Cisco switch sends the client's MAC address as the "user name".
>
> This is part of a debug log of a successful login of a wired host.
Which doesn't show a lot.
> In order to get this I modified 'sites-enabled/default' to include
> 'files' in the 'authorize' section. I also had to add the following in
> the users file:
>
> DEFAULT Auth-Type := Accept
That's almost always wrong. That tells the server to bypass all authentication, including 802.1X.
> That's because I was hoping to accomplish what is stated in Step 2
> (c), ie. allow "any" MAC address but assign a different vlan ID.
>
> With this configuration wired hosts access "as expected", but wireless
> hosts with EAP-TLS fail to have access to the network even though the
> freeradisu debug log reports a "Login OK" line. The EAP messages are
> not seen in the log so it seems they're being by-passed.
Exactly.
> I'd like to give more information, but this e-mail is long already --
> maybe even too long.
>
> What could I try from here?
Don't set a DEFAULT which applies to all packets. Instead, read the debug output to see how the MAB packets are different from the 802.1X packets.
Then, write "unlang" rules to match the MAB packets (but not the 802.1X packets!). Something like:
authorize {
...
if (somehow packet is MAB) {
do MAB stuff
accept
}
...
}
That will still "accept" the MAB packets, but it won't match the 802.1X packets.
Alan DeKok.
More information about the Freeradius-Users
mailing list