Joining Forti-Authenticator into your domain

You could join Forti-Authenticator into a Domain.  In-order to perform authentications like MSCHAP against LDAP Server , where you have passwords  stored in encrypted way  requires you to join Radius server onto that domain.

Scenarios where FAC acting as your radius server for a 802.1.x client and user password is stored on Windows Active directory, would require FAC to join the respected domain to perform the authentication for NAS devices(radius client).

Below configuration and monitor option helps you to confirm the Domain Join function with your FAC:

Once you get to add your LDAP server under FAC successfully,  you should be able to now browser the LDAP users and attributes now. Make sure the LDAP-SERVICE-ACCOUNT used have enough permission to read users and needed attributes and also able to join the domain.


Once after adding the LDAP server into FAC, You may now to enable “windows Active Directory Domain Authentication”  Will required the following information to join domain;

Kerberos realm name:

Domain NetBIOS name:

FAC NetBIOS name

Domain Administrator service account to join the respected domain

<Attached picture for reference>



Once after Successful configuring, you can check to monitor under Monitor tab > will show “joined domain” successfully.


On the other hand from the logging section, you will see if the join was successful or failed. If its failing then it will be mostly because of any domain join parameter you configured is incorrect.


Finally, now you could apply the settings on radius client settings/profile to perform “Windows Domain Authentication ” <screenshot for reference>




Captive portal Tricks & Tweaks on Fortigate Firewall

You can configure your Fortigate Firewall with Captive Portal user based authentication for both wired and wireless user traffic. There are few places in fortigate firewall you could control the settings.

#Fortigate captive portal:

To disable HTTP access based captive portal redirection & Enable Secure HTTP

config user settings
Auth-secure-http : Enable
(Or) for HTTP only redirection

To avoid certificate pining problems or HSTS(HTTP Strict-Transport-Security) based browser warnings and when Websites being strict for man-in-the-middle for enabling captive portals.

config user settings
Auth-secure-http : disable
NOTE: Fortigate uses port 1000 for HTTP and port 1003 for HTTPS based redirection.
These settings can be custom changed to one you would like to.

config system global
set auth-https-port xxxx (default = 1003)
#To redirect with FQDN & not IP address:

To redirect captive portal with DNS based which helps to mask the IP address on the captive portal redirection process.
config firewall auth-portal
portal-addr :

# Since you decided to do the Captive portal over HTTPS and with FQDN, you will need to have Trusted secure certificate in fortigate for CP redirection and Authentication.

config user setting
set auth-cert <auth-cert>
set auth-ca-cert <auth-ca-cert>

auth-cert -> Actual cert
auth-ca-cert -> Root CA signed your captive portal Certificate.
# If you want to enable captive portal on the LAN interface for the user traffic.
edit “port12_lan”

set vdom “Praveen_NAT”

set ip

set allowaccess ping https ssh snmp http

set security-mode captive-portal

#Enable Captive Portal at firewall policy level

You may also enable captive portal parameter’s from the firewall policy level on fortigate. These items on firewall policy level will override the global parameters under “config user setting”
This will help to manage different portal redirection and certificates for multiple clients.
#config firewall policy
edit <my_policy_ID>
set auth-redirect-addr “”

#config firewall policy
edit <my_policy_ID>
set auth-cert <auth-cert>

#config firewall policy
edit <my_policy_ID>
set disclaimer enable
set redirect-url “;
Note: If you set the USER GROUP for the “security-mode =captive portal” user will land on the login portal page asking for USERNAME/PASSWORD. And if you don’t set any
“allow all ” will be set and user will be provided with disclaimer page.

#Wireless interface/SSID (Tunnel mode) default have Email collection as a authorization service and to allow secure access.

config wireless-controller vap
edit Guest_Access
set security captive-portal
set portal-type email-collect

And if you want to enable Email collection on the Wired Interface you might have to customize the default landing page to perform so. In-order to do that you might need some experience in code editing on the default page , so it could automate the email collection seamlessly and to authenticate and authorize the user access.
#If you want to exempt Captive portal redirection for certain “users/devices” then you may exempt to create a firewall policy for them.

config firewall policy
edit <id>
set captive-portal-exempt enable
#Customizing Captive portal pages:

