Disconnect User Network Access through Forti-Authenticator Usage profile

 

Goal:  Disconnect/Not to allow user network access after certain usage.

 

STEP 1:

Configure your Fortigate/NAS to send User Accounting information to Forti-Authenticator after successful user authentication. In this case Forti-Authenticator is  used as Authentication server as well.

#Sample Radius configuration on Fortigate :

config user radius

edit “10.47.1.148”

set server “10.47.1.148”

set secret ENC     zMbdF/mNYBr5a4Cc3cP

set nas-ip 192.168.242.80

set acct-interim-interval 600

set radius-coa enable

config accounting-server

edit 1

set status enable

set server “10.47.1.148”

set secret ENC   nGw/l5GCxHSymW3SnXGJKgmk

set port 1646

next

 

Note: Port 1646 is used for Accounting traffic on Fortigate and Forti-Authenticator.

Interim Acct and COA is enabled.

 

acct port

 

STEP 2:

Make sure to enable Accounting monitor on the FAC interface that will be talking to NAS/Fortigate.

2

 

STEP 3:

Enable to “Accept Accounting” on the radius client profile and support COA.

3.png

 

STEP 4 :

Usage profile for time or data is configured.

4

 

STEP 5 :

Usage profile can be applied to user/ user group /Device.

5

Remember to add the Radius Attribute  interim update set to 600 sec once.

 

STEP 6:

After successful authentication and Receiving Radius Accounting information you get to see the sample like below.

Navigation:  Monitor->Radius Accounting

accounting

STEP 7:

If FAC(Forti Authenticator) find the user crossed time/usage(data) limit , then it sends out a COA message to Fortigate and also disables the user at FAC.

10

 

STEP 8:

User session state at Fortigate 

==> User Session before Disconnect/bounce from network

Alza-kvm21 # diagnose firewall auth list | grep -A5 “test1”
10.120.0.125, test1, captive FAC user
src_mac: 00:0c:29:xx:xx:xx
type: fw, id: 0, duration: 547, idled: 64
expire: 236, allow-idle: 300
flag(30): radius idle
server: 10.47.8.250

 

==> User session after Disconnect/bounced from network.

Alza-kvm21 # diagnose firewall auth list | grep -A5 “test1”

Alza-kvm21 #

 

 

COA | Change Of Authorization

COA | Change of authorization
RFC 3576
UDP port 3766 | IEEE

>Change of authorization is used to ask NETWORK SWITCH/ROUTER/WIFI-CONTROLLER to disconnect-user, session timeout, bounce port of the existing user session on network.
>Mostly AAA server is user to record the user accounting information and based on the user activity or time the user is then disconnected from the network or session timed out.
>The Network device will send the accounting information to a AAA server.
>The AAA server keeps track of user information like Device MAC-ADDRESS, User SESSION-ID, USERNAME, FRAMED-IP-ADDRESS and more based on what it gets from accounting request.
>The radius accounting request traffic will be send only after a successful authentication.
>You could configure to send interim accounting update about the user to accounting server.This interim update can help in scenarios where you want to disconnect the user after usage of certain amount of bandwidth in network. Default time:300 Sec

#Things to remember while working on a COA setup:
>Make sure the network device is configured to accept the COA request from COA server on respected port.
>NAS devices wants to see particular attriutes in COA request to identify the user session and perform COA, So sending the right attributes on COA request is important and it depends on the NAS device vendor.
>The expected COA user identification attribute might be different for a Captive portal authenticated user and Dot1.x user.
>Some vendor ignote the unsupported or unknown attributes in COA request and still ACK your COA request. However some vendor devices dont like you sending a unsupported COA attributes, so they respond with disconnect-NAK
#Here in case of Fortigate Firewall you might need to send the right COA supported attribute to identify the user session.

*supported attributes: WPA-Enterprise&UserGroup and Captive Portal supports:
USER_NAME,
FRAMED_IP_ADDRESS,
EVENT_TIMESTAMP,
MESSAGE_AUTHENTICATOR,

*User-name” and “Frame-ip” were supported in DM request and both MUST be involved, other attributes like “Calling-Station-Id”, “Called-Station-Id” could not be supported and would cause 503 error message.
*The attributes “EVENT_TIMESTAMP” and “MESSAGE_AUTHENTICATOR” are options.
*Note: Supported attributes as on the latest firmware v5.4

#In case of ARUBA MOBILIY CONTROLLER:

The mobility controller supports the following attributes for identifying the users who authenticate with an RFC 3576 server:

* user-name: Name of the user to be authenticated.
* framed-ip-address: User’s IP address.
* calling-station-id: Phone number of a station that originated a call.
* accounting-session-id: Unique accounting ID for the user session

–> Other attribute might cause 503 error.

