Freeradius and Unifi Vlan
Hi Im trying to use freeradius to assign the VLAN of a connection using the unifi AP, like in this page: https://help.ubnt.com/hc/en-us/articles/219654087-UniFi-Using-VLANs-with-Uni... My server is a Debian jessie fresh install with Freeradius 3.0.12(compiled from source, using defaults) and unifi controler 5.3.5(beta version, but i see some guys using radius+vlan using a cisco solution) My AP is a UniFi AP-AC-Lite firmware 3.7.24.5422 My users file(the default file and i add in the end): kemi Cleartext-Password := "1q2w3e4r" Tunnel-Type = VLAN, Tunnel-Medium-Type = 6, Tunnel-Private-Group-Id = 3 My clients.conf client private-network-1 { ipaddr = 192.168.3.0/24 secret = testing123 } In radiusd.conf i only change line 510: allow_vulnerable_openssl = 'CVE-2016-6304' The radiusd -X when i use radtest(i attatch the full log) (0) Login OK: [kemi/1q2w3e4r] (from client private-network-1 port 0) (0) Sent Access-Accept Id 130 from 192.168.3.1:1812 to 192.168.3.1:56590 length 0 (0) Tunnel-Type = VLAN (0) Tunnel-Medium-Type = IEEE-802 (0) Tunnel-Private-Group-Id = "3" (0) Finished request The radiusd -X when i use the AP: (9) post-auth { ... } # empty sub-section is ignored (9) Login OK: [kemi/<via Auth-Type = eap>] (from client private-network-1 port 0 via TLS tunnel) (9) } # server inner-tunnel (9) Virtual server sending reply (9) Tunnel-Type = VLAN (9) Tunnel-Medium-Type = IEEE-802 (9) Tunnel-Private-Group-Id = "3" (9) MS-MPPE-Encryption-Policy = Encryption-Required (9) MS-MPPE-Encryption-Types = 4 (9) MS-MPPE-Send-Key = 0x5cbfff77aff0148b908c8cec2efaae2c (9) MS-MPPE-Recv-Key = 0xd4ad8206c448c3530a1e547ee91f173c (9) EAP-Message = 0x03030004 (9) Message-Authenticator = 0x00000000000000000000000000000000 (9) User-Name = "kemi" (9) eap_ttls: Got tunneled Access-Accept (9) eap_ttls: No information to cache: session caching will be disabled for session 4487edec31086c9129e937fada901fbda23ba4600dd0d7e67f0c5e1a843ba264 (9) eap: Sending EAP Success (code 3) ID 58 length 4 But unifi still using vlan 1, is possible the unifi is not receiving the Tunnel information? Thanks
Hi guys I recive a mensagem from unifi forum and is need to change the eap configuration: *copy_request_to_tunnel = yes use_tunneled_reply = yes proxy_tunneled_request_as_eap = yes* Sorry for opening a thread, the search in the unifi foruns don't work really fine Thanks 2016-11-10 10:02 GMT-02:00 Gabriel Ozaki <gabriel.ozaki@kemi.com.br>:
Hi Im trying to use freeradius to assign the VLAN of a connection using the unifi AP, like in this page: https://help.ubnt.com/hc/en-us/articles/219654087-UniFi- Using-VLANs-with-UniFi-Wireless-Routing-Switching-Hardware#UAP
My server is a Debian jessie fresh install with Freeradius 3.0.12(compiled from source, using defaults) and unifi controler 5.3.5(beta version, but i see some guys using radius+vlan using a cisco solution) My AP is a UniFi AP-AC-Lite firmware 3.7.24.5422
My users file(the default file and i add in the end): kemi Cleartext-Password := "1q2w3e4r" Tunnel-Type = VLAN, Tunnel-Medium-Type = 6, Tunnel-Private-Group-Id = 3
My clients.conf client private-network-1 { ipaddr = 192.168.3.0/24 secret = testing123 }
In radiusd.conf i only change line 510: allow_vulnerable_openssl = 'CVE-2016-6304'
The radiusd -X when i use radtest(i attatch the full log) (0) Login OK: [kemi/1q2w3e4r] (from client private-network-1 port 0) (0) Sent Access-Accept Id 130 from 192.168.3.1:1812 to 192.168.3.1:56590 length 0 (0) Tunnel-Type = VLAN (0) Tunnel-Medium-Type = IEEE-802 (0) Tunnel-Private-Group-Id = "3" (0) Finished request
The radiusd -X when i use the AP: (9) post-auth { ... } # empty sub-section is ignored (9) Login OK: [kemi/<via Auth-Type = eap>] (from client private-network-1 port 0 via TLS tunnel) (9) } # server inner-tunnel (9) Virtual server sending reply (9) Tunnel-Type = VLAN (9) Tunnel-Medium-Type = IEEE-802 (9) Tunnel-Private-Group-Id = "3" (9) MS-MPPE-Encryption-Policy = Encryption-Required (9) MS-MPPE-Encryption-Types = 4 (9) MS-MPPE-Send-Key = 0x5cbfff77aff0148b908c8cec2efaae2c (9) MS-MPPE-Recv-Key = 0xd4ad8206c448c3530a1e547ee91f173c (9) EAP-Message = 0x03030004 (9) Message-Authenticator = 0x00000000000000000000000000000000 (9) User-Name = "kemi" (9) eap_ttls: Got tunneled Access-Accept (9) eap_ttls: No information to cache: session caching will be disabled for session 4487edec31086c9129e937fada901fbda23ba4600dd0d7e67f0c5e1a843b a264 (9) eap: Sending EAP Success (code 3) ID 58 length 4
But unifi still using vlan 1, is possible the unifi is not receiving the Tunnel information?
Thanks
On 10/11/2016 12:02, Gabriel Ozaki wrote:
But unifi still using vlan 1, is possible the unifi is not receiving the Tunnel information?
Look carefully at the end of your debug output: (9) Login OK: [kemi/<via Auth-Type = eap>] (from client private-network-1 port 0 cli F8-2F-A8-F5-12-97) (9) Sent Access-Accept Id 40 from 192.168.3.1:1812 to 192.168.3.190:49091 length 0 (9) MS-MPPE-Recv-Key = 0x9cef482e0e294db32ca069d27b9a4b1605896ae638b2d845ffd593d7fc00777e (9) MS-MPPE-Send-Key = 0xd010d975e1b595af9f1c04a1ad0e07d22213f62823948c425fc21bfb18c16b5e (9) EAP-Message = 0x033a0004 (9) Message-Authenticator = 0x00000000000000000000000000000000 (9) User-Name = "kemi" (9) Finished request The final reply doesn't include those attributes; the inner tunnel auth has them, but they don't appear in the outer session. You need to set: use_tunneled_reply = yes Similarly, if in your inner tunnel logic you want to make use of attributes in the request (such as Called-Station-ID to see which SSID the client is connecting to), you need: copy_request_to_tunnel = yes These settings are in mods-available/eap Regards, Brian.
You are correct, now is working fine Thanks 2016-11-10 10:47 GMT-02:00 Brian Candler <b.candler@pobox.com>:
On 10/11/2016 12:02, Gabriel Ozaki wrote:
But unifi still using vlan 1, is possible the unifi is not receiving the Tunnel information?
Look carefully at the end of your debug output:
(9) Login OK: [kemi/<via Auth-Type = eap>] (from client private-network-1 port 0 cli F8-2F-A8-F5-12-97) (9) Sent Access-Accept Id 40 from 192.168.3.1:1812 to 192.168.3.190:49091 length 0 (9) MS-MPPE-Recv-Key = 0x9cef482e0e294db32ca069d27b9a 4b1605896ae638b2d845ffd593d7fc00777e (9) MS-MPPE-Send-Key = 0xd010d975e1b595af9f1c04a1ad0e 07d22213f62823948c425fc21bfb18c16b5e (9) EAP-Message = 0x033a0004 (9) Message-Authenticator = 0x00000000000000000000000000000000 (9) User-Name = "kemi" (9) Finished request
The final reply doesn't include those attributes; the inner tunnel auth has them, but they don't appear in the outer session. You need to set:
use_tunneled_reply = yes
Similarly, if in your inner tunnel logic you want to make use of attributes in the request (such as Called-Station-ID to see which SSID the client is connecting to), you need:
copy_request_to_tunnel = yes
These settings are in mods-available/eap
Regards,
Brian.
Hi, i am trying now to make this scenario work with sql. But the VLAN information disapear in the eap answer, like(full log attach): (12) eap_peap: Got tunneled reply RADIUS code 2 (12) eap_peap: Tunnel-Type = VLAN (12) eap_peap: Tunnel-Medium-Type = IEEE-802 (12) eap_peap: Tunnel-Private-Group-Id = "5" (12) eap_peap: MS-MPPE-Encryption-Policy = Encryption-Required (12) eap_peap: MS-MPPE-Encryption-Types = 4 (12) eap_peap: MS-MPPE-Send-Key = 0x13ee183f2b36e3ab894c988ab66767cf (12) eap_peap: MS-MPPE-Recv-Key = 0x619eade4a503a46bb6cfe472b89763ff (12) eap_peap: EAP-Message = 0x03540004 (12) eap_peap: Message-Authenticator = 0x00000000000000000000000000000000 (12) eap_peap: User-Name = "kemi2" (12) eap_peap: Tunneled authentication was successful (12) eap_peap: SUCCESS (12) eap: Sending EAP Request (code 1) ID 85 length 46 (12) eap: EAP session adding &reply:State = 0xe437a030ed62b94d (12) [eap] = handled (12) } # authenticate = handled (12) Using Post-Auth-Type Challenge (12) Post-Auth-Type sub-section not found. Ignoring. (12) # Executing group from file /usr/local/etc/raddb/sites-enabled/default (12) Sent Access-Challenge Id 117 from 192.168.3.1:1812 to 192.168.3.190:49091 length 0 (12) EAP-Message = 0x0155002e19001703030023e11004 733abe7be1910c9689bf21cbcbf1ef5c6fa111398d0e5523e4c0c15e812b1e8d (12) Message-Authenticator = 0x00000000000000000000000000000000 (12) State = 0xe437a030ed62b94ddcae84c47b005509 (12) Finished request ....... (13) [sql] = ok (13) [exec] = noop (13) policy remove_reply_message_if_eap { (13) if (&reply:EAP-Message && &reply:Reply-Message) { (13) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (13) else { (13) [noop] = noop (13) } # else = noop (13) } # policy remove_reply_message_if_eap = noop (13) } # post-auth = ok (13) Login OK: [kemi2/<via Auth-Type = eap>] (from client private-network-1 port 0 cli 00-37-6D-ED-69-41) (13) Sent Access-Accept Id 118 from 192.168.3.1:1812 to 192.168.3.190:49091 length 0 (13) MS-MPPE-Recv-Key = 0xbef38cc2e01eeff7b73767ce0801 54e8453b8b1d6c8faaf140a7dd05683552da (13) MS-MPPE-Send-Key = 0x09861f887608b2e276d24f1d7ee1 d1557b00a4bbcbec566ad63fe7c0ddd5669f (13) EAP-Message = 0x03550004 (13) Message-Authenticator = 0x00000000000000000000000000000000 (13) User-Name = "kemi2" (13) Finished request Waking up in 4.7 seconds. (14) Received Accounting-Request Id 119 from 192.168.3.190:50137 to 192.168.3.1:1813 length 151 (14) Acct-Session-Id = "0000000C-00000007" (14) Acct-Status-Type = Start (14) Acct-Authentic = RADIUS (14) User-Name = "kemi2" (14) NAS-Identifier = "802aa8907353" (14) NAS-Port = 0 (14) Called-Station-Id = "80-2A-A8-91-73-53:TESTE" (14) Calling-Station-Id = "00-37-6D-ED-69-41" (14) NAS-Port-Type = Wireless-802.11 (14) Connect-Info = "CONNECT 0Mbps 802.11b" (14) # Executing section preacct from file /usr/local/etc/raddb/sites- enabled/default The tables: mysql> SELECT * FROM radcheck; +----+----------+--------------------+----+----------+ | id | username | attribute | op | value | +----+----------+--------------------+----+----------+ | 1 | kemi2 | Cleartext-Password | := | 1q2w3e4r | +----+----------+--------------------+----+----------+ 1 row in set (0.00 sec) mysql> SELECT * FROM radreply; +----+----------+-------------------------+----+-------+ | id | username | attribute | op | value | +----+----------+-------------------------+----+-------+ | 1 | kemi2 | Tunnel-Type | := | VLAN | | 2 | kemi2 | Tunnel-Medium-Type | := | 6 | | 3 | kemi2 | Tunnel-Private-Group-Id | := | 5 | +----+----------+-------------------------+----+-------+ 3 rows in set (0.00 sec) I can see the reply mensage in eap and in sql, but the reply is not in the final mensage and i don't know why (note:radtest works fine) Thanks 2016-11-10 10:54 GMT-02:00 Gabriel Ozaki <gabriel.ozaki@kemi.com.br>:
You are correct, now is working fine
Thanks
2016-11-10 10:47 GMT-02:00 Brian Candler <b.candler@pobox.com>:
On 10/11/2016 12:02, Gabriel Ozaki wrote:
But unifi still using vlan 1, is possible the unifi is not receiving the Tunnel information?
Look carefully at the end of your debug output:
(9) Login OK: [kemi/<via Auth-Type = eap>] (from client private-network-1 port 0 cli F8-2F-A8-F5-12-97) (9) Sent Access-Accept Id 40 from 192.168.3.1:1812 to 192.168.3.190:49091 length 0 (9) MS-MPPE-Recv-Key = 0x9cef482e0e294db32ca069d27b9a 4b1605896ae638b2d845ffd593d7fc00777e (9) MS-MPPE-Send-Key = 0xd010d975e1b595af9f1c04a1ad0e 07d22213f62823948c425fc21bfb18c16b5e (9) EAP-Message = 0x033a0004 (9) Message-Authenticator = 0x00000000000000000000000000000000 (9) User-Name = "kemi" (9) Finished request
The final reply doesn't include those attributes; the inner tunnel auth has them, but they don't appear in the outer session. You need to set:
use_tunneled_reply = yes
Similarly, if in your inner tunnel logic you want to make use of attributes in the request (such as Called-Station-ID to see which SSID the client is connecting to), you need:
copy_request_to_tunnel = yes
These settings are in mods-available/eap
Regards,
Brian.
On 11/11/2016 10:40, Gabriel Ozaki wrote:
I can see the reply mensage in eap and in sql, but the reply is not in the final mensage and i don't know why (note:radtest works fine) (4) eap: Found mutually acceptable type PEAP (25)
Looking at debug output, you've set "use_tunneled_reply = yes" for ttls, but forgot to set it to yes for peap. # Linked to sub-module rlm_eap_peap peap { tls = "tls-common" default_eap_type = "mschapv2" copy_request_to_tunnel = no * use_tunneled_reply = no** * proxy_tunneled_request_as_eap = yes virtual_server = "inner-tunnel" soh = no require_client_cert = no } Aside: if you're sending the radtests to localhost:18120, then you're looking just at what the inner-tunnel is doing. That's where the SQL stuff belongs, since only the inner tunnel knows the *true* identity of the logged in user. The outer server should ignore everything and only send the reply attributes from the inner tunnel. If you have something like this in your outer (main) server: eap { ok = return } sql then non-tunnelled sessions will also use your sql logic. However it turns out that some parts of the ongoing EAP exchange will also fall through to the block after eap. I found I needed to do this to avoid it: eap { ok = return updated = return } sql If you don't make this change then it may only be annoying - some unnecessary SQL queries are done, some unnecessary attributes are returned in Access-Challenge responses. But if the sql logic sets Auth-Type := Reject under some circumstances, then I found I was rejecting users before they had a chance to complete their authentication. Regards, Brian.
and on 3.0.12 etc you dont use that option, read the inner-tunnel and enable: # # Instead of "use_tunneled_reply", uncomment the # next two "update" blocks. # # update { # &outer.session-state: += &reply: # } # # These attributes are for the inner session only. # They MUST NOT be sent in the outer reply. # # If you uncomment the previous block and leave # this one commented out, WiFi WILL NOT WORK, # because the client will get two MS-MPPE-keys # # update outer.session-state { # MS-MPPE-Encryption-Policy !* ANY # MS-MPPE-Encryption-Types !* ANY # MS-MPPE-Send-Key !* ANY # MS-MPPE-Recv-Key !* ANY # Message-Authenticator !* ANY # EAP-Message !* ANY # Proxy-State !* ANY # }
Thanks Brian and Alan I enable the update blocks and works on the first time, but on second too, but in the thirt connection the reply VLAN is not present Process: Connect to wifi(works with vlan) disconnect and reconnect(Sometimes works) disconnect and reconnect again(don't work) And looking in the radpostauth table i see some accept-accept replys with login without password :O +----+----------+----------+---------------+---------------------+ | id | username | pass | reply | authdate | +----+----------+----------+---------------+---------------------+ | 1 | kemi2 | 1q2w3e4r | Access-Reject | 2016-11-10 12:04:35 | | 2 | kemi | 1q2w3e4r | Access-Accept | 2016-11-10 12:06:00 | | 3 | kemi2 | 1q2w3e4r | Access-Reject | 2016-11-10 15:26:27 | | 4 | kemi2 | 1q2w3e4r | Access-Reject | 2016-11-10 15:27:52 | | 5 | kemi2 | 1q2w3e4r | Access-Reject | 2016-11-10 15:28:04 | | 6 | kemi2 | 1q2w3e4r | Access-Accept | 2016-11-10 15:28:58 | | 7 | kemi2 | | Access-Accept | 2016-11-10 15:37:49 | | 8 | kemi2 | | Access-Accept | 2016-11-10 15:37:49 | | 9 | kemi2 | 1q2w3e4r | Access-Accept | 2016-11-10 15:49:14 | | 10 | kemi2 | 1q2w3e4 | Access-Reject | 2016-11-10 15:49:18 | | 11 | kemi2 | 1q2w3e4r | Access-Accept | 2016-11-10 15:49:25 | | 12 | kemi2 | | Access-Accept | 2016-11-10 15:49:54 | | 13 | kemi2 | | Access-Accept | 2016-11-10 15:49:54 | | 14 | kemi2 | | Access-Reject | 2016-11-10 16:10:44 | ... | 54 | kemi2 | | Access-Accept | 2016-11-11 09:45:48 | | 55 | kemi2 | | Access-Accept | 2016-11-11 09:45:56 | +----+----------+----------+---------------+---------------------+ There is any flowchart of freeradius 3 to help me understand how the login proccess? if i understand the log is something like: client send wireless request -> eap decode, send to sql(via inner-tunnel?) -> sql validate, if fails try other options(ex:users file), then send back to eap(via inner-tunnel?) -> eap send reply to client 2016-11-11 9:23 GMT-02:00 Alan Buxey <A.L.M.Buxey@lboro.ac.uk>:
and on 3.0.12 etc you dont use that option, read the inner-tunnel and enable:
# # Instead of "use_tunneled_reply", uncomment the # next two "update" blocks. # # update { # &outer.session-state: += &reply: # }
# # These attributes are for the inner session only. # They MUST NOT be sent in the outer reply. # # If you uncomment the previous block and leave # this one commented out, WiFi WILL NOT WORK, # because the client will get two MS-MPPE-keys # # update outer.session-state { # MS-MPPE-Encryption-Policy !* ANY # MS-MPPE-Encryption-Types !* ANY # MS-MPPE-Send-Key !* ANY # MS-MPPE-Recv-Key !* ANY # Message-Authenticator !* ANY # EAP-Message !* ANY # Proxy-State !* ANY # }
On Nov 11, 2016, at 7:06 AM, Gabriel Ozaki <gabriel.ozaki@kemi.com.br> wrote:
I enable the update blocks and works on the first time, but on second too, but in the thirt connection the reply VLAN is not present Process: Connect to wifi(works with vlan) disconnect and reconnect(Sometimes works) disconnect and reconnect again(don't work)
As always, read the debug output to see what's going on.
And looking in the radpostauth table i see some accept-accept replys with login without password :O
Because that's how EAP works.
There is any flowchart of freeradius 3 to help me understand how the login process?
http://networkradius.com/freeradius-documentation/ Read the FreeRADIUS technical guide. Alan DeKok.
Hi,
I enable the update blocks and works on the first time, but on second too, but in the thirt connection the reply VLAN is not present Process: Connect to wifi(works with vlan) disconnect and reconnect(Sometimes works) disconnect and reconnect again(don't work)
And looking in the radpostauth table i see some accept-accept replys with login without password :O
sounds to me like youve got caching turned on. in which case, the server will bypass several things and used the cached policy. alan
Disable the cache on eap module and disabling the cache module solved the problem, there is any lost in performance for medium networks?(like 300 devices) 2016-11-11 11:59 GMT-02:00 <A.L.M.Buxey@lboro.ac.uk>:
Hi,
I enable the update blocks and works on the first time, but on second too, but in the thirt connection the reply VLAN is not present Process: Connect to wifi(works with vlan) disconnect and reconnect(Sometimes works) disconnect and reconnect again(don't work)
And looking in the radpostauth table i see some accept-accept replys with login without password :O
sounds to me like youve got caching turned on. in which case, the server will bypass several things and used the cached policy.
alan
Hi,
Disable the cache on eap module and disabling the cache module solved the problem, there is any lost in performance for medium networks?(like 300 devices)
loss of performance? yes - as you are not using the cache. if you care about that, then fix cnfig so its works with the cache (read docs, ensure required attributes and replies are being put into the cache and recalled when needed) alan
On 11/11/2016 11:23, Alan Buxey wrote:
# Instead of "use_tunneled_reply", uncomment the # next two "update" blocks. # # update { # &outer.session-state: += &reply: # }
Thanks for that. However I think the text higher up in the same file should be clarified, since it currently says: # If you need to send a reply attribute in the outer session, # the ONLY safe way is to set "use_tunneled_reply = yes", and # then update the inner-tunnel reply.
Hi,
My server is a Debian jessie fresh install with Freeradius 3.0.12(compiled from source, using defaults) and unifi controler 5.3.5(beta version, but i
you need to copy the contents of the post-auth from inner-tunnel to the outer reply for thew AP to see. HOWVERm, please dont do what you've read - thats for older version,s instead look at the virtual servers and read the comments regarding how to enable that feature properly on 3.0.12 - its subtly different, you need to uncomment both parts. the old method is deprecated...even the comments in the configs tell you this alan
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan Buxey
-
Alan DeKok -
Brian Candler -
Gabriel Ozaki