This section helps you customize the default fortinet provided templates to your company policy and banner/logo.


#Replacement message groups


You have settings called “replacement Message Group” which allows to use customized replacement message for individual policy and profile.


If you want this feature visible on GUI:

config system settings

set gui-replacement-message-groups enable



To Edit from CLI:

config system replacemsg-group

edit <group>

set group-type {auth | utm}

config <message_category>

edit <message_type>

set buffer <message>

set header {none | http | 8bit}

set format {none | text | html}






To Apply at firewall policy level:

config firewall policy


set replacemsg-override-group “name”

set inspection-mode proxy


#Force Disclaimer page on a firewall policy whose SRC INTERFACE already have another Firewall policy to ALLOW ALL traffic.

In above condition even though you have the disclaimer policy on top of the Allow all policy the traffic from the user for whom you have created the disclaimer page would still hit the Allow ALL policy only.

Reason: Disclaimer page is not like User authentication captive portal page.

Prompting for User authentication is automatic, When the traffic is matched against the policy table, if it falls all the way through AND there is some authentication policies, then it will prompt the authentication automatically.

**Disclaimer is a special type of user auth. It’s like a hidden group called “accepted disclaimer users”.

** Therefore, in your policies[For Example when policy 1 and policy 2 is Active], what’s happening is:
— first packet, it will NOT hit the first policy because the user has never accepted the disclaimer before(and thus never been authenticated under the ‘accepted disclaimer users’ group).
— the packet WILL match the 2nd policy because it matches the entire interface.

Firewall Policies for example:

edit 1

set srcintf “Guest”
set dstintf “Internet”
set srcaddr “test-guest-user”
set dstaddr “all”
set action accept
set schedule “always”
set service “ALL”
set logtraffic all
set fsso disable
set groups “Group-Wifi”
set disclaimer enable
set auth-cert “wildcard cert”
set auth-redirect-addr “”
set nat enable

edit 2
set uuid 9a14bfdc-34c2-51e9-b6c4-af2e5582216d
set srcintf “Guest”
set dstintf “Internet”
set srcaddr “all”
set dstaddr “all”
set action accept
set schedule “always”
set service “ALL”
set utm-status enable
set nat enable

> So what you have to do as a workaround on firewall policy 2 is:

edit 2
set uuid 9a14bfdc-34c2-51e9-b6c4-af2e5582216d
set srcintf “Guest”
set dstintf “Internet”
set srcaddr “test-guest”     —–>
set srcaddr-negate enable —->  This will force the “test-guest to go through policy 1
set dstaddr “all”
set action accept
set schedule “always”
set service “ALL”
set utm-status enable
set nat enable



Disconnect User Network Access through Forti-Authenticator Usage profile


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



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 “”

set server “”

set secret ENC     zMbdF/mNYBr5a4Cc3cP

set nas-ip

set acct-interim-interval 600

set radius-coa enable

config accounting-server

edit 1

set status enable

set server “”

set secret ENC   nGw/l5GCxHSymW3SnXGJKgmk

set port 1646



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

Interim Acct and COA is enabled.


acct port



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




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



STEP 4 :

Usage profile for time or data is configured.



STEP 5 :

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


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



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

Navigation:  Monitor->Radius Accounting



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.




User session state at Fortigate 

==> User Session before Disconnect/bounce from network

Alza-kvm21 # diagnose firewall auth list | grep -A5 “test1”, 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


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

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

Alza-kvm21 #



SMS Token Based Captive Portal Authentication with Forti Authenticator

Forti Authenticator is a Identity and Access Management system and very efficient when it comes for client Access Control Management. In this Blog post you will see how can you use the captive portal function on FAC for SMS Based Token Authentication. We integrate the FAC with Fortigate Firewall being NAS.

Token Authentication can be done using Hardware(Forti Hardware Token) or Soft Token(Fortinet Token Mobile) too. In this case we use SMS Gateway to deliver the token for users over SMS. I believe this could come effective for a Wireless Guest user Authentication with Token Code.


Step1:  Creating  wireless interface/ SSID and set the captive portal redirection URL to external portal landing page at Forti-Authenticator



Step2: You need to configure a Radius Server on fortigate Firewall for back end Authentication with Forti Authenticator.