#Other ports to Remember:
*Radus Accounting request and Response is on UDP1813
*Radius Authentication is on UDP1812

#Some snapshots attached here to see what’s there inside Disconnect-request,Disconnect-,ACK,Disconnect-NAK.

Accounting Request:

radius-acc

Disconnect Request:

Disconnect-request

Disconnect-ACK:

Disconnect_Ack

Disconnect-NAK:

Disconnect_NAK

If would like to look at the entire pcap, let me know I can share with your guys.

 

BYOD fails because of those CNA agents on IOS and Android

I had this chance to work with an Australian Account for BYOD solution issue.

Deployment: Fortinet Infrastructure wifi solution with Forticonnect a Byod solution.

Issue: Windows devices are able to get on-boarded successfully but the Macintosh and android having issues.

Once i jumped onto troubleshoot this issue found the configuration seems to be totally fine. So is it a software bug?
What i get to find again is this tiny browser (CNA agent) on wifi clients which doesn’t have the full browser capacity is the cause of the issue.

Firstly , how a traditional BYOD solution works is users initially connect to a OPEN ssid and then they download a DOT1.X PROFILE and later using the profile user are on-boarded securely on the network.This can also be done using a single SSID also, It depends on how much your BYOD solution can assist you on this.

Coming back to my issue here, I say the user connected on the guest network and did authenticate to the CAPTIVE PORTAL/ BYOD. However this authentication success message was never passed back to the WLAN controller, So that WLC can initiate the RADIUS REQUEST to RADIUS SERVER.

>This is how a station log for problematic wifi client looks like.

2017-Jan- 9 13:14:27.306847 | 44:2a:60:fc:39:d4 | Station Assign | <AID=3>[abgn](v0) assigned to <AP=99> ESSID=e-smart-access A-BSSID=00:0c:e6:0a:39:ee Ch=149 reason=Station probed
station-log>
2017-Jan- 9 13:14:27.352095 | 44:2a:60:fc:39:d4 | Band Steering | <AID=0>[abgn](v0) Steering to 5Ghz under policy=A Blocking 2.4Ghz, present staType=ABGN ESSID=e-smart-access B-BSSID=00:0c:e6:0a:cb:1f Ch=11
station-log>
2017-Jan- 9 13:14:27.554238 | 44:2a:60:fc:39:d4 | 802.11 State | <AID=3>[abgn](v0) state change <old=Unauthenticated><new=Authenticated><AP[99]=00:0c:e6:13:27:a5> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:14:27.554248 | 44:2a:60:fc:39:d4 | 802.11 State | <AID=3>[abgn](v0) state change <old=Unauthenticated> <new=Authenticated> <AP=99> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:14:27.555616 | 44:2a:60:fc:39:d4 | 802.11 State | . <AID=3>[abgn](v0) state change <old=Authenticated><new=Associated><AP[99]=00:0c:e6:13:27:a5> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:14:27.555625 | 44:2a:60:fc:39:d4 | 802.11 State | . <AID=3>[abgn](v0) state change <old=Authenticated> <new=Associated> <AP=99> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:14:27.555993 | 44:2a:60:fc:39:d4 | Band Steering | * <AID=3>[abgn](v0) Steered to 5Ghz under policy=A staType=ABGN[15] ESSID=e-smart-access A-BSSID=00:0c:e6:0a:39:ee Ch=149 Steering time = 0.203891 seconds
station-log>
2017-Jan- 9 13:14:27.563019 | 44:2a:60:fc:39:d4 | DHCP | <msg_type=REQUEST><server_ip=127.0.0.1><client_ip=0.0.0.0>
station-log>
2017-Jan- 9 13:14:27.572135 | 44:2a:60:fc:39:d4 | DHCP | <msg_type=ACK><server_ip=127.0.0.1><offered_ip=10.12.1.135>
station-log>
2017-Jan- 9 13:14:28.573801 | 44:2a:60:fc:39:d4 | IP Address Discovered | <Old IP discovery Method=none><Old IP=0.0.0.0><New IP discovery Method=dynamic><New IP=10.12.1.135

While if you want to compare how a successful CP authentication looks like on contrast:

