d(a)emonkeeper's purgatory

Have you ever been annoyed from managing a complex VLAN setup on switches? It is a complex task. Not so much to actually configure a VLAN but to track state among different hardware, allowed and forbidden group memberships, configurations and to keep an eye on your networks. You can ease your live by assigning VLANs dynamically by MAC address. All you need is a switch supporting MAC Authentication (“Mac-Auth“) and a RADIUS server providing a data base of your assignments. Afterwards your switch will automatically assign your clients to the right VLAN.

I’m going to explain how to achieve this with a Juniper EX series switch running JUNOS and a Debian server running a FreeRADIUS server.

Why do I need a VLAN

Consider you are on a network with different entities and groups. Just think of a network with public facing servers and a network for private access like an web server, an e-mail relay and so on. In the private network you run data base servers, network file systems and so on – chances are you don’t want to have those services accessible from the public for security reasons.
Now you say: “Ehrm wait – what about private Internet addresses? All you need is a non-routable IP like the one in the 192.168.0.0/16 range” . You are right, that’s the first requirement, but it is not sufficient, since it won’t protect you from internal attacks. Just because you did add an additional network layer, you still share the same Ethernet segment. Unless you segregate your networks into two physically isolated partitions, you are not safe. That being said, a private address range does not protect from local network attacks. For example an attacker being able to compromise a public system of yours, could just add another IP address to access internal servers as well. Just because you actually don’t see traffic not destined to you when being in a different IP network, it doesn’t mean it isn’t there on Ethernet level.

This is where VLANs – Virtual Local Area Networks enter the game. As said, you need to isolate network segments for security reasons. You could do that by using physically separate switches. It should be obvious to you, that this won’t scale, if you consider service provider setups for example, whom have hundreds of such networks and nodes participating in several networks at once. Moreover a physical division is not always possible, since servers sharing the same segment could be physically distant, making life really complicated to do such things.

Therefore, the idea is to have a network behaving and looking like a physical but not being actually physical. You can consider a VLAN a set of overlay networks on top of a physical infrastructure (it is – however – not a virtualized network, which is a different thing!). This works by adding an identifier to each Ethernet frame being sent on the switch. Most hosts are connected to switches these days and sends out Ethernet frames when sending a message. Now the switch tags this frame, bit extending the header by a with given VLAN identifier. The switch will forward this message only to ports whom are member of this VLAN identifier as well. Doing this, a network host can’t escape from its assigned network just by adding another IP, since the switch will not forward segments destined to another virtual ethernet network. This is the access port mode in VLAN terminology.

Another method is the so called trunk mode. This requires the host end, for example the end system, being aware to be member of a VLAN and let the client itself choose to which VLAN a given frame should be sent to. This is useful for switch to switch communication on communication “backbones” or routers, participating in several networks at once. You see, there is a lot of complexity entering the game you have to keep track.

There are plenty of ways to manage VLANs, synchronize state and solve similar problems. As soon as your network grows, you will sooner or later find out, it tends to be a complicated task to configure VLAN access ports and trunk ports when applicable, to make sure all your peers participate in all the networks they should. Sooner or later you will find out, this is a lot of effort to not lose track. A simple but yet nifty solutions is to automate VLAN assignment by identifying the VLAN membership by the MAC address of the client itself (more on this again in the Wiki). Note, Cisco knows a similar, but proprietary concept called “VLAN Management Policy Server” (VMPS), although the RADIUS based MAC authentication is standardized in IEEE 802.1X, so it should work on Cisco switches as well.

Beware, the assignment of VLANs based on MAC addresses is a security threat if you can’t enforce the source MAC address! That is, when considering such a setup, you must use a MAC filter to prevent spoofing attacks, since that would allow clients to escape from the VLAN they are supposed to be a member of.

RADIUS

RADIUS is a standardized method for Authentication, Authorization and Accounting, hence it is usually referred to as AAA. Nearly all service providers are using RADIUS for some purposes. It is a rather complex protocol, but fortunately for what we require from it, it is simple to use. If you are on Debian all you need to do get it, is to do a

apt-get install freeradius