Step3: On the fortigate Firewall you need to make sure HTTP or HTTPS/DNS allowed for the Guest user’s traffic to get successfully redirected to  captive portal page.



Step4: Now on the Forti-Authenticator you could configure the social login page with Guest account settings.

4.1 You need to enable Social Login page first.

4.2 You could then select the User Group to be placed for all the users through this portal.

4.3 Set  the Account expiration Hour for your Users

4.4 If you have multiple SMS Gateway Service then choose the one which you would like to be used. In this example, i have used Fortiguard Messaging service(Need to purchase the license)

Note: If you like to Give other Social Login access on the same page then you could enable FACEBOOK LOGIN , GOOGLE LOGIN etc. However you may need to configure the respected login key and secret setting for them to work.




Step 5.Setup your Radius client settings, in this case it will be your fortigate firewall.  You must use the same Shared Secret key you configured on “step-2” at fortigate firewall.

5.1 Enable  Social login portal  under radius client settings.



Step 6. After a successful user authentication you will see the user information captured as social login user.


7. You will get to see the following user Event on the Fortigate for the successful user login with Token.


8. Further on the FAC side you may be able to see the following user Events under logging and log access.



Hope the following blog post is helpful in setting up your FAC for SMS based Token Authentication.

Setting up Fortinet Remote VPN AP

FortiRU Wireless controllers support remote AP setup mostly from SD6.0 Onwords. You will have a remote AP configured at your small office/remote office or home that can be managed/Provisioned by WLC  sitting at Data Center. In this case the data communication between controller and AP goes over the internet which is secure by open VPN encryption.

Configuring VPN AP:

First step, is to install a SSL Certificate for WLC controller (VPN server certificate) to manage and authenticate the remote APs.

+Before Processing to import the signed SSL certificate for controller first install the trusted CA certificates.



+Similarly import all subordinate CA certificates(if any sub CA’s).


Create a certificate Signing request(csr) for Controller:

+Login to Controller, Go to Configuration ->Security-> Certificates -> Controller Certificates.


+Click on Add button (You can see a Certificate Add Popup), Fill in the Input Fields and click on Save.

+User can View CSR (select the radio button against the Pending CSR) and then Click View button or export the CSR by clicking Export Button

+Once the CSR is created, User can see Entry Created (showing the Type as Pending-CSR)

+Select the radio button against the Pending CSR, then click on Import Certificate Button



+User can see the Certificate Alias name, issued to, Issued By etc.




Step Two, Configuring Remote VPN AP and assigning a certificate for the VPN client.

i. Login to Controller, Go to Configuration -> Certificates -> AP Certificates and List of AP’s will be displayed, Make sure that the AP for which you are installing is Enabled and its Online.


ii. Select the radio button against the AP, then click on Create CSR Button
iii. A Create Signing Request – AP Certificate Popup will Appear
iv. Enter the Validity (in days) and then click Apply.


v. Click the Refresh Button, Once on Refresh, user can see CSR-Generation-in-Progress under User Req status.


vii. User can View CSR (select the radio button against the AP) and the Click View button or export the CSR by clicking Export Button


viii. Give the CSR File or the Contents to the CSR to the admin to get the Certificate and the CA Certificate
ix. Incase if the Certificates is issued by a different CA server, First install the CA Certificate as mentioned in “Trusted CA install section at the beginning .”.
x. Import the Certificate for the AP, by selecting the radio button against the AP and by clicking Import Button



xi. Once the Certificate is copied, user can see a message “Cert-Installation-In-Progress ” under user Req Status

xii. Once the Certificate is Installed, user can see “Cert-Installed” message under User Req Status


NOTE: AP must be on L3 connection(must assign IP)


Assigning the server certificate for the VPN server:

i. Login to Controller, Go to Configuration -> Certificates -> Controller Certificates
ii. Click on Application Button, A Popup will appear, select the certificate next to VPN Application and click save.


iii. A popup message will be displayed asking user to run reload-vpn command from CLI ( On running reload-vpn, selected certificate will be used by VPN Server) Forti-Ru gives this option to user, because if already all AP’s are connected using VPN, running reload-vpn will cause all VPN AP’s to reboot, Hence when there are no stations, the user can run reload-vpn.


