Technical Tip: How to modify the IDLE timeout for Email collection captive-portal users

[laltuzar]

Description	This article responds to the question of whether is it possible to modify the IDLE timeout and or expiration time of a user who used a captive portal that collects email addresses for Guest WiFi access.
Scope	FortiGate, FortiAP.
Solution	Users might find the usage of the Email collection captive portal as a way of gathering customers' emails for future engagement strategies. This can be accomplished by following this KB article: Technical Tip: How to collect email addresses for guest access However, it is not clear whether is possible if the IDLE timeout or expiration time can be configured. Some users might need this to be modified as they might want the clients to get the captive-portal shown again after some time. Let's clarify what is the purpose of this feature on FortiGate: Gather clients' emails. Therefore, this is not a feature for authentication purposes. Users might just input their email or other emails. Asking every time a user enters their email to access the internet might not work as well as was thought and automated stitches is one solution. How an Email collection type of Captive portal works: This feature associates the MAC address of the device on the firewall's auth list. Note that this is not the same table as the firewall auth list. So it is possible to check the users as follows: FG # diag firewall auth list ----- 0 listed, 0 filtered ------ FG # diagnose firewall auth mac list 26:b4:a8:aa:bb:cc, aabbcc@gmail.com type: email, id: 0, duration: 74222, idled: 53865 expire: 810134, allow-idle: 864000 flag(1000): src_idle packets: in 109554 out 125210, bytes: in 46728733 out 127723401 4e:67:86:dd:ee:ff, ddeeff@gmail.com type: email, id: 0, duration: 59026, idled: 59026 expire: 804974, allow-idle: 864000 flag(1000): src_idle packets: in 0 out 1, bytes: in 0 out 167 ... ----- 5 listed, 0 filtered ------ The IDLE time is set to 'allow-idle: 864000', which means that the user will be held on that table until it expires in 10 days (864000 seconds). Therefore the captive-portal will not be displayed the next time one tries to use the WiFi in the next 10 days. The command that was executed to get this information was 'diagnose firewall auth mac list' instead of 'diag firewall auth list'. This is because, as explained before, the session gets associated with the station's MAC address. So the solution is to clear that table with the command 'diagnose firewall auth mac clear'. It is now possible to do this automatically. For example with an Automation Stitch. Here are the steps to have this command run daily, one minute before midnight. It is possible to specify when to run the script. The steps are the following: Create the CLI script as an Action: config system automation-action     edit "clear auth mac list"         set action-type cli-script         set script "diagnose firewall auth mac clear"         set accprofile "super_admin"     next end​ Create the Trigger to specify the time the script is to be executed: config system automation-trigger     edit "Daily auth mac clear"         set trigger-type scheduled         set trigger-hour 23         set trigger-minute 59     next end​ Create the Stitch that will automate the clearance: config system automation-stitch     edit "Stitch-auth mac clear"         set trigger "Daily auth mac clear"             config actions                 edit 1                     set action "clear auth mac list"                     set required enable                 next             end         next     end​ After configuring, it would be possible to display the captive portal after x amount of time.