Guest access in a retail environment
Some retail businesses such as coffee shops provide free Wi-Fi Internet access for their customers. For this type of application, the FortiOS guest management feature is not required; the Wi-Fi access point is open and customers do not need logon credentials. However, the business might want to contact its customers later with promotional offers to encourage further patronage. Using an Email Collection portal, it is possible to collect customer email addresses for this purpose. The security policy grants network access only to users who provide a valid email address.
The first time a customer’s device attempts to use the Wi-Fi connection, FortiOS requests an email address, which it validates. The customer’s subsequent connections go directly to the Internet without interruption.
Creating an email harvesting portal
The customer’s first contact with your network will be with a captive portal which presents a web page requesting an email address. When FortiOS has validated the email address, the customer’s device MAC address is added to the Collected Emails device group.
To create the email collection portal:
- Go to WiFi & Switch Controller > SSID and edit your SSID.
- Set Security Mode to Captive Portal.
- Set Portal Type to Email Collection.
- Optionally, in Customize Portal Messages select Email Collection.
You can change the portal content and appearance. See Customizing captive portal pages on page 101.
To create the email collection portal – CLI:
In this example the freewifi Wi-Fi interface is modified to present an email collection captive portal.
config wireless-controller vap edit freewifi set security captive-portal set portal-type email-collect
end
Creating the security policy
You need configure a security policy that allows traffic to flow from the Wi-Fi SSID to the Internet interface but only for members of the Collected Emails device group. This policy must be listed first. Unknown devices are not members of the Collected Emails device group, so they do not match the policy.
To create the security policy:
- Go to Policy & Objects > IPv4 Policy and select Create New.
- Enter the following information:
| Incoming Interface | freewifi |
| Source Address | all |
| Source Device Type | Collected Emails |
| Outgoing Interface | wan1 |
| Destination Address | all |
| Schedule | always |
| Service | ALL |
| Action | ACCEPT |
| NAT | On |
- Select OK.
To create the authentication rule – CLI:
config firewall policy edit 3 set srcintf “freewifi” set dstintf “wan1” set srcaddr “all” set action accept set devices collected-emails
set nat enable set schedule “always” set service “ALL”
end
Checking for harvested emails
In the web-based manager, go to User & Device > Device Inventory. In the CLI you can use the diagnose user device list command. For example,
FGT-100D # diagnose user device list hosts vd 0 d8:d1:cb:ab:61:0f gen 35 req 30 redir 1 last 43634s 7-11_2-int ip 10.0.2.101 ip6 fe80::dad1:cbff:feab:610f type 2 ‘iPhone’ src http c 1 gen 29 os ‘iPhone’ version ‘iOS 6.0.1’ src http id 358 c 1
email ‘yo@yourdomain.com’
vd 0 74:e1:b6:dd:69:f9 gen 36 req 20 redir 0 last 39369s 7-11_2-int ip 10.0.2.100 ip6 fe80::76e1:b6ff:fedd:69f9 type 1 ‘iPad’ src http c 1 gen 5 os ‘iPad’ version ‘iOS 6.0’ src http id 293 c 1
host ‘Joes’s-iPad’ src dhcp email ‘you@fortinet.com’
Fall-through authentication policies
User authentication policies have an implicit fall-through feature that intentionally causes policy matching to fall through to a policy lower on the list that can also match the traffic. In other words the first user policy that is Guest access in a retail environment
matched in the policy list, based on standard policy criteria, isn’t the only policy that can be matched.
Fall-through is intended to match users in different user groups with different policies. For example, consider an organization with two user groups where one group requires a web filtering profile, while the other requires virus scanning. In this example, you would edit two basic Internet access policies: policy 1 assigning User Group A with a Web Filtering profile, and policy 2 assigning User Group B with an AntiVirus profile. Both policies are also assigned to the same internal subnet, named subnet1.
In this configuration, all users from subnet1 will see an authentication prompt. If the user is found in User Group A, the traffic is accepted by policy 1 and is filtered by the Web Filtering profile. If the user is found in User Group B, the traffic is accepted by policy 2 and is virus scanned.
The fall-through feature is required for users to be matched with policy 2. Without the fall-through feature, traffic would never be matched with policy 2.