Creating a VPN SERVER on Controller:

I. Login to Controller, Go to Configuration -> Security -> VPN Server
ii. Fill in VPN Server/IP Name, it should be Controller’s Publicly reachable IP address or the hostname (FQDN), also fill the port, default will be 1194, IP pool and subnet needs to be added.

vpn server


Finally, Adding the AP to VPN Group:

i. Login to Controller, Go to Configuration -> security -> VPN server -> VPN AP’s

ii. Select the AP’s that you want to add to the VPN Group and Click on next


iii. See the Column below Action required, if the status is “No Action Required“, Click activate, if there is any pending action, User need to finish the pending action before activating.


iv. Once User clicks Activate, Initially the VPN connectivity status will be disconnected, AP will go for reboot

v. Once the AP comes back, AP will connect back to controller in VPN mode and user can see the status as Connected under VPN Connectivity Status.



Troubleshooting command:

Controller level:

default(15)# show vpn-ap

default(15)# show vpn-server

default(15)# show vpn-ap <id>

default(15)# show ap-certificate <id>

default(15)# capture-packets -R ip.addr==x.x.x.x

+Run Capture packets command with filter as AP’s Real IP address, the communication between controller and AP should happen only on VPN port (in this case UDP port 1194)


AP Level:

ap 8> ip vpn show

Chromcast SSDP and mDNS Service Control on Fortinet Wireless Controllers

Service control feature on FortiRu Controller’s been there for quite some time now. This has been very effective in managing the mDNS traffic on wireless side. Once you enable this feature on the Wireless controller you could manage the mDNS traffic flow across VLANS and ESSIDS by creating Service control policy.

This works well for mDNS traffic control for Airprint ,Airplay, etc. There are some limitation in case of chromecast multicast traffic management when it comes managing SSDP traffic.

FortiRU controller don’t support SSDP service control across multiple VLANs from day one. While still this can work between ESSIDs within VLAN.

Reason, In your FortiRU controller’s :

                           SSDP forwarding happens on data path
                           mDNS forwarding happens on user space.

Since SSDP traffic doesn’t hit the user space the Service control policy don’t get applied.

A real world condition:  If you try use your Windows computer with chromecast you mostly will notice mDNS traffic used for discovery and mirroring. While on a iPad running YouTube application and you try to mirror that application you will see SSDP application used for discovery. So, this very well depends on Device/Application using SSDP ( udp dst port 1900) for discovery.

Following a Feature request, now from SD 8.4 General release onward it will be supported.


By default, on  FortiRU OS you will have apple service types available for service control while for chromecast you might need to create your own service types(FortiRu OS might be missing what exactly you want).

#Configuration on WLC controller is straight forward::

1.Enable service control

enable service control

2.Confirm that your interested service types are available on your WLC controller for service control

service type

3.SC-AP Group creation

sc ap group

4. Publisher and subscriber User Group creation.

user group

5. Finally Policy creation:


To debug Service control issue on WLC-Controller:

FortiMeruXXX(15)# sup-cli
FortiMeruXXX] tr ServiceMgr ffffffff

FortiMeruXXX] trace on (turn on the trace)

Once the issue is captured turn it OFF.

FortiMeruXXX] trace off (turn OFF the trace)

To debug on AP side:

AP level : (check the client connected AP and run the trace on the AP)

Conn ap  

ap X> trace on 
Real-time trace display enabled for severity >= 0. 

Once the issue is captured turn it OFF. 

ap X> trace off 
Real-time trace display disabled. 


Wi-Fi Now Conference Bangkok-2017

I recently got chance to attend the Wi-Fi Now conference held at Bangkok this year. Met some wonderful people in WiFi community.

Got engaged on discussion with latest WiFi deployments and its success stories.

How to meet customer demands with right solutions available in the market. Vendors gave some insight on how they are meeting customer demands already and what they can offer to meet the customer requirements and some Proof of success from POCs and production network.


At the same day, met some of my favorite wi-fi peers.


I was given a demo on iBWAVE WiFi Design Tool by  Sunder Arumugam and Swee Leong Sim

#My favorite features on  iBWAVE :

Advanced 3D modeling of the venue
Cable routing and costing
Complete bill of materials reporting
project proposal generation
Automatic link budget calculations