Note, you don’t need a data base for FreeRADIUS but you better do, if you want to deploy it on large scale. For the sake of simplicity I will use plain text files though. To get hints on how to run a data base enabled FreeRADIUS server, read more in the FreeRADIUS Wiki. Moreover you should be aware that MAC authentication is standardized, but not thought as only authentication scheme. Indeed the idea is to use MAC based authentication as fall back scheme for clients, not aware or able to authenticate through RADIUS. Therefore you need to relax rules a bit to effectively abuse FreeRADIUS as VLAN data provider. Mostly RADIUS is using the “Extensible Authentication Protocol” (EAP) to authenticate clients.

This works pretty much like you know it from your Internet service provider at home. You provide a user name and a password and a client handshake protocol establishes a connection with an authenticating remote peer. This is not acceptable for “dumb” clients, as those are not aware they have to authenticate at all. So, as method of last resort, you use the MAC address for both, user name and password. In my setup I use the MAC based authentication as first class citizen to carry a VLAN service group along the authentication message to the client which the authenticated user should join. Note, the RADIUS client is the switch in this case, requesting authentication on behalf of the peer connected on a port of it (the “supplicant”), which is not aware of the RADIUS authentication in the background at all. Architecture looks as outlined in the picture above: The end system sends an Ethernet frame to the network. As soon as the frame arrives at the switch, it will try to authenticate the host by producing a RADIUS authentication message to the RADIUS server. This authentication message contains the end host’s MAC address, which has been learned by the switch from the packet showing up on its forward plane. .
Finally, the RADIUS server acknowledges the authentication message and sends the desired VLAN along the message. The switch reads that message, and puts the supplicant’s flow into that VLAN.

As soon as you installed FreeRADIUS on your system, you will notice a lot of configuration files in /etc/freeradius. You can remove most of them as you won’t need them (or leave them untouched). First, configure radiusd.conf – note I threw out most of the side references to other configuration files:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103

# -*- text -*-
##
## radiusd.conf -- FreeRADIUS server configuration file.
##
 
 
prefix = /usr
exec_prefix = /usr
sysconfdir = /etc
localstatedir = /var
sbindir = ${exec_prefix}/sbin
logdir = /var/log/freeradius
raddbdir = /etc/freeradius
radacctdir = ${logdir}/radacct
 
name = freeradius
 
confdir = ${raddbdir}
run_dir = ${localstatedir}/run/${name}
db_dir = ${raddbdir}
libdir = /usr/lib/freeradius
 
pidfile = ${run_dir}/${name}.pid
 
user = freerad
group = freerad
 
max_request_time = 30
 
cleanup_delay = 5
 
max_requests = 1024
 
listen {
        type = auth
        ipaddr = 10.10.102.4
        port = 0
}
 
hostname_lookups = no
allow_core_dumps = no
 
regular_expressions     = yes
extended_expressions    = yes
 
log {
        destination = files
        file = ${logdir}/radius.log
        syslog_facility = daemon
        stripped_names = no
        auth = yes
        auth_badpass = yes
        auth_goodpass = yes
}
 
checkrad = ${sbindir}/checkrad
 
security {
        max_attributes = 200
        reject_delay = 1
        status_server = yes
}
 
proxy_requests  = yes
 
 
client switch {
        ipaddr          = 10.10.102.1
        secret          = mysecret
        require_message_authenticator = no
        nastype     = other
}
 
 
thread pool {
        start_servers = 5
        max_servers = 32
        min_spare_servers = 3
        max_spare_servers = 10
        max_requests_per_server = 0
}
 
modules {
        $INCLUDE ${confdir}/modules/
        $INCLUDE eap.conf
}
 
instantiate {
        exec
        expr
        expiration
        logintime
 
}
 
authorize {
        eap
        files
}
 
authenticate {
        eap
}

There is a lot of boring standard stuff in this configuration, real fun begins at line 34. There you specify the listening interface for incoming connections. Configure FreeRADIUS to listen for authentication requests (line 35) on the IP and port you want. Leave 0 to make FreeRADIUS listen on its default port (TCP 1814). You don’t need to listen for accounting connections if you paln to use MAC based authentication only (obviously), therefore feel free to disable those interfaces.

In lines 46 to 54 I configured a verbose logging of message. Strictly speaking you don’t need that, and you neither want it that verbose on productive systems, but to get hands dirty enable it for debugging purposes.

In line 67 I finally configured clients allowed to connect to the authentication server. Note again: In this case, the client is the switch performing authentication – not the actual host you want to assign to a VLAN. You may want to restrict access to a specific IP address and assign a password for security.