2017-Jan- 9 13:50:53.401458 | 44:2a:60:fc:39:d4 | Station Assign | <AID=3>[abgn](v0) assigned to <AP=99> ESSID=e-smart-access A-BSSID=00:0c:e6:0a:39:ee Ch=149 reason=RSSI changed
station-log>
2017-Jan- 9 13:50:55.921525 | 44:2a:60:fc:39:d4 | Station Assign | <AID=3>[abgn](v0) removed from <AP=99> ESSID=e-smart-access A-BSSID=00:0c:e6:0a:39:ee Ch=149 reason=Inactivity timer expired
station-log>
2017-Jan- 9 13:52:33.440124 | 44:2a:60:fc:39:d4 | Station Assign | <AID=2>[abgn](v0) assigned to <AP=99> ESSID=e-smart-access A-BSSID=00:0c:e6:0a:39:ee Ch=149 reason=Station probed
station-log>
2017-Jan- 9 13:52:33.440941 | 44:2a:60:fc:39:d4 | 802.11 State | <AID=2>[abgn](v0) state change <old=Unauthenticated><new=Authenticated><AP[99]=00:0c:e6:13:27:a5> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:52:33.440950 | 44:2a:60:fc:39:d4 | 802.11 State | <AID=2>[abgn](v0) state change <old=Unauthenticated> <new=Authenticated> <AP=99> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:52:33.441122 | 44:2a:60:fc:39:d4 | 802.11 State | . <AID=2>[abgn](v0) state change <old=Authenticated><new=Authenticated><AP[99]=00:0c:e6:13:27:a5> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:52:33.441131 | 44:2a:60:fc:39:d4 | 802.11 State | . <AID=2>[abgn](v0) state change <old=Authenticated> <new=Authenticated> <AP=99> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:52:33.441549 | 44:2a:60:fc:39:d4 | 802.11 State | . <AID=2>[abgn](v0) state change <old=Authenticated><new=Associated><AP[99]=00:0c:e6:13:27:a5> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:52:33.441558 | 44:2a:60:fc:39:d4 | 802.11 State | . <AID=2>[abgn](v0) state change <old=Authenticated> <new=Associated> <AP=99> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:52:33.442632 | 44:2a:60:fc:39:d4 | Band Steering | * <AID=2>[abgn](v0) Self-steered to 5Ghz under policy = A staType = ABGN ESSID=e-smart-access A-BSSID=00:0c:e6:0a:39:ee Ch=149 Steering time = 0
station-log>
2017-Jan- 9 13:52:33.448274 | 44:2a:60:fc:39:d4 | DHCP | <msg_type=REQUEST><server_ip=127.0.0.1><client_ip=0.0.0.0>
station-log>
2017-Jan- 9 13:52:33.454929 | 44:2a:60:fc:39:d4 | DHCP | <msg_type=ACK><server_ip=127.0.0.1><offered_ip=10.12.1.135>
station-log>
2017-Jan- 9 13:52:34.507002 | 44:2a:60:fc:39:d4 | IP Address Discovered | <Old IP discovery Method=none><Old IP=0.0.0.0><New IP discovery Method=dynamic><New IP=10.12.1.135>
station-log>
station-log>
station-log>
station-log>
2017-Jan- 9 13:53:54.616485 | 44:2a:60:fc:39:d4 | CP User Authentication | <Captive Portal Profile= captive-portal> <User : chewc@xxxx.edu.au> <ipaddr=10.12.1.135> Sending User Authentication Request.
station-log>
2017-Jan- 9 13:53:54.616487 | 44:2a:60:fc:39:d4 | CP User Authentication | <User=chewc@XXXX.edu.au> <ipaddr=10.12.1.135> Sent Guest User Authentication Request.
station-log>
2017-Jan- 9 13:53:54.616626 | 44:2a:60:fc:39:d4 | CP User Authentication | <User=chewc@XXXX.edu.au> <ipaddr=10.12.1.135> Sent Radius Authentication Request.
station-log>
2017-Jan- 9 13:53:54.678054 | 44:2a:60:fc:39:d4 | CP User Authentication | <User=chewc@XXXX.edu.au> <ipaddr=10.12.1.135> Radius User Authenticated Successfully <session_time=0 secs> <filter_id=> <idle_time=0 secs>
station-log>
>You would see on the above successful station log that the client has forwarded the WiFi Auth credentials back to the WLAN controller (4th line from the last) and so Radius Auth session can now be initiated to RADIUS Server(last 3 lines)
Note:This is very important for the controller to know that the users is authenticated and so later when ANDROID user going to google play store or when an IOS user going to Apple store the controller lets the traffic go out. Since captive portal SSID always allows only ARP, DNS, DHCP traffic of client before authentication success. And in few other vendors you still need to allow the client subnet to access google play store and apple store.

>Else you would run into issues such that the wifi clients are not able to download the application(smart connect) from APP STORE that assists the device to download dot1.x profile from BYOD server.

Solution: After we just disabling the CNA agent(tiny browser) the wifi clients have no problem in onbording to a dot1.x network. We forced the client not to use the CNA AGENT by using the feature in WiFi controller.

>There are some parameter (SSID+CLIENT_MACADDRESS+SWITCHIP:PORT+BROWSERINFO+some other)on the fly(During onboard) the browser  remember till it POST the credential back to controller for radius authentication.

>Since those tiny browsers are  not capable to do this, Some times you have hard time to Successfully design BYOD Onboard.