#Ekahau Folks

Met Brandon Biggs and Mark Winter from inTechnology Distribution

I was given a Demo on New Sidekick Tool and had some discussed on Single Channel planning with Ekahau Wi-Fi design Tool.


#Wi-FI Now CEO and chairman | Claus Hetting

Got chance to have a short conversation regarding the conference.


# CWNE and Board of Advisor | Ronald van Kleunen

I was able to catch-up with Ronald at Bangkok





Wi-Fi Roaming on a Fortinet Single Channel Architecture(SCA)

Successful Wi-Fi client Roaming is moving across Access point / BSSID  to a best possible service AP for the wireless client in term’s of SNR and RSSI while with least time involved in the process and with zero Hard hand off seen.

Faster Roaming is considered key for VoIP over Wi-Fi and for other application that is running over Wi-Fi Network which is very sensitive for latency and delay.

Wireless Vendor’s do have protocol implementations to deal these roaming problems with : PMK caching, OKC, FAST ROAMING 802.11 K/V/R

However Fortinet Infrastructure Wi-Fi being unique with single BSSID virtually visible across the network and roaming seems to be quite simple, but they still have to calculate the math to solve the roaming issue with their software.

I want to stress on this point: Yes, FortiWLC does  support both Single channel Architecture and Multi channel Architecture mode and you can take advantage of this with the help of feature grouping. So you can deploy sites some with single channel and other sites which you feel from Design point that it’s optimal to go with Multi channel architecture. So take some advantage of the SCA where it can really go well for you.

Ok, So how does SCA works together for client roaming?

Like other MCA vendors Fortinet Wi-Fi system also has the following tweaks and operations that will help you to build a system optimal for Good roaming (choice of which parameter really depends on wi-fi environment).

*Prob response threshold(This is based on SNR)

*Lower data rate changes

*TX power changes.

*Prob response from associated AP only.

*AP load balancing

*Frequency Band-steering

Apart from the settings mentioned above there are some  major factors that contribute SCA roaming :  

*Adequate RSSI




2 frame report with 3 dbm difference on RSSI strength   [ This is Interval between each frame report and its RSSI difference]

Coordinator  [wi-fi system which takes in-charge of  AP<->CLIENT association and here coordinator gives client assignment to the best access point to service the client based on the condition and threshold set]

coordinator reassignment and AP acknowledgment for that assignment.

silent client behavior and WLC features to handle such client behaviors.

Below are some client roaming behavior on different roaming condition.

#Normal system hand off based on adequate rssi(better signal strength).

2017-Sep-29 14:51:56.611901 | 78:31:c1:Xx:Xx:XX | 802.11 State | * <AID=31>[abgn](v0) handoff <OLD_AP=6> RSSI (-56 -55) <NEW_AP=13> RSSI (-52 -43) ESSID=XXXXX Ch=149 A-BSSID=00:0c:e6:02:67:70 reason=Normal handoff

#System Hand off based on  -256  frame report:

This condition of seeing -256 frame report and followed by normal handoff means that the station is found on different service AP while before the last serviced AP could flag the client as LOST.

station-log> 2017-Sep-29 15:44:55.069959 | 78:31:c1:XX:XX:XX | 802.11 State | * <AID=31>[abgn](v0) handoff <OLD_AP=13> RSSI (-256 -256) <NEW_AP=6> RSSI (-55 -55) ESSID=XXXX Ch=149 A-BSSID=00:0c:e6:02:67:70 reason=Normal handoff

#System LOST-FOUND on same Access point(-256):

When the wireless client is marked LOST on the connected Access point and not found on any other servicing Access point. And the client shows up(FOUND) again on the same access point after been marked as LOST.

–>Sample Station log:

If no other UNASSIGNED AP have marked it QUASI FOUND
01:40:30.503000 | 7c:7a:91:XX:XX:XX | 802.11 State | <AID=6>[abgn](pre lost) found on assigned <AP=97>(rssi=-256) ESSID=XXXX Ch=44 A-BSSID=00:0c:e6:5a:1b:44 reason=Station discovered

#System Hand off based on LOST-FOUND(station is declared as LOST but found on different servicing AP)

Here station is completely lost on the connected AP, while it probed on a different Access point resulting on a hand off.