FreeRADIUS is completely modular, hence you can enable a lot of authenticators, protocols and methods. As said, MAC authentication is usually meant to bypass authentication for “dumb” clients, so we won’t need most of available features, FreeRADIUS provides. However you must nonetheless use EAP, hence make sure you load the module to initialize it (line 85 in my configuration) and you enable authentication based on it (see line 97 and 102).

The “Extensible Authentication Protocol” is powerful, but we need a simple subset of it only. In fact, we use EAP just to send the MAC address in clear text. However I did not change much on the shipped eap.conf file, when compared to version as shipped by Debian (note, Debian provides self-signed SSL certificates as well). All I did is to disable some things and to reformat the file. Nonetheless, for the records, my eap.conf looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

# -*- text -*-
##
##  eap.conf -- Configuration for EAP types (PEAP, TTLS, etc.)
##
 
eap {
        default_eap_type = md5
        timer_expire     = 60
        ignore_unknown_eap_types = no
        cisco_accounting_username_bug = no
        max_sessions = 4096
        md5 {
        }
        leap {
        }
        gtc {
                auth_type = PAP
        }
        tls {
                certdir = ${confdir}/certs
                cadir = ${confdir}/certs
                #private_key_password = whatever
                private_key_file = ${certdir}/server.key
                certificate_file = ${certdir}/server.pem
                CA_file = ${cadir}/ca.pem
                dh_file = ${certdir}/dh
                random_file = ${certdir}/random
                cipher_list = "DEFAULT"
                cmake_cert_command = "${certdir}/bootstrap"
                cache {
                enable = no
                        lifetime = 24 # hours
                        max_entries = 255
                }
        }
 
        ttls {
                default_eap_type = md5
                copy_request_to_tunnel = no
                use_tunneled_reply = no
                virtual_server = "inner-tunnel"
        }
 
        peap {
                default_eap_type = mschapv2
                copy_request_to_tunnel = no
                use_tunneled_reply = no
                virtual_server = "inner-tunnel"
        }
 
        mschapv2 {
        }
}

Just one thing has to be mentioned here: In line 27 the EAP module references some random entropy it needs to work. You need to provide that yourself. Random stuff is purely random, so do a

dd if=/dev/random of=/etc/freeradius/certs/random bs=1k count=1024K

to get some randomness and make the RADIUS server happy.

Configure MAC-Auth

As I said initially, I used plain text files to provide access lists of valid users. The “files” statement is responsible to enable this (as referenced in line 98 of radiusd.conf). You can find the configuration of this module in /etc/freeradius/modules/files if you do care, however you don’t need to change anything here. If you look into that file though, you will notice it references the actual user configuration file. Unless you change the path, you will find it on /etc/freeradius/users by default. This is, where real fun starts. This is the file, where you define valid supplicants, i.e. the end hosts you want to interconnect. The file is really simple (note I omitted the second client I am later occasionally referring to, as its configuration is nearly identical):

1
2
3
4

00163e13975a    Auth-Type := "EAP", Cleartext-Password := 00163e13975a
        Tunnel-Type = VLAN,
        Tunnel-Medium-Type = IEEE-802,
        Tunnel-Private-Group-Id = "PRIVATE_VLAN"

You see, I identify the client by their MAC address. You don’t see it? Let’s compare with the host’s ifconfig output:

root@vm1:/home/at# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:16:3e:13:97:5a  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:122340 errors:0 dropped:0 overruns:0 frame:0
          TX packets:329 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:9427903 (8.9 MiB)  TX bytes:24362 (23.7 KiB)
          Interrupt:32 Memory:da000000-da012800

So in fact, all I did is to take the MAC address (referred to as “HWaddr” in the output above), removed the colons and pasted it into the heading entry of each user stanza twice. The first time as user name, the second time as password. Along with the authentication type set to “EAP” we are done. Having this entry on a single line (yep, that’s important!), we are ready to authenticate the host with a single line.

After a successful authentication you can push additional information to the authenticator. This is, where the VLAN configuration is propagated to the switch. Basically you just tell the switch it should use VLANs to tunnel packets (in the second line). In the final line of every stanza you define a “Tunnel-Private-Group-Id“, which is the VLAN identifier you want the client to be assigned to. I use the literal “PRIVATE_VLAN” there.