–>Sample station log :

2017-Sep-29 15:44:53.507727 | 78:31:c1:XX:XX:XX| 802.11 State | * <AID=31>[abgn](v0) (pre found) lost from assigned <AP=13> ESSID=XXXX Ch=149 A-BSSID=00:0c:e6:02:67:70 reason=Station lost from AP
station-log> 2017-Sep-29 15:44:55.069956 | 78:31:c1:XX:XX:XX | 802.11 State | * <AID=31>[abgn](v0) (pre lost) quasi found on unassigned <AP=6>(rssi=-55) ESSID=XXXX Ch=149 A-BSSID=00:0c:e6:02:67:70 reason=Station probed
station-log> 2017-Sep-29 15:44:55.069959 | 78:31:c1:XX:XX:XX | 802.11 State | * <AID=31>[abgn](v0) handoff <OLD_AP=13> RSSI (-256 -256) <NEW_AP=6> RSSI (-55 -55) ESSID=XXXX Ch=149 A-BSSID=00:0c:e6:02:67:70 reason=Normal handoff


->>The below log indicates that the station is now handed-off to new access point and the access point ack’ed the “coordinator” that he is going to take over the client service.
station-log> 2017-Sep-29 15:44:55.070826 | 78:31:c1:XX:XX:XX | 802.11 State | * <AID=31>[abgn](v0) (pre quasi found) marked found as received handoff ack from assigned <AP=6> ESSID=wireless-nation Ch=149 A-BSSID=00:0c:e6:02:67:70


#Wireless Client Assoc-Assoc .

This is a problem condition in SCA where the wi-fi station does a re-association to the access point but to the wireless system already know him as a associated client in his DB.

The client does this thinking  it needs a re-association to the wireless network because he hasn’t heard any beacon for some time interval or could be because beacons are found to be corrupted while decoding or client didn’t like the frames sent by Access point(Have seen such behavior mostly with INTEL chip-set based clients). This needs a investigation if these log show up on system and matches the time frame user reporting any connectivity issues.

This  condition could cause client going through authentications phase again and/or even disconnections (8021.x and 802.11i  happens every time when hits Assoc to Assoc)

–>Sample events for Assoc-Assoc situation:
station-log> 2017-Sep-29 15:44:59.257873 | 78:31:c1:XX:XX:XX | 802.11 State | * <AID=31>[abgn](v0) state change <old=Associated><new=Associated><AP[6]=00:0c:e6:1a:34:11> ESSID=XXXX Ch=149 A-<BSSID=00:0c:e6:02:67:70>
station-log> 2017-Sep-29 15:44:59.257877 | 78:31:c1:XX:XX:XX | 802.11 State | * <AID=31>[abgn](v0) state change <old=Associated> <new=Associated> <AP=6> ESSID=XXXX Ch=149 A-<BSSID=00:0c:e6:02:67:70>
station-log> 2017-Sep-29 15:44:59.258432 | 78:31:c1:XX:XX:XX | 1X Authentication | <AID=0> <EAP code=request> <EAP ID=1> <EAP type=Identity> sent
station-log> 2017-Sep-29 15:44:59.290511 | 78:31:c1:XX:XX:XX | 1X Authentication | <AID=31> <pkt type=EAP_PACKET> <EAP code=response><EAP ID=1>
station-log> 2017-Sep-29 15:44:59.290514 | 78:31:c1:XX:XX:XX | 1X Authentication | <AID=31> Radius <msg code=access_request><msg ID=174> sent <ip=>:<port=1812>
station-log> 2017-Sep-29 15:44:59.299477 | 78:31:c1:XX:XX:XX | 1X Authentication | <AID=31> <pkt type=EAP_PACKET> <EAP code=request><EAP ID=2> <info=relay eap-request from Radius> sent

station-log> 2017-Sep-29 15:44:59.572152 | 78:31:c1:XX:XX:XX | 1X Authentication | <AID=31> <pkt type=EAP_PACKET> <EAP code=response><EAP ID=9>
station-log> 2017-Sep-29 15:44:59.572156 | 78:31:c1:XX:XX:XX | 1X Authentication |
station-log> 2017-Sep-29 15:44:59.645547 | 78:31:c1:XX:XX:XX | 1X Authentication | <AID=31> <pkt type=EAP_PACKET> <EAP code=response><EAP ID=12>
station-log> 2017-Sep-29 15:44:59.646297 | 78:31:c1:XX:XX:XX | 1X Authentication | <AID=31> Radius <msg code=access_request><msg ID=189> sent <ip=>:<port=1812>
station-log> 2017-Sep-29 15:44:59.647948 | 78:31:c1:XX:XX:XX | 1X Authentication | <AID=31> Radius ACCESS-ACCEPT received : Session Timeout: None, VLAN Tag : 0, Filter id : , CUI : None.


How does Fortinet SCA Wi-Fi Network manages Silent Client issues

Small Wi-Fi devices, Bar-code scanners and other IOT devices does go for doze state very often to save power. Every Wi-Fi vendor will have some kind of implementations to get attention of those Wi-Fi Client that tend to go silent often.

Traditionally Meru Wi-Fi system have a feature called CLIENT LOCATOR. While after adding the client devices MAC-OUI on the WI-FI System it keeps sending ICMP request and gets an ICMP reply  from those silent clients, by this way the clients connection is kept active. Also Wi-Fi system sends out Qos Null frame in earlier days for those Silent clients.

Now in recent Fortinet Infrastructure based AP models there are certain client upstream and downstream silent client feature implemented.


For Active Clients (If Wi-Fi client hasn’t informed about going for a power save but remains silent):


> If the client is silent for more than 2 seconds, silent client polling kicks in from AP every  2 seconds.

                                              AP                                                                             STA
                                                           No upstream packet from STA
                                                              (Start RTS mechanism)
                                                                                                                  <-  CTS



> Consider, if no reply from the silent client then the AP tried to send the RTS for 8 – 30 seconds and gives up. Then the AP will update the “coordinator” about the client is been lost now.

station log will look like this:

| 802.11 State | * <AID=31>[abgn](v0) (pre found) lost from assigned <AP=13> ESSID=***** Ch=149 A-BSSID=***** reason=Station lost from AP

>So, Once station is declared lost, TIM bit is enabled in the beacon.

>And if station is back on network, then a found notification will be send. If not found then the system will run the station ideal time out for 33 min(default) and will send out a De-auth.


                                       AP                                                                                    STA
                                                    No upstream packet from STA
                                             RTS 1–>
                                             RTS 2–>
                                            RTS 8–>
                                                                   Station lost message
                                            TIM bit set in Beacon–>
                                                              After 33minutes TIM bit cleared


Power Save Clients (Client informed going for power save)


>Again if client is silent for 2 sec, silent client polling kicks in from AP every 2 sec.

> Silent client polling starts by AP setting TIM vector in beacons.

> However, TIM bit is still set in the beacons for 33 minutes and if no response from client then  later TIM bit is reset and De-auth will be sent out.

                                              AP                                                                              STA
                                                                 No upstream packet from STA
                                                    Beacon (TIM bit set)–>


                                                                           (After 33minutes)
                                                   Beacon (TIM bit reset)–>

>Silent client polling starts by AP setting TIM vector in beacons and stations sends PS-   POLL frame to AP, AP in turn sends QOS NULL data.

                                              AP                                                                               STA
                                                                 No upstream packet from STA
                                                       Beacon (TIM bit set)–>
                                                       QOS Null Data–>

The default  silent_client.frame_fail_threshold varies from “8 – 30” depending on the Firmware version on the system and this can be changed with the help of AP Boot script. However, before any changes i would advise you to get some tips from Experts.



My Troubleshooting experience with 802.11 Beacon Frames.

Wireless Frame Analysis involve understanding what to look for in the 802.11 packet. Here lets look at “Beacon” Wi-Fi Management frames and those Interesting packet fields that can come handy while you troubleshoot client connectivity and performance issues caused by beacon frames.

802.11 management frames enable stations to establish and maintain communications.

The following are common 802.11 management frame subtypes:


#Beacon Frame:

The access point periodically sends a beacon frame to announce its presence and relay information, such as timestamp, SSID, and other parameters regarding the access point to radio NICs that are within range. Radio NICs continually scan all 802.11 radio channels and listen to beacons as the basis for choosing which access point is best to associate with.