This name is just an identifier you can use to identify a particular VLAN. It is rather common to name VLANs which makes it easier to remember its purpose and name. as those are easier to remember rather than numbers. However, if you prefer, you can use the pure numeric VLAN identifier as well. If you use literals, make sure your switch knows how to translate those name though.

EX configuration

As RADIUS is standardized in 802.1X, JUNOS refers its configuration in the the protocols > dot1x hierarchy. Before you can actually configure the MAC based authentication, you have to make the RADIUS server known to the switch. Use the IP, port and password as you defined in your radiusd.conf above. Enter configuration mode in JUNOS and type:

set access radius-server 10.10.102.4 port 1812
set access radius-server 10.10.102.4 secret mysecret
set access radius-server 10.10.102.4 retry 5

Don’t forget to replace parameters as you need them. Next configure an authentication profile, making use of this RADIUS server:

set access profile auth authentication-order radius
set access profile auth radius authentication-server 10.10.102.4

The resulting configuration should look like this:

access {                                
    radius-server {                     
        10.10.102.4 {                   
            port 1812;                  
            secret "..."; ## SECRET-DATA
            retry 5;                    
        }                               
    }                                   
    profile auth {                      
        authentication-order radius;    
        radius {                        
            authentication-server 10.10.102.4;
        }                               
    }                                   
}

Now make sure, you have configured the VLAN from the users file as I explained before. Remember, I want to assign my end hosts to a VLAN called “PRIVATE_VLAN”. So I did:

set vlans PRIVATE_VLAN vlan-id 1000

Next I finally enabled MAC based RADIUS authentication on two ports of the switch, ge-0/0/26 and ge-1/0/14 in my case. As further requirement it is important, you have no static VLAN configuration on those ports and you set the port type to ethernet-switching. Now configure dot1x:

edit protocols dot1x authenticator 
set authentication-profile-name auth
set interface ge-0/0/26.0 supplicant multiple
set interface ge-0/0/26.0 mac-radius restrict
set interface ge-0/0/26.0 no-reauthentication
set interface ge-1/0/14.0 supplicant multiple
set interface ge-1/0/14.0 mac-radius restrict
set interface ge-1/0/14.0 no-reauthentication

Note, I referenced the authentication profile I defined above and I configured the MAC authentication for the two interfaces outlined above. The “no-reauthentication” statement causes JUNOS to disable a periodic reauthentication of the client. This is not desired, when using RADIUS only to assign VLANs. Read here about possible settings in the dot1x hierarchy. The most important thing is the “mac-radius restrict” setting. The supplicant multiple line causes the switch to allow multiple supplicants (i.e. hosts) to share the same physical port. Depending on your setup this can be desired or not. It is for me, since I have a bridged interface on the other end, where Xen virtual machines do connect (I filter for spoofed MAC addresses there by the way, don’t forget to do that similarly!). Moreover, while it is not needed, it is helpful to enable a monitor to provide debugging output:

set protocols dot1x traceoptions file dot1x
set protocols dot1x traceoptions flag state
set protocols dot1x traceoptions flag dot1x-debug
set protocols dot1x traceoptions flag eapol

Again, this is how the final configuration should look like:

protocols {                             
...
    dot1x {                             
        traceoptions {                  
            file dot1x;                 
            flag state;                 
            flag dot1x-debug;           
            flag eapol;                 
        }                               
        authenticator {                 
            authentication-profile-name auth;
            interface {                 
                ge-0/0/26.0 {           
                    supplicant multiple;
                    mac-radius {        
                        restrict;       
                    }                   
                    no-reauthentication;
                }                       
                ge-1/0/14.0 {           
                    supplicant multiple;
                    mac-radius {        
                        restrict;       
                    }                   
                    no-reauthentication;
                }                       
            }                           
        }                               
    }

Bringing all together

Well, that was it. Now its time to commit your changes on the switch and to start your FreeRADIUS server unless you already did. You can use the usual init script shipped along the FreeRADIUS package, but to see what happens, I suggest you to start it by hand wit debugging switches turned on:

$ /usr/sbin/freeradius -sX
...
Listening on authentication address 10.10.102.4 port 1812
Listening on proxy address 10.10.102.4 port 1814
Ready to process requests.

If everything went fine, you can now see, whether you get network connectivity on your client. Since you are using MAC authentication, all you need to do is to send some packets to a non local destination. So ping a remote host or do whatever you want, just make sure you triggers some Ethernet frames. As soon as they show up on the switch, it should start authenticating. You can verify, whether it worked by calling “show dot1x interface“:

arno@switch> show dot1x interface                         
802.1X Information:
Interface     Role           State           MAC address          User
ge-0/0/26.0   Authenticator  Authenticated   00:16:3E:13:97:5A    00163e13975a 
ge-1/0/14.0   Authenticator  Authenticated   00:16:3E:36:EF:FD    00163e36effd

An even more verbose output discloses, whether the VLAN configuration worked as well:

arno@switch> show dot1x interface detail 
ge-0/0/26.0
  Role: Authenticator
...
  Mac Radius: Enabled
...
    Supplicant: 00163e13975a, 00:16:3E:13:97:5A
      Operational state: Authenticated
      Authentcation method: Mac Radius
      Authenticated VLAN: PRIVATE_VLAN
      Session Reauth interval: 3600 seconds
      Reauthentication due in 0 seconds

Also, a “show vlans” should list the interfaces having joined the “PRIVATE_VLAN” pool. Analogously, for FreeRADIUS you should see something similar to my output as well:

...
Sending Access-Challenge of id 151 to 10.10.102.1 port 62064
        Tunnel-Type:0 = VLAN
        Tunnel-Medium-Type:0 = IEEE-802
        Tunnel-Private-Group-Id:0 = "PRIVATE_VLAN"
        EAP-Message = 0x0101001604102ce60b6060e3344daff6671b833581c3
        Message-Authenticator = 0x00000000000000000000000000000000
        State = 0x071b05ff071a01170a112e296d9c47e6
Finished request 0.
Going to the next request
Waking up in 4.9 seconds.
rad_recv: Access-Request packet from host 10.10.102.1 port 62064, id=58, length=212
        User-Name = "00163e36effd"
        NAS-Port = 85
        State = 0x071b05ff071a01170a112e296d9c47e6
        EAP-Message = 0x02010022041012ec6e15365c463a7a11d46b993a2e2b303031363365333665666664
        Message-Authenticator = 0xfe3946606f0ec76a95c1cbac3be26a7c
        Acct-Session-Id = "8O2.1x81b601b700038690"
        NAS-Port-Id = "ge-1/0/14.0"
        Calling-Station-Id = "00-16-3e-36-ef-fd"
        Called-Station-Id = "50-c5-8d-ae-25-00"
        NAS-Identifier = "switch"
        NAS-Port-Type = Ethernet
# Executing section authorize from file /etc/freeradius/radiusd.conf
+- entering group authorize {...}
[eap] EAP packet type response id 1 length 34
[eap] No EAP Start, assuming it's an on-going EAP conversation
++[eap] returns updated
[files] users: Matched entry 00163e36effd at line 8
++[files] returns ok

To troubleshoot you can also look into JUNOS’ monitor output. The output will look like this upon success:

arno@switch> monitor start dot1x                          
Mar 18 10:06:09.231577 ASM CONNECTING: ONLY-MAC-MODE init on intf ge-1/0/14.0
...
Mar 18 10:06:09.231766  ASM moved to state: AUTHENTICATING !!
...
Mar 18 10:06:09.231825  for Port: 85, MAC: 163e36-effd 
....
Mar 18 10:06:09.232361 Queuing message to auth client to validate mac address 0:16:3e:36:ef:fd, user 00163e36effd on interface ge-1/0/14.0
...
Mar 18 10:06:09.241628 Received message from authentication client
...
Mar 18 10:06:09.242002 process_auth_reply len:3002
Mar 18 10:06:09.242280 Received VLAN ID/name PRIVATE_VLAN from authentication server
Mar 18 10:06:09.242330 Received Access-Accept authentication message
Mar 18 10:06:09.242360 Invoking state machine for authentication response for mac address 00:16:3E:36:EF:FD 
Mar 18 10:06:09.242380  on intf ge-1/0/14.0
...
Mar 18 10:06:09.243053  BSM Called with Event: ASUCCESS_RCVD, and State: Response
Mar 18 10:06:09.243507  BSM moved to state: SUCCESS !!
...
Mar 18 10:06:09.243628  ASM moved to state: AUTHENTICATED from Authenticating!!
Mar 18 10:06:09.243655  ASM moved to state: AUTHENTICATED !!