The  Beacon frame has some information that we could glance through.

Section 1 : Physical Header of a Beacon: The radio tap header information are basically pseudo-header to supply additional info from driver to userspace.

And I use wire-shark to decode the packets for analysis and sometime it also depends on how best the software decodes the Wi-Fi packets for analysis. Rarely you might get to see some issues on the protocol analyzers that fail to decode the information right. we might need to double confirm with another (It just happens in corner cases)

The following are few information we have in physical header

*The signal strength

*channel (frequency)

*data rate of the packet

Section 2 : MAC Header and Frame Control of a beacon frame

Following information’s are available in  MAC-LAYER.

*Type of fame

*sub-frame type

*Frame control Flags

*Source address of the frame

*Destination address of the frame : FF:FF:FF:FF:FF:FF(Broadcast)


Section 3: Beacon Frame Body

Following information’s are available in  frame body of Beacon frame.

*Beacon Interval

*capability information: Support for APSD, BLOCK-ACK

*SSID parameter

*Supported rates

*Country Information

*RSN Information

*HT Capability

*Vendor Specific attributes

Wi-Fi troubleshooting with Beacon Frame:

1.)Beacon Miss : I have experienced issues where client missing to hear the beacons would cause them go for repeated frequency scanning and re-association request or disconnections. Some clients are so sensitive that missing 3 or 4 beacons will cause a disconnection and few other survive till 7 too.

You might need to analyse the AIR traffic to see if AP sending out beacons at regular interval or if the beacons getting corrupted in Air or if client receives a corrupted frames.

In such cases try to plot a IO graph in your Wireshark application and/or enable the column DELTA TIME  in Wireshark, which ever is your choice or if both. I prefer to use IO output(this can be further more customized during the Tshoot). NOTE: Getting the exact/close enough problem time frame is key thing.

IO Graph:

The Below sample graph shows you the total traffic on AIR captured VS Beacon (IN RED)send out by AP for a given time.


Y-axis represents number of packets and X-axis shows with respect to the time interval.

Default beacon interval time on most vendors are usually every 0.1024 second.

2.)Wifi signal strength identifier: If you get to sniff the traffic staying as close as possible to the client machine , you get to see how well the client can hear the SSID(signal strength). [ considering comparing receiving sensitivity of the sniffing adapter and client NIC ]. Then by Looking at the signal strength parameter you can tell if the client is connected to far away access point or having week signal.

This will help mostly to isolate issues such as network coverage holes especially for engineers who is validating the network from remote.

3.)Date rate: Looking at the rate Beacon is sent out, you can tell if lower data rate has been disabled or not. Since Beacons always sent out @ lowest rate (base rate) configured on the Essid. Also the supported rate parameter in the frame body gives you information at the lowest rate the data packet(QoS data) will be send.

4.) BSSID parameter on the Beacon will tell you which AP the beacon belong to. So you get to know how far the AP is away from the user(if the capture is taken close to the user). NOTE: BSSID is unique to an AP.

Unless the wireless infrastructure is a single channel architecture where all the APs will share the same BSSID on a given radio.

5.) If you want to know whether if the AP supports or advertising its support for WMM, Fast BSS transition support , you should be able to find that by looking at the beacon frame.

6.)RSN information on the Beacon frame will tell if the SSID is secured or open. This field is critical for a wireless client to identify if they are connected to open network or secured network and after the wireless layer 1 association(I like to call this as Layer-1) if client need to send out a DHCP packet(Layer-3) or it has to perform layer 2 authentication further like MAC-AUTH/MACHINE-AUTH/DOT1.X before layer 3.

Seen following cases in field:  On a beacon frame RSN bit is set for a captive portal SSID(incorrect behavior of AP a software bug) causing the client connection issues. While in the same environment Macintosh laptops were able to survive this issue while the other IOS devices couldn’t and they were not able to associate to Wireless network.

7.)Beacon frame carries information about the AP vendor and even the AP chipset vendor in use.

Its been helpful for me adding some useful column’s such as “DATE RATE , SIGNAL STRENGTH, CHANNEL, RETRY, DELTA-TIME” in Wire-shark application during my packet analysis.

You can always add more packet list column preference that will help your packet analysis.

wireshark colume's