Yearly Archives: 2019

Using remote WLAN FortiAPs

Using remote WLAN FortiAPs

Remote WLAN FortiAP models enable you to provide a pre-configured WiFi access point to a remote or traveling employee. Once plugged in at home or in a hotel room, the FortiAP automatically discovers the enterprise FortiGate WiFi controller over the Internet and broadcasts the same wireless SSID used in the corporate office. Communication between the WiFi controller and the FortiAP is secure, eliminating the need for a VPN.

Split tunneling

By default, all traffic from the remote FortiAP is sent to the FortiGate WiFi controller. If split tunneling is configured, only traffic destined for the corporate office networks is routed to the FortiGate. Other general Internet traffic is routed unencrypted through the local gateway. Split tunneling avoids loading the FortiGate with unnecessary traffic and allows direct access to local private networks at the location of the FortiAP even if the connection to the WiFi controller goes down.

By default, split tunneling options are not visible in the FortiGate GUI. You can make these options visible using the following CLI command:

config system settings set gui-fortiap-split-tunneling enable

end

Split tunneling is configured in Managed FortiAPs, FortiAP Profiles, and enabled in the SSID.

Configuring the FortiGate for remote FortiAPs

This section assumes that you have already defined SSIDs and now want to make them available to remote FortiAPs.

  • Create FortiAP profiles for the Remote LAN FortiAP models l If split tunneling will be used l configure override split tunneling in Managed FortiAPs l enable Split Tunneling in the SSID
  • configure the split tunnel networks in the FortiAP profile

Override Split tunneling

Go to WiFi & Switch Controller > Managed FortiAPs and edit your managed APs. When preconfiguring the AP to connect to your FortiGate WiFi controller, you can choose to override split tunneling, optionally including the local subnet of the FortiAP.

Creating FortiAP profiles

If you were not already using Remote LAN FortiAP models, you will need to create FortiAP profiles for them. In the FortiAP profile, you specify the SSIDs that the FortiAP will broadcast. For more information, see “Creating a FortiAP profile” on page 34.

Configuring the FortiGate for remote FortiAPs                                                                Using remote WLAN FortiAPs

Configuring split tunneling – FortiGate GUI

Go to WiFi & Switch Controller > SSID and edit your SSID. In the WiFi Settings section, enable Split Tunneling.

Go to WiFi Controller > FortiAP Profiles and edit the FortiAP Profile(s) that apply to the AP types used in the WiFi network. In the Split Tunneling section, enable Include Local Subnet and Split Tunneling Subnet(s), where you can enter a list all of the destination IP address ranges that should not be routed through the the FortiGate WiFi controller. Packets for these destinations will instead be routed through the remote gateway local to the FortiAP.

The list of split tunneling subnets includes public Internet destinations and private subnets local to the FortiAP. Split tunneling public Internet destinations reduces traffic through the FortiGate unit. Split tunneling local private subnets allows these networks to be accessible to the client behind the FortiAP. Otherwise, private network IP destinations are assumed to be behind the FortiGate WiFi controller.

Configuring split tunneling – FortiGate CLI

In this example, split tunneling is configured on the example-ssid WiFi network. On FortiAP model 21D, traffic destined for the 192.168.x.x range will not be routed through the FortiGate WiFi controller. This private IP address range is typically used as a LAN by home routers.

config wireless-controller vap edit example-ssid set split-tunneling enable

end

config wireless-controller wtp-profile edit FAP21D-default set split-tunneling-acl-local-ap-subnet enable config split-tunneling-acl edit 1 set dest-ip 192.168.0.0 255.255.0.0

end

end

To enter multiple subnets, create a split-tunneling-acl entry for each one.

Overriding the split tunneling settings on a FortiAP

If the FortiAP Profile split tunneling settings are not appropriate for a particular FortiAP, you can override the settings on that unit.

config wireless-controller wtp edit FAP321C3X14019926 set override-split-tunnel enable

set split-tunneling-acl-local-ap-subnet enable config split-tunneling-acl edit 1 set dest-ip 192.168.10.0 255.255.255.0

end end

Using remote WLAN FortiAPs                                                                                        Configuring the FortiAP units

Configuring the FortiAP units

Prior to providing a Remote WLAN FortiAP unit to an employee, you need to preconfigure the AP to connect to your FortiGate WiFi controller.

To pre-configure a FortiAP

  1. Connect the FortiAP to the FortiGate unit.
  2. Go to WiFi & Switch Controller > Managed FortiAPs and wait for the FortiAP to be listed. Click Refresh periodically to see the latest information. Note the Connected Via IP address.
  3. Go to Dashboard. In the CLI Console, log into the FortiAP CLI. For example, if the IP address is 192.168.1.4, enter:

exec telnet 192.168.1.4

Enter admin at the login prompt. By default, no password is set.

  1. Enter the following commands to set the FortiGate WiFi controller IP address. This should be the FortiGate Internet-facing IP address, in this example 172.20.120.142.

cfg -a AC_IPADDR_1=172.20.120.142 cfg -c

  1. Enter exit to log out of the FortiAP CLI.

Preauthorizing FortiAP units

By preauthorizing FortiAP units, you facilitate their automatic authorization on the network. Also, you can assign each unit a unique name, such as the employee’s name, for easier tracking.

  1. Go to WiFi & Switch Controller > Managed FortiAPs and create a new entry.
  2. Enter the Serial Number of the FortiAP unit and give it a Name. Select the appropriate FortiAP Profile.
  3. Click OK.

Repeat this process for each FortiAP.

Features for high-density deployments

High-density environments such as auditoriums, classrooms, and meeting rooms present a challenge to WiFi providers. When a large number of mobile devices try to connect to a WiFi network, difficulties arise because of the limited number of radio channels and interference between devices.

FortiOS and FortiAP devices provide several tools to mitigate the difficulties of high-density environments.

Multiple FortiAP firmware upgrades at once

Administrators can configure multiple FortiAP and FortiSwitch firmware upgrades to occur in one click (under

WiFi & Switch Controller > Managed FortiAPs), removing the need to upgrade each device one at a time.

Power save feature

Occasionally, voice calls can become disrupted. One way to alleviate this issue is by controlling the power save feature, or to disable it altogether.

Manually configure packet transmit optimization settings by entering the following command:

config wireless-controller wtp-profile edit <name> config <radio-1> | <radio-2> set transmit-optimize {disable | power-save | aggr-limit | retry-limit | sendbar}

l disable: Disable transmit optimization. l power-save: Mark a client as power save mode if excessive transmit retries happen. l aggr-limit: Set aggregation limit to a lower value when data rate is low. l retry-limit: Set software retry limit to a lower value when data rate is low. l send-bar: Do not send BAR frame too often.

11n radio powersave optimization

The following powersave-optimize parameters (under config radio) are used for 11n radios to optimize system performance for specific situations.

  • tim: Set traffic indication map (TIM) bit for client in power save mode. TIM bit mask indicates to any sleeping listening stations if the AP has any buffered frames present. If enabled, the AP will always indicate to the connected client that there is a packet waiting in the AP, so it will help to prevent the client from entering a sleep state.
  • ac-vo: Use Access Category (AC) Voice (VO) priority to send packets in the power save queue. AC VO is one of the highest classes/priority levels used to ensure quality of service (QoS). If enabled, when a client returns from a sleep state, the AP will send its buffered packet using a higher priority queue, instead of the normal priority queue.
  • no-obss-scan: Do not put Overlapping Basic Service Set (OBSS), or high-noise (i.e. non-802.11), scan IE into a Beacon or Probe Response frame.
  • no-11b-rate: Do not send frame using 11b data rate.

 

Broadcast packet suppression

  • client-rate-follow: Adapt transmitting PHY rate with receiving PHY rate from client. If enabled, the AP will integrate the current client’s transmission PHY rate into its rate adaptation algorithm for transmitting.

Broadcast packet suppression

Broadcast packets are sent at a low data rate in WiFi networks, consuming valuable air time. Some broadcast packets are unnecessary or even potentially detrimental to the network and should be suppressed.

ARP requests and replies could allow clients to discover each other’s IP addresses. On most WiFi networks, intraclient communication is not allowed, so these ARP requests are of no use, but they occupy air time.

DHCP (upstream) should be allowed so that clients can request an IP address using DHCP.

DHCP (downstream) should be suppressed because it would allow a client to provide DHCP service to other clients. Only the AP should do this.

NetBIOS is a Microsoft Windows protocol for intra-application communication. Usually this is not required in highdensity deployments.

IPv6 broadcast packets can be suppressed if your network uses IPv4 addressing.

You can configure broadcast packet suppression in the CLI. The following options are available for broadcast suppression:

config wireless-controller vap edit <name> set broadcast-suppression {dhcp-up | dhcp-down | dhcp-starvation | arp-known | arpunknown | arp-reply | arp-poison | arp-proxy | netbios-ns | netbios-ds | ipv6 | all-other-mc | all-other-bc}

end

dhcp-starvation helps prevent clients from depleting the DHCP address pool by making multiple requests. arp-poison helps prevent clients from spoofing ARP messages.

Because of all these specific multicast and broadcast packet types, the two options all-other-mc and allother-bc help suppress multicast (mc) and broadcast (bc) packets that are not covered by any of the specific options.

Multicast to unicast conversion

Multicast data such as streaming audio or video are sent at a low data rate in WiFi networks. This causes them to occupy considerable air time. FortiOS provides a multicast enhancement option that converts multicast streams to unicast. A unicast stream is sent to each client at high data rate that makes more efficient use of air time. You can configure multicast-to-unicast conversion in the CLI:

config wireless-controller vap edit <vap_name> set multicast-enhance enable end

Ignore weak or distant clients

Ignore weak or distant clients

Clients beyond the intended coverage area can have some impact on your high-density network. Your APs will respond to these clients’ probe signals, consuming valuable air time. You can configure your WiFi network to ignore weak signals that most likely come from beyond the intended coverage area. The settings are available in the CLI:

config wireless-controller vap edit <vap_name> set probe-resp-suppression enable set probe-resp-threshold <level_int>

end vap_name is the SSID name.

probe-resp-threshold is the signal strength in dBm below which the client is ignored. The range is -95 to 20dBm. The default level is -80dBm.

Turn off 802.11b protocol

By disabling support for the obsolete 802.11b protocol, you can reduce the air time that data frames occupy. These signals will now be sent at a minimum of 6Mbps, instead of 1Mbps. You can set this for each radio in the FortiAP profile, using the CLI:

config wireless-controller wtp-profile edit <name_string> config radio-1 set powersave-optimize no-11b-rate

end

Disable low data rates

Each of the 802.11 protocols supports several data rates. By disabling the lowest rates, air time is conserved, allowing the channel to serve more users. You can set the available rates for each 802.11 protocol: a, b, g, n, ac. Data rates set as Basic are mandatory for clients to support. Other specified rates are supported.

The 802.11 a, b, and g protocols are specified by data rate. 802.11a can support 6,9,12, 18, 24, 36, 48, and 54

Mb/s. 802.11b/g can support 1, 2, 5.5, 6, 9,12, 18, 24, 36, 48, 54 Mb/s. Basic rates are specified with the suffix “basic”, “12-basic” for example. The capabilities of expected client devices need to be considered when deciding the lowest Basic rate.

The 802.11n and ac protocols are specified by the Modulation and Coding Scheme (MCS) Index and the number of spatial streams.

  • 11n with 1 or 2 spatial streams can support mcs0/1, mcs1/1, mcs2/1, mcs3/1, mcs4/1, mcs5/1, mcs6/1, mcs7/1,mcs8/2,mcs9/2, mcs10/2, mcs11/2, mcs12/2, mcs13/2, mcs14/2, mcs15/2.
  • 11n with 3 or 4 spatial streams can support mcs16/3, mcs17/3, mcs18/3, mcs19/3, mcs20/3, mcs21/3, mcs22/3, mcs23/3, mcs24/4, mcs25/4, mcs26/4, mcs27/4, mcs28/4, mcs29/4, mcs30/4, mcs31/4.

Limit power

  • 11ac with 1 or 2 spatial streams can support mcs0/1, mcs1/1, mcs2/1, mcs3/1, mcs4/1, mcs5/1, mcs6/1, mcs7/1, mcs8/1, mcs9/1, mcs0/2, mcs1/2, mcs2/2, mcs3/2, mcs4/2, mcs5/2, mcs6/2, mcs7/2, mcs8/2, mcs9/2.
  • 11ac with 3 or 4 spatial streams can support mcs0/3, mcs1/3, mcs2/3, mcs3/3, mcs4/3, mcs5/3, mcs6/3, mcs7/3, mcs8/3, mcs9/3, mcs0/4, mcs1/4, mcs2/4, mcs3/4, mcs4/4, mcs5/4, mcs6/4, mcs7/4, mcs8/4, mcs9/4 Here are some examples of setting basic and supported rates.

config wireless-controller vap edit <vap_name> set rates-11a 12-basic 18 24 36 48 54 set rates-11bg 12-basic 18 24 36 48 54

set rates-11n-ss34 mcs16/3 mcs18/3 mcs20/3 mcs21/3 mcs22/3 mcs23/3 mcs24/4 mcs25/4 set rates-11ac-ss34 mcs0/3 mcs1/3 mcs2/3 mcs9/4 mcs9/3

end

Limit power

High-density deployments usually cover a small area that has many clients. Maximum AP signal power is usually not required. Reducing the power reduces interference between APs. Fortinet recommends that you use FortiAP automatic power control. You can set this in the FortiAP profile.

  1. Go to WiFi & Switch Controller > FortiAP Profiles and edit the profile for your AP model.
  2. For each radio, enable Auto TX Power Control and set the TX Power Low and TX Power High The default range of 10 to 17dBm is recommended.

Use frequency band load-balancing

In a high-density environment is important to make the best use of the two WiFi bands, 2.4GHz and 5GHz. The 5GHz band has more non-overlapping channels and receives less interference from non-WiFi devices, but not all devices support it. Clients that are capable of 5GHz operation should be encouraged to use 5GHz rather than the 2.4GHz band.

To load-balance the WiFi bands, you enable Frequency Handoff in the FortiAP profile. In the FortiGate webbased manager, go to WiFi & Switch Controller > FortiAP Profiles and edit the relevant profile. Or, you can use the CLI:

config wireless-controller wtp-profile edit FAP221C-default config radio-1 set frequency-handoff enable

end

The FortiGate wireless controller continuously performs a scan of all clients in the area and records their signal strength (RSSI) on each band. When Frequency Handoff is enabled, the AP does not reply to clients on the

2.4GHz band that have sufficient signal strength on the 5GHz band. These clients can associate only on the 5GHz band. Devices that support only 2.4GHz receive replies and associate with the AP on the 2.4GHz band.

Setting the handoff RSSI threshold

The FortiAP applies load balancing to a client only if the client has a sufficient signal level on 5GHz. The minimum signal strength threshold is set in the FortiAP profile, but is accessible only through the CLI:

AP load balancing

config wireless-controller wtp-profile edit FAP221C-default set handoff-rssi 25

end

handoff-rssi has a range of 20 to 30. RSSI is a relative measure. The higher the number, the stronger the signal.

AP load balancing

The performance of an AP is degraded if it attempts to serve too many clients. In high-density environments, multiple access points are deployed with some overlap in their coverage areas. The WiFi controller can manage the association of new clients with APs to prevent overloading.

To load-balance between APs, enable AP Handoff in the FortiAP profile. In the FortiGate web-based manager, go to WiFi & Switch Controller > FortiAP Profiles and edit the relevant profile. Or, you can use the CLI:

config wireless-controller wtp-profile edit FAP221C-default config radio-1 set ap-handoff enable

end

When an AP exceeds the threshold (the default is 30 clients), the overloaded AP does not reply to a new client that has a sufficient signal at another AP.

Setting the AP load balance threshold

The thresholds for AP handoff are set in the FortiAP profile, but is accessible only through the CLI:

config wireless-controller wtp-profile edit FAP221C-default set handoff-sta-thresh 30 set handoff-rssi 25

end

handoff-sta-thresh sets the number of clients at which AP load balancing begins. It has a range of 5 to 35.

handoff-rssi Sets the minimum signal strength that a new client must have at an alternate AP for the overloaded AP to ignore the client. It has a range of 20 to 30. RSSI is a relative measure. The higher the number, the stronger the signal.

Application rate-limiting

To prevent particular application types from consuming too much bandwidth, you can use the FortiOS Application Control feature.

  1. Go to Security Profiles > Application Control.

You can use the default profile or create a new one.

  1. Click the category, select Traffic Shaping and then select the priority for the category.

Repeat for each category to be controlled.

  1. Select Apply.
  2. Go to Policy & Objects > IPv4 Policy and edit your WiFi security policy.

AP group management and dynamic VLAN assignment

  1. In Security Profiles, set Application Control ON and select the security profile that you edited.
  2. Select OK.

AP group management and dynamic VLAN assignment

The FortiGate can create FortiAP Groups, under WiFi & Switch Controller > Managed FortiAPs by selecting Create New > Managed AP Group, where multiple APs can be managed. AP grouping allows specific profile settings to be applied to many APs all at once that belong to a certain AP group, simplifying the administrative workload.

Note that each AP can only belong to one group.

In addition, VLANs can be assigned dynamically based on the group which an AP belongs. When defining an SSID, under WiFi & Switch Controller > SSID, a setting called VLAN Pooling can be enabled where you can either assign the VLAN ID of the AP group the device is connected to, to each device as it is detected, or to always assign the same VLAN ID to a specific device. Dynamic VLAN assignment allows the same SSID to be deployed to many APs, avoiding the need to produce multiple SSIDs.

Sharing tunnel SSIDs within a single managed AP between VDOMs as a virtual AP for multi-tenancy

This feature provides the ability to move a tunnel mode VAP into a VDOM, similar to an interface/VLAN in VDOMs. FortiAP is registered into the root VDOM.

Within a customer VDOM, customer VAPs can be created/added. In the root VDOM, the customer VAP can be added to the registered FortiAP. Any necessary firewall rules and interfaces can be configured between the two VDOMs.

Syntax

config wireless-controller global set wtp-share {enable | disable}

end

Manual quarantine of devices on FortiAP (tunnel mode)

Quarantined MAC addresses are blocked on the connected FortiAP from the network and the LAN. When a tunnel VAP is created, a sub-interface named wqtn is automatically created under tunnel interface. ThisThis subinterface is added under a software switch.

To quarantine an SSID, go to WiFi & Switch Controller > SSID. Edit the SSID, and enable Quarantine Host is enabled under WiFi Settings.

Alternatively, this can be configured in the CLI Console. This feature consolidates previous CLI syntax for quarantining a host, so that the host does not need to be configured in multiple places (FortiAP and FortiSwitch). Host endpoints can be entered in a single place and the host will be quarantined throughout the access layer devices on the Fortinet Security Fabric.

Manual quarantine of devices on FortiAP (tunnel mode)

Syntax – SSID:

config wireless-controller vap edit <name> set quarantine {enable | disable}

next

end

Syntax – Software Switch, DHCP, and User Quarantine

config system switch-interface edit “wqt.root” set vdom “root” set member “wqtn.26.AV-Qtn”

next

end

config system dhcp server edit <id> set interface “AV-Qtn” config ip-range edit <id> set start-ip 10.111.0.2 set end-ip 10.111.0.254

next …

config user quarantine set quarantine {enable | disable}

end

To list stations in quarantine, use the following diagnose command:

diagnose wireless-controller wlac -c sta-qtn

Host quarantine per SSID

Upon creating or editing an SSID, a Quarantine Host option is available to enable (by default) or disable quarantining devices that are connected in Tunnel-mode. The option to quarantine a device is available on Topology and FortiView WiFi pages.

When a host is put into quarantine VLAN, it will get its IP from the quarantine VLAN’s DHCP server, and become part of the quarantined network.

Syntax

config wireless-controller vap edit <name> set quarantine {enable | disable}

next end

Locate a FortiAP with LED blinking

To list all stations in quarantine:

diagnose wireless-controller wlac -c sta-qtn

Locate a FortiAP with LED blinking

If you have an environment that contains numerous APs, and there is one AP that you need to frequently monitor, you can configure it to blink in the FortiCloud web portal. The blinking AP will be easier to locate.

To start or stop LED blinking of a managed FortiAP, using the GUI:

  1. Go to WiFi & Switch Controller > Managed FortiAPs.
  2. Right-click in the row of the device you want to control.
  3. In the dialog box, scroll down to LED Blink and select Start or Stop.

The following models support LED blink control through the GUI, operating on FortiAP software 6.0.1, or later:

  • FortiAP-112D, 221C, 223C, 224D, 320C, 321C l FortiAP-S/W2

To start or stop LED blinking of a managed FortiAP, using the CLI:

execute wireless-controller led-blink <wtp-id> {on | on 10 | off}

The following models support LED blink control through the CLI, operating on FortiAP software 5.6.2, or later:

  • FortiAP-112D, 221C, 223C, 224D, 320C, 321C l FortiAP-S/W2

Wireless controller optimization for large deployment – AP image upgrade

Using the CLI to upgrade FortiAP image is the preferred method especially for large deployments. Use the following execute command to upload the desired FortiAP image on the controller:

execute wireless-controller upload-wtp-image

After entering the command, reboot the FortiAP devices. This feature allows the administrator to configure all FortiAP devices to download the image from the controller at join time.

Syntax

config wireless-controller global set image-download {enable | disable}

end

To fine-tune this process, in order to deploy FortiAP image upgrades to a subset of devices for pilot testing, use the following command:

config wireless-controller wtp edit <name> set image-download {enable | disable} next

Control message off-loading and aeroscout enhancement

end

Control message off-loading and aeroscout enhancement

Users can configure control message off-loading to optimize performance. This is especially useful in environments where the AP count is around 300-350 (with a device count between 1500 and 3000), where existing users are disconnected and unable to reauthenticate due to high CPU usage. This feature includes aeroscout enhancements.

Syntax

config wireless-controller global set control-message-offload {evp-frame | areoscout-tag | ap-list | sta-list | sta-caplist | stats | aeroscout-mu}

end

config wireless-controller wtp-profile edit <name> set control-message-offload {enable | disable} config lbs set ekahau-blink-mode {enable | disable} set aeroscout {enable | disable} set aeroscout-server-ip <address>

set aeroscount-server-port <UDP listening port> set aeroscout-mu {enable | disable}

end end

 

Combining WiFi and wired networks with a software switch

Combining WiFi and wired networks with a software switch

Combining WiFi and wired networks with a software switch

FortiAP local bridging (Private cloud-managed AP)

Using bridged FortiAPs to increase scalability

Combining WiFi and wired networks with a software switch

A WiFi network can be combined with a wired LAN so that WiFi and wired clients are on the same subnet. This is a convenient configuration for users. Note that software switches are only available if your FortiGate is in Interface mode.

To create the WiFi and wired LAN configuration, you need to:

  • Configure the SSID so that traffic is tunneled to the WiFi controller.
  • Configure a software switch interface on the FortiGate unit with the WiFi and internal network interface as members. l Configure Captive Portal security for the software switch interface.

To configure the SSID – web-based manager

  1. Go to WiFi & Switch Controller > SSID and select Create New.
  2. Enter:
Interface name A name for the new WiFi interface, homenet_if for example.
Traffic Mode Tunnel to Wireless Controller
SSID The SSID visible to users, homenet for example.
Security Mode

Data Encryption

Preshared Key

Configure security as you would for a regular WiFi network.
  1. Select OK.
  2. Go to WiFi & Switch Controller > Managed FortiAPs, select the FortiAP unit for editing.
  3. Authorize the FortiAP unit.

The FortiAP unit can carry regular SSIDs in addition to the Bridge SSID.

To configure the SSID – CLI

This example creates a WiFi interface “homenet_if” with SSID “homenet” using WPA-Personal security, passphrase “Fortinet1”.

config wireless-controller vap edit “homenet_if” set vdom “root” set ssid “homenet” set security wpa-personal set passphrase “Fortinet1”

end

config wireless-controller wtp edit FAP22B3U11005354 set admin enable set vaps “homenet_if”

end

To configure the FortiGate software switch – web-based manager

  1. Go to Network > Interfaces and select Create New > Interface.
  2. Enter:
Interface Name A name for the new interface, homenet_nw for example.
Type Software Switch
Physical Interface Members Add homenet_if and the internal network interface.
Addressing mode Select Manual and enter an address, for example 172.16.96.32/255.255.255.0
DHCP Server Enable and configure an address range for clients.
Security Mode Select Captive Portal. Add the permitted User Groups.
  1. Select OK.

To configure the FortiGate unit – CLI

config system interface edit homenet_nw set ip 172.16.96.32 255.255.255.0 set type switch set security-mode captive-portal set security-groups “Guest-group”

end

config system interface edit homenet_nw set member “homenet_if” “internal” end

FortiAP local bridging (Private cloud-managed AP)

VLAN configuration

If your environment uses VLAN tagging, you assign the SSID to a specific VLAN in the CLI. For example, to assign the homenet_if interface to VLAN 100, enter:

config wireless-controller vap edit “homenet_if” set vlanid 100

end

Additional configuration

The configuration described above provides communication between WiFi and wired LAN users only. To provide access to other networks, create appropriate firewall policies between the software switch and other interfaces.

FortiAP local bridging (Private cloud-managed AP)

A FortiAP unit can provide WiFi access to a LAN, even when the wireless controller is located remotely. This configuration is useful for the following situations:

  • Installations where the WiFI controller is remote and most of the traffic is local or uses the local Internet gateway l Wireless-PCI compliance with remote WiFi controller
  • Telecommuting, where the FortiAP unit has the WiFi controller IP address pre-configured and broadcasts the office SSID in the user’s home or hotel room. In this case, data is sent in the wireless tunnel across the Internet to the office and you should enable encryption using DTLS.

FortiAP local bridging (Private cloud-managed AP)

Remotely-managed FortiAP providing WiFi access to local network

On the remote FortiGate wireless controller, the WiFi SSID is created with the Bridge with FortiAP Interface option selected. In this mode, no IP addresses are configured. The WiFi and Ethernet interfaces on the FortiAP behave as a switch. WiFi client devices obtain IP addresses from the same DHCP server as wired devices on the LAN.

The local bridge feature cannot be used in conjunction with Wireless Mesh features.

Block-Intra-SSID Traffic is available in Bridge mode. This is useful in hotspotdeployments managed by a central FortiGate, but would also be useful in cloud deployments. Previously, this was only supported in Tunnel mode.

To configure a FortiAP local bridge – web-based manager

  1. Go to WiFi & Switch Controller > SSID and select Create New > SSID.
  2. Enter:
Interface name A name for the new WiFi interface.
Traffic Mode Local bridge with FortiAP’s Interface
SSID The SSID visible to users.

 

Security Mode

Data Encryption

Preshared Key

Configure security as you would for a regular WiFi network.
  1. Select OK.
  2. Go to WiFi & Switch Controller > Managed FortiAPs and select the FortiAP unit for editing.
  3. Authorize the FortiAP unit.

The FortiAP unit can carry regular SSIDs in addition to the Bridge SSID.

SSID configured for local bridge operation

To configure a FortiAP local bridge – CLI

This example creates a WiFi interface “branchbridge” with SSID “LANbridge” using WPA-Personal security, passphrase “Fortinet1”.

config wireless-controller vap edit “branchbridge” set vdom “root” set ssid “LANbridge” set local-bridging enable set security wpa-personal set passphrase “Fortinet1”

end

config wireless-controller wtp edit FAP22B3U11005354 set admin enable set vaps “branchbridge” end

Using bridged FortiAPs to increase scalability

Continued FortiAP operation when WiFi controller connection is down

The wireless controller, or the connection to it, might occasionally become unavailable. During such an outage, clients already associated with a bridge mode FortiAP unit continue to have access to the WiFi and wired networks. Optionally, the FortiAP unit can also continue to authenticate users if the SSID meets these conditions:

  • Traffic Mode is Local bridge with FortiAP’s Interface.

In this mode, the FortiAP unit does not send traffic back to the wireless controller.

  • Security Mode is WPA2 Personal.

These modes do not require the user database. In WPA2 Personal authentication, all clients use the same preshared key which is known to the FortiAP unit.

  • Allow New WiFi Client Connections When Controller is down is enabled. This field is available only if the other conditions have been met.

The “LANbridge” SSID example would be configured like this in the CLI:

config wireless-controller vap edit “branchbridge” set vdom “root” set ssid “LANbridge” set local-bridging enable set security wpa-personal set passphrase “Fortinet1” set local-authentication enable

end

Using bridged FortiAPs to increase scalability

The FortiGate wireless controller can support more FortiAP units in local bridge mode than in the normal mode. But this is only true if you configure some of your FortiAP units to operate in remote mode, which supports only local bridge mode SSIDs.

The Managed FortAP page (WiFi & Switch Controller > Managed FortiAPs) shows at the top right the current number of Managed FortiAPs and the maximum number that can be managed, “5/64” for example. The maximum number, however, is true only if all FortiAP units operate in remote mode. For more detailed information, consult the Maximum Values Table. For each FortiGate model, there are two maximum values for managed FortiAP units: the total number of FortiAPs and the number of FortiAPs that can operate in normal mode.

Using bridged FortiAPs to increase scalability

To configure FortiAP units for remote mode operation

  1. Create at least one SSID with Traffic Mode set to Local bridge with FortiAP’s Interface.
  2. Create a custom AP profile that includes only local bridge SSIDs.
  3. Configure each managed FortiAP unit to use the custom AP profile. You also need to set the FortiAP unit’s wtpmode to remote, which is possible only in the CLI. The following example uses the CLI both to set wtp-mode and select the custom AP profile:

config wireless-controller wtp edit FAP22B3U11005354 set wtp-mode remote set wtp-profile 220B_bridge end

 

Wireless mesh

Wireless mesh

The access points of a WiFi network are usually connected to the WiFi controller through Ethernet wiring. A wireless mesh eliminates the need for Ethernet wiring by connecting WiFi access points to the controller by radio. This is useful where installation of Ethernet wiring is impractical.

Overview of Wireless mesh

Configuring a meshed WiFi network

Configuring a point-to-point bridge

Overview of Wireless mesh

The figure below shows a wireless mesh topology.

A wireless mesh is a multiple AP network in which only one FortiAP unit is connected to the wired network. The other FortiAPs communicate with the controller over a separate backhaul SSID that is not available to regular WiFi clients. The AP that is connected to the network by Ethernet is called the Mesh Root node. The backhaul SSID carries CAPWAP discovery, configuration, and other communications that would usually be carried on an Ethernet connection.

The root node can be a FortiAP unit or the built-in AP of a FortiWiFi unit. APs that serve regular WiFi clients are called Leaf nodes. Leaf APs also carry the mesh SSID for more distant leaf nodes. A leaf node can connect to the mesh SSID directly from the root node or from any of the other leaf nodes. This provides redundancy in case of an AP failure.

All access points in a wireless mesh configuration must have at least one of their radios configured to provide mesh backhaul communication. As with wired APs, when mesh APs start up they can be discovered by a FortiGate or FortiWiFi unit WiFi controller and authorized to join the network.

Overview of

The backhaul SSID delivers the best performance when it is carried on a dedicated radio. On a two-radio FortiAP unit, for example, the 5GHz radio could carry only the backhaul SSID while the 2.4GHz radio carries one or more SSIDs that serve users. Background WiFi scanning is possible in this mode.

The backhaul SSID can also share the same radio with SSIDs that serve users. Performance is reduced because the backhaul and user traffic compete for the available bandwidth. Background WiFi scanning is not available in this mode. One advantage of this mode is that a two-radio AP can offer WiFi coverage on both bands.

Wireless mesh deployment modes

There are two common wireless mesh deployment modes:

Wireless Mesh Access points are wirelessly connected to a FortiGate or FortiWiFi unit WiFi controller. WiFi users connect to wireless SSIDs in the same way as on non-mesh WiFi networks.
Wireless bridging Two LAN segments are connected together over a wireless link (the backhaul SSID).

On the leaf AP, the Ethernet connection can be used to provide a wired network. Both WiFi and wired users on the leaf AP are connected to the LAN segment to which the root AP is connected.

Firmware requirements

All FortiAP units that will be part of the wireless mesh network must be upgraded to FAP firmware version 5.0 build 003. FortiAP-222B units must have their BIOS upgraded to version 400012. The FortiWiFi or FortiGate unit used as the WiFi controller must be running FortiOS 5.0.

Types of wireless mesh

A WiFi mesh can provide access to widely-distributed clients. The root mesh AP which is directly connected to the WiFi controller can be either a FortiAP unit or the built-in AP of a FortiWiFi unit that is also the WiFi controller.

FortiAP units used as both mesh root AP and leaf AP

Overview of Wireless mesh

FortiWiFi unit as root mesh AP with FortiAP units as leaf APs

An alternate use of the wireless mesh functionality is as a point-to-point relay. Both wired and WiFi users on the leaf AP side are connected to the LAN segment on the root mesh side.

Overview of

Point-to-point wireless mesh

Fast-roaming for mesh backhaul link

Mesh implementations for leaf FortiAP can perform background scan when the leaf AP is associated to root. Various options for background scanning can be configured with the CLI. See Mesh variables on page 189 for more details.

Configuring a meshed WiFi network

You need to:

  • Create the mesh root SSID. l Create the FortiAP profile. l Configure mesh leaf AP units. l Configure the mesh root AP, either a FortiWiFi unit’s Local Radio or a FortiAP unit. l Authorize the mesh branch/leaf units when they connect to the WiFi Controller.
  • Create security policies.

This section assumes that the end-user SSIDs already exist.

Creating the mesh root SSID

The mesh route SSID is the radio backhaul that conveys the user SSID traffic to the leaf FortiAPs.

To configure the mesh root SSID

  1. Go to WiFi & Switch Controller > SSID and select Create New > SSID.
  2. Enter a Name for the WiFi interface.
  3. In Traffic Mode, select Mesh Downlink.
  4. Enter the SSID.
  5. Set Security Mode to WPA2 Personal and enter the Pre-shared key.

Remember the key, you need to enter it into the configurations of the leaf FortiAPs.

  1. Select OK.

Creating the FortiAP profile

Create a FortiAP profile for the meshed FortiAPs. If more than one FortiAP model is involved, you need to create a profile for each model. Typically, the profile is configured so that Radio 1 (5GHz) carries the mesh backhaul SSID while Radio 2 (2.4GHz) carries the SSIDs to which users connect.

The radio that carries the backhaul traffic must not carry other SSIDs. Use the Select SSIDs option and choose only the backhaul SSID. Similarly, the radio that carries user SSIDs, should not carry the backhaul. Use the Select SSIDs option and choose the networks that you want to provide.

For more information, see Configuring a WiFi LAN on page 30.

Configuring the mesh root FortiAP

The mesh root AP can be either a FortiWiFi unit’s built-in AP or a FortiAP unit.

Configuring a meshed WiFi network

To enable a FortiWiFi unit’s Local Radio as mesh root – web-based manager

  1. Go to WiFi Controller > Local WiFi Radio.
  2. Select Enable WiFi Radio.
  3. In SSID, select Select SSIDs, then select the mesh root SSID.
  4. Optionally, adjust TX Power or select Auto Tx Power Control.
  5. Select Apply.

In a network with multiple wireless controllers, make sure that each mesh root has a unique SSID. Other controllers using the same mesh root SSID might be detected as fake or rogue APs. Go to WiFi & Switch Controller > SSID to change the SSID.

To configure a network interface for the mesh root FortiAP unit

  1. On the FortiGate unit, go to Network > Interfaces.
  2. Select the interface where you will connect the FortiAP unit, and edit it.
  3. Make sure that Role is LAN.
  4. In Addressing mode, select Dedicated to Extension Device.
  5. In IP/Network Mask, enter an IP address and netmask for the interface.

DHCP will provide addresses to connected devices. To maximize the number of available addresses, the interface address should end with 1, for example 192.168.10.1.

  1. Select OK.

At this point you can connect the mesh root FortiAP, as described next. If you are going to configure leaf FortiAPs through the wireless controller (see “Configuring a meshed WiFi network” on page 82), it would be convenient to leave connecting the root unit for later.

To enable the root FortiAP unit

  1. Connect the root FortiAP unit’s Ethernet port to the FortiGate network interface that you configured for it.
  2. Go to WiFi & Switch Controller > Managed FortiAPs.

If the root FortiAP unit is not listed, wait 15 seconds and select Refresh. Repeat if necessary. If the unit is still missing after a minute or two, power cycle the root FortiAP unit and try again.

  1. Right-click the FortiAP entry and choose your profile from the Assign Profile
  2. Right-click the FortiAP entry and select Authorize.

Initially, the State of the FortiAP unit is Offline. Periodically click Refresh to update the status. Within about two minutes, the state changes to Online.

  1. Select OK.

You might need to select Refresh a few times before the FortiAP shows as Online.

Configuring the leaf mesh FortiAPs

The FortiAP units that will serve as leaf nodes must be preconfigured. This involves changing the FortiAP unit internal configuration.You can do this by direct connection or through the FortiGate wireless controller. meshed WiFi network

Method 1: Direct connection to the FortiAP

  1. Connect a computer to the FortiAP unit’s Ethernet port. Configure the computer’s IP as 192.168.1.3.
  2. Telnet to 192.168.1.2. Login as admin. By default, no password is set.
  3. Enter the following commands, substituting your own SSID and password (pre-shared key):

cfg -a MESH_AP_TYPE=1 cfg -a MESH_AP_SSID=fortinet.mesh.root cfg -a MESH_AP_PASSWD=hardtoguess

cfg -c exit

  1. Disconnect the computer.
  2. Power down the FortiAP.
  3. Repeat the preceding steps for each branch FortiAP.

Method 2: Connecting through the FortiGate unit

  1. Connect the branch FortiAP unit’s Ethernet port to the FortiGate network interface that you configured for FortiAPs. Connect the FortiAP unit to a power source unless POE is used.
  2. Go to WiFi & Switch Controller > Managed FortiAPs.

If the FortiAP unit is not listed, wait 15 seconds and select Refresh. Repeat if necessary. If the unit is still missing after a minute or two, power cycle the FortiAP unit and try again.

  1. Select the discovered FortiAP unit and authorize it. Click Refresh every 10 seconds until the State indicator is green.
  2. Right-click the FortiAP and select >_Connect to CLI. The CLI Console window opens. Log in as “admin”.
  3. Enter the following commands, substituting your own SSID and password (pre-shared key):

cfg -a MESH_AP_TYPE=1 cfg -a MESH_AP_SSID=fortinet.mesh.root cfg -a MESH_AP_PASSWD=hardtoguess

cfg -c exit

  1. Disconnect the branch FortiAP and delete it from the Managed FortiAP list.
  2. Repeat the preceding steps for each branch FortiAP.

Authorizing leaf APs

When the root FortiAP is connected and online, apply power to the pre-configured leaf FortiAPs. The leaf FortiAPs will connect themselves wirelessly to the WiFi Controller through the mesh network. You must authorize each unit.

  1. Go to WiFi & Switch Controller > Managed FortiAPs. Periodically select Refresh until the FortiAP unit is listed. This can take up to three minutes.

The State of the FortiAP unit should be Waiting for Authorization.

  1. Right-click the FortiAP entry and choose your profile from the Assign Profile
  2. Right-click the FortiAP entry and select Authorize.

Initially, the State of the FortiAP unit is Offline. Periodically click Refresh to update the status. Within about two minutes, the state changes to Online.

Creating security policies

You need to create security policies to permit traffic to flow from the end-user WiFi network to the network interfaces for the Internet and other networks. Enable NAT.

Viewing the status of the mesh network

Go to WiFi & Switch Controller > Managed FortiAPs to view the list of APs.

The Connected Via field lists the IP address of each FortiAP and uses icons to show whether the FortiAP is connected by Ethernet or Mesh.

Ethernet
Mesh

If you mouse over the Connected Via information, a topology displays, showing how the FortiGate wireless controller connects to the FortiAP.

Configuring a point-to-point bridge

You can create a point-to-point bridge to connect two wired network segments using a WiFi link. The effect is the same as connecting the two network segments to the same wired switch.

You need to:

point-to-point bridge

l Configure a backhaul link and root mesh AP as described in Configuring a point-to-point bridge on page 84.

Note: The root mesh AP for a point-to-point bridge must be a FortiAP unit, not the internal AP of a FortiWiFi unit. l Configure bridging on the leaf AP unit.

To configure the leaf AP unit for bridged operation – FortiAP web-based manager

  1. With your browser, connect to the FortiAP unit web-based manager.

You can temporarily connect to the unit’s Ethernet port and use its default address: 192.168.1.2.

  1. Enter:
Operation Mode Mesh
Mesh AP SSID fortinet-ap
Mesh AP Password fortinet
Ethernet Bridge Select
  1. Select Apply.
  2. Connect the local wired network to the Ethernet port on the FortiAP unit.

Users are assigned IP addresses from the DHCP server on the wired network connected to the root mesh AP unit.

To configure a FortiAP unit as a leaf AP – FortiAP CLI

cfg -a MESH_AP_SSID=fortinet-ap cfg -a MESH_AP_PASSWD=fortinet cfg -a MESH_ETH_BRIDGE=1 cfg -a MESH_AP_TYPE=1 cfg -c

 

Hotspot 2.0

Hotspot 2.0 Access Network Query Protocol (ANQP) is a query and response protocol that defines seamless roaming services offered by an AP. The following CLI commands are available under config wirelesscontroller, to configure Hotspot 2.0 ANQP.

Syntax

config wireless-controller hotspot20 anqp-3gpp-cellular edit {name} config mcc-mnc-list edit {id} set id {integer} set mcc {string} set mnc {string}

next

next

end

config wireless-controller hotspot20 anqp-ip-address-type edit {name} set ipv6-address-type {option} set ipv4-address-type {option}

next

end

config wireless-controller hotspot20 anqp-nai-realm edit {name} config nai-list edit {name} set encoding {enable | disable} set nai-realm {string} config eap-method edit {index} set index {integer} set method {option} config auth-param edit {index} set index {integer} set id {option} set val {option}

next

next

next

next

end

config wireless-controller hotspot20 anqp-network-auth-type edit {name} set auth-type {option} set url {string}

next end

Hotspot 2.0

config wireless-controller hotspot20 anqp-roaming-consortium edit {name} config oi-list edit {index} set index {integer} set oi {string} set comment {string}

next

next

end

config wireless-controller hotspot20 anqp-venue-name edit {name} config value-list edit {index} set index {integer} set lang {string} set value {string}

next

next

end

config wireless-controller hotspot20 h2qp-conn-capability edit {name} set icmp-port {option} set ftp-port {option} set ssh-port {option} set http-port {option} set tls-port {option} set pptp-vpn-port {option} set voip-tcp-port {option} set voip-udp-port {option} set ikev2-port {option} set ikev2-xx-port {option} set esp-port {option}

next

end

config wireless-controller hotspot20 h2qp-operator-name edit {name} config value-list edit {index} set index {integer} set lang {string} set value {string}

next

next

end config wireless-controller hotspot20 h2qp-osu-provider

Configuring a point-to-point bridge

edit {name} config friendly-name edit {index} set index {integer} set lang {string} set friendly-name {string}

Configuring a point-to-point bridge                                                                                                         Hotspot 2.0

next set server-uri {string} set osu-method {option} set osu-nai {string} config service-description edit {service-id} set service-id {integer} set lang {string}

set service-description {string}

next

set icon {string}

next

end

config wireless-controller hotspot20 h2qp-wan-metric edit {name} set link-status {option} set symmetric-wan-link {option} set link-at-capacity {enable | disable} set uplink-speed {integer} set downlink-speed {integer} set uplink-load {integer} set downlink-load {integer} set load-measurement-duration {integer}

next

end

config wireless-controller hotspot20 hs-profile edit {name} set access-network-type {option} set access-network-internet {enable | disable} set access-network-asra {enable | disable} set access-network-esr {enable | disable} set access-network-uesa {enable | disable} set venue-group {option} set venue-type {option} set hessid {mac address} set proxy-arp {enable | disable} set l2tif {enable | disable} set pame-bi {enable | disable} set anqp-domain-id {integer} set domain-name {string} set osu-ssid {string} set gas-comeback-delay {integer} set gas-fragmentation-limit {integer} set dgaf {enable | disable} set deauth-request-timeout {integer} set wnm-sleep-mode {enable | disable} set bss-transition {enable | disable} set venue-name {string} set roaming-consortium {string} set nai-realm {string} set oper-friendly-name {string} config osu-provider edit {name} next set wan-metrics {string}

Hotspot 2.0                                                                                                         Configuring a point-to-point bridge

set network-auth {string} set 3gpp-plmn {string} set conn-cap {string} set qos-map {string} set ip-addr-type {string}

next

end

config wireless-controller hotspot20 icon edit {name} config icon-list edit {name} set lang {string} set file {string} set type {option} set width {integer} set height {integer}

next

next

end

config wireless-controller hotspot20 qos-map edit {name} config dscp-except edit {index} set index set dscp set up

next

config dscp-range edit {index} set index set up set low set high

next

next end

Access point deployment

Access point deployment

Overview

FortiAP units discover WiFi controllers. The administrator of the WiFi controller authorizes the FortiAP units that the controller will manage.

In most cases, FortiAP units can find WiFi controllers through the wired Ethernet without any special configuration. Review the following section, Access point deployment on page 55, to make sure that your method of connecting the FortiAP unit to the WiFi controller is valid. Then, you are ready to follow the procedures in Access point deployment on page 55.

If your FortiAP units are unable to find the WiFi controller, refer to Access point deployment on page 55 for detailed information about the FortiAP unit’s controller discovery methods and how you can configure them.

Network topology for managed APs

The FortiAP unit can be connected to the FortiGate unit in any of the following ways:

Direct connection: The FortiAP unit is directly connected to the FortiGate unit with no switches between them.

This configuration is common for locations where the number of FortiAP’s matches up with the number of

‘internal’ ports available on the FortiGate. In this configuration the FortiAP unit requests an IP address from the FortiGate unit, enters discovery mode and should quickly find the FortiGate WiFi controller. This is also known as a wirecloset deployment. See “Wirecloset and Gateway deployments” below.

 

Wirecloset deployment

Switched Connection: The FortiAP unit is connected to the FortiGate WiFi controller by an Ethernet switch operating in L2 switching mode or L3 routing mode. There must be a routable path between the FortiAP unit and the FortiGate unit and ports 5246 and 5247 must be open. This is also known as a gateway deployment. See Gateway Deployment below.

Gateway Deployment

Network topology for managed

Connection over WAN: The FortiGate WiFi controller is off-premises and connected by a VPN tunnel to a local FortiGate. In this method of connectivity its best to configure each FortiAP with the static IP address of the WiFi controller. Each FortiAP can be configured with three WiFi controller IP addresses for redundant failover. This is also known as a datacenter remote management deployment. See Remote deployment below.

Remote deployment

Configuring a WiFi LAN

Configuring a WiFi LAN

When working with a FortiGate WiFi controller, you can configure your wireless network before you install any access points. If you are working with a standalone FortiWiFi unit, the access point hardware is already present but the configuration is quite similar. Both are covered in this section.

Overview of WiFi controller configuration

Setting your geographic location

Creating a FortiAP profile

Defining a wireless network interface (SSID)

Defining SSID groups

Dynamic user VLAN assignment

Configuring user authentication

Configuring firewall policies for the SSID

Configuring the built-in access point on a FortiWiFi unit

Enforcing UTM policies on a local bridge SSID for managed smart APs

On FortiGate model 30D, web-based manager configuration of the WiFi controller is disabled by default. To enable it, enter the following CLI commands:

config system global

set gui-wireless-controller enable end

The WiFi Controller and Switch Controller are enabled through the Feature Store (under System > Feature Select). However, they are separately enabled and configured to display in the GUI via the CLI.

To enable both WiFi and Switch controllers, enter the following:

config system global set wireless-controller enable set switch-controller enable

end

To enable the GUI display for both controllers, have also been separated:

config system settings set gui-wireless-controller enable set gui-switch-controller enable end

If you want to connect and authorize external APs, such as FortiAP units, see the next chapter, Access point deployment.

Captive portals

Captive portals

Introduction to captive portals

You can authenticate your users on a web page that requests the user’s name and password. Until the user authenticates successfully, the authentication page is returned in response to any HTTP request. This is called a captive portal.

After successful authentication, the user accesses the requested URL and can access other web resources, as permitted by security policies. Optionally, the captive portal itself can allow web access to only the members of specified user group.

The captive portal can be hosted on the FortiGate unit or on an external authentication server. You can configure captive portal authentication on any network interface, including WiFi and VLAN interfaces.

When a captive portal is configured on a WiFi interface, the access point initially appears open. The wireless client can connect to the access point with no security credentials, but sees only the captive portal authentication page.

WiFi captive portal types:

  • Authentication — until the user enters valid credentials, no communication beyond the AP is permitted.
  • Disclaimer + Authentication — immediately after successful authentication, the portal presents the disclaimer page—an acceptable use policy or other legal statement—to which the user must agree before proceeding.
  • Disclaimer Only — the portal presents the disclaimer page—an acceptable use policy or other legal statement— to which the user must agree before proceeding. The authentication page is not presented.
  • Email Collection — the portal presents a page requesting the user’s email address, for the purpose of contacting the person in future. This is often used by businesses who provide free WiFi access to their customers. The authentication page is not presented.
  • MAC Bypass — when clients are authenticated against their bridged SSID and their MAC addresses are known, they are redirected to the external captive portal.

Configuring a captive portal

Captive portals are configured on network interfaces. A WiFi interface does not exist until the WiFi SSID is created. You can configure a WiFi captive portal at the time that you create the SSID. Afterwards, the captive portal settings will also be available by editing the WiFi network interface in System > Network > Interfaces.

On a physical (wired) network interface, you edit the interface configuration in System > Network > Interfaces and set Security Mode to Captive Portal.

To configure a WiFi captive portal – web-based manager:

  1. Go to WiFi & Switch Controller > SSID and create your SSID.

If the SSID already exists, you can edit the SSID or you can edit the WiFi interface in Network > Interfaces.

  1. Under WiFi Settings, for Security Mode, select Captive Portal.
  2. Enter the following:
Portal Type The portal can provide authentication and/or disclaimer, or perform user email address collection. See Introduction to captive portals on page 19.
Authentication Portal Local – portal hosted on the FortiGate unit.

Remote – enter FQDN or IP address of external portal.

User Groups Select permitted user groups.
Exempt Sources

Exempt

Destinations/Services

Select exempt lists whose members will not be subject to captive portal authentication.
Redirect after Captive Portal Select whether to have authenticated users navigate to their originally requested URL or be redirected to another/specific URL.
  1. Select OK.

To configure an SSID with external-web enabled – CLI:

config wireless-controller vap edit “web-ext” set vdom “root” set ssid “web-ext” set security captive-portal set selected-usergroups “qnap“

Configuring a

set security-exempt-list “wifi”

set security-redirect-url “ http://www.fortinet.com” set intra-vap-privacy enable set local-switching disable

set external-web “192.168.234.51/portal.php”

next

end

Note that the external-web entry is the URL of the external authentication web server. When this entry is not set, the FortiGate will use the local web server hosting the local login/splash page.

The external web URL is not explicitly set with HTTP/HTTPS – FortiGate uses the auth-secure-http entry under config user setting.

Exemption from the captive portal

A captive portal requires all users on the interface to authenticate. But some devices are not able to authenticate. You can create an exemption list of these devices. For example, a printer might need to access the Internet for firmware upgrades. Using the CLI, you can create an exemption list to exempt all printers from authentication.

config user security-exempt-list edit r_exempt config rule edit <id> set devices printer

end

end

Furthermore, a walled garden firewall policy can be created:

config firewall policy edit <id> set captive-portal-exempt enable …

next

end

MAC Bypass for captive portal

It is possible to provide a MAC address bypass for authenticated clients.When clients are authenticated with bridged SSID and their MAC addresses are known, they are redirected to the External Captive Portal.

A new portal type has been added, under config wireless-controller vap, to provide successful MAC authentication Captive Portal functionality.

Syntax

config wireless-controller vap edit {name} set portal-type {cmcc-macauth}

next

end

MAC-auth-bypass for the captive-portal SSID

Captive-portal SSID supports MAC-auth-bypass. If a client’s MAC can be authenticated from localuser or RADIUS, then the client can bypass firewall authentication directly.

 

config wireless-controller vap edit <name> set security captive-portal set MAC-auth-bypass {enable | disable}

next

end

Customizing captive portal pages

These pages are defined in replacement messages. Defaults are provided. In the web-based manager, you can modify the default messages in the SSID configuration by selecting Customize Portal Messages. Each SSID can have its own unique portal content.

The captive portal contains the following default web pages: l Login page—requests user credentials

Typical modifications for this page would be to change the logo and modify some of the text.

You can change any text that is not part of the HTML code nor a special tag enclosed in double percent (%) characters.

There is an exception to this rule. The line “Please enter your credentials to continue” is provided by the %%QUESTION%% tag. You can replace this tag with text of your choice. Except for this item, you should not remove any tags because they may carry information that the FortiGate unit needs.

  • Login failed page—reports that the entered credentials were incorrect and enables the user to try again.

The Login failed page is similar to the Login page. It even contains the same login form. You can change any text that is not part of the HTML code nor a special tag enclosed in double percent (%) characters.

There is an exception to this rule. The line “Firewall authentication failed. Please try again.” is provided by the %%FAILED_MESSAGE%% tag. You can replace this tag with text of your choice. Except for this item, you should not remove any tags because they may carry information that the FortiGate unit needs.

  • Disclaimer page—is a statement of the legal responsibilities of the user and the host organization to which the user must agree before proceeding.(WiFi or SSL VPN only)
  • Declined disclaimer page—is displayed if the user does not agree to the statement on the Disclaimer page. Access is denied until the user agrees to the disclaimer.

Changing images in portal messages

You can replace the default Fortinet logo with your organization’s logo. First, import the logo file into the FortiGate unit and then modify the Login page code to reference your file.

To import a logo file:

  1. Go to System > Replacement Messages and select Manage Images.
  2. Select Create New.
  3. Enter a Name for the logo and select the appropriate Content Type. The file must not exceed 24 Kilo bytes.
  4. Select Browse, find your logo file and then select Open.
  5. Select OK.

To specify the new logo in the replacement message:

  1. Go to Network > Interfaces and edit the interface. The Security Mode must be Captive Portal.
  2. Select the portal message to edit.
    • In SSL VPN or WiFi interfaces, in Customize Portal Messages click the link to the portal messages that you want to edit.
    • In other interfaces, make sure that Customize Portal Messages is selected, select the adjacent Edit icon, then select the message that you want to edit.
  3. In the HTML message text, find the %%IMAGE tag.

By default it specifies the Fortinet logo: %%IMAGE:logo_fw_auth%%

  1. Change the image name to the one you provided for your logo. The tag should now read, for example, %%IMAGE:mylogo%%
  2. Select Save.
  3. Select OK.

Modifying text in portal messages

Generally, you can change any text that is not part of the HTML code nor a special tag enclosed in double percent (%) characters. You should not remove any tags because they may carry information that the FortiGate unit needs. See the preceding section for any exceptions to this rule for particular pages.

To modify portal page text

  1. Go to System > Network > Interfaces and edit the interface. The SSID Security Mode must be Captive Portal.
  2. Select the portal message to edit.
    • In SSL VPN or WiFi interfaces, in Customize Portal Messages click the link to the portal messages that you want to edit.
    • In other interfaces, make sure that Customize Portal Messages is selected, select the adjacent Edit icon, then select the message that you want to edit.
  3. Edit the HTML message text, then select Save.
  4. Select OK.

Configuring disclaimer page for ethernet interface captive portals

While you can customize a disclaimer page for captive portals that connect via WiFi, the same can be done for wired connections. However, this can only be configured on the CLI Console, and only without configuring user groups.

When configuring a captive portal through the CLI, you may set security-groups to a specific user group. The result of this configuration will show an authentication form to users who wish to log in to the captive portal— not a disclaimer page. If you do not set any security-groups in your configuration, an “Allow all” status will be in effect, and the disclaimer page will be displayed for users.

The example CLI configuration below shows setting up a captive portal interface without setting security-groups, resulting in a disclaimer page for users:

config system interface edit “port1” set vdom “root” set ip 172.16.101.1 255.255.255.0 set allowaccess ping https ssh snmp http set type physical set explicit-web-proxy enable set alias “LAN”

set security-mode captive-portal

set snmp-index 1

next

end

Roaming support

Client devices can maintain captive portal authentication as they roam across different APs. By maintaining a consistent authentication, uninterrupted access to latency sensitive applications such as VoIP is ensured.

The Cloud will push a random per-AP Network encryption key to the AP. The key is 32 bytes in length, and is used in captive portal fast roaming. All APs of an AP Network will use the same encryption key. This key is randomly generated, and will be updated daily.

Session timeout interval for captive portal

The following syntax can be set to configure a session timeout interval in seconds for Captive Portal users. Set the range between 0 – 864000 (or no timeout to ten days). The default is set to 0.

Syntax

config wireless-controller vap edit <name> …

set captive-portal-session-timeout-interval <seconds>

next end

 

Configuration example – captive portal WiFi access control

In this scenario, you will configure the FortiGate for captive portal access so users can log on to your WiFi network.

You will create a user account (rgreen), add it to a user group (employees), create a captive portal SSID (example-staff), and configure a FortiAP unit. When the user attempts to browse the Internet, they will be redirected to the captive portal login page and asked to enter their username and password.

1. Enabling HTTPS authentication

Go to User & Device > Authentication Settings.

Under Protocol Support, enable Redirect HTTP Challenge to a Secure Channel (HTTPS). This will make sure that user credentials are communicated securely through the captive portal.

2. Creating the user

Go to User & Device > User Definition and create a Local user (rgreen).

Create additional users if needed, and assign any authentication methods.

3. Creating the user group

Go to User & Device > User Groups and create a user group (employees).

Add rgreen to the group.

4. Creating the SSID

Go to WiFi & Switch Controller > SSID and configure the wireless network.

Some FortiGate models may show the GUI path as WiFi & Switch Controller.

Enter an Interface Name (example-wifi) and IP/Network Mask.

An address range under DHCP Server will be automatically configured.

Under WiFi Settings, enter an SSID name (example-staff), set Security Mode to Captive Portal, and add the employees user group.

5. Creating the security policy

Go to Policy & Objects > Addresses and create a new address for the SSID (example-wifi-net).

Set Subnet/IP Range to the same range set on the DHCP server in the previous step.

Set Interface to the SSID interface.

Go to Policy & Objects > IPv4 Policy and create a new policy for WiFi users to connect to the Internet.

Add both the example-wifi-net address and employees user group to Source.

6. Connecting and authorizing the FortiAP

Go to Network > Interfaces and edit an available interface.

Under Address, set Addressing mode to Dedicated to Extension Device and assign it an IP address.

Connect the FortiAP unit to the configured interface, then go to WiFi & Switch Controller > Managed FortiAPs.

The FortiAP is listed, but its State shows a greyed-out question mark — this is because it is waiting for authorization.

Highlight the FortiAP and select Authorize.

The question mark is now replaced by a red down-arrow — this is because it is authorized, but still offline.

Go to WiFi & Switch Controller > FortiAP Profiles and edit the profile.

For each radio, enable Radio Resource Provision and select your SSID.

Go back to WiFi & Switch Controller > Managed FortiAPs to verify that the FortiAP unit is online.

7. Results

When a user attempts to connect to the wireless network, they will be redirected to the captive portal login screen.

Members of the employees group must enter their Username and Password. The user will then be redirected to the URL originally requested.

On the FortiGate, go to Monitor > WiFi Client Monitor to verify that the user is authenticated.

 

Supported RFCs

Supported RFCs

FortiOS supports the following RFCs.

BGP

l RFC 4724: Graceful Restart Mechanism for BGP l RFC 4456: BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) l RFC 4360: BGP Extended Communities Attribute l RFC 4271: A Border Gateway Protocol 4 (BGP-4) l RFC 2918: Route Refresh Capability for BGP-4 l RFC 2545: Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing l RFC 2439: BGP Route Flap Damping l RFC 1997: BGP Communities Attribute l RFC 1930: Guidelines for creation, selection, and registration of an Autonomous System (AS) l RFC 1772: Application of the Border Gateway Protocol in the Internet

Cryptography

  • RFC 8031: Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement l RFC 7634: ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec l RFC 7627: Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension l RFC 7539: ChaCha20 and Poly1305 for IETF Protocols l RFC 7427: Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) l RFC 7383: Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation l RFC 7296: Internet Key Exchange Protocol Version 2 (IKEv2) l RFC 7027: Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS) l RFC 6989: Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2)
  • RFC 6954: Using the Elliptic Curve Cryptography (ECC) Brainpool Curves for the Internet Key Exchange Protocol

Version 2 (IKEv2) l RFC 6290: A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE) l RFC 6023: A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA) l RFC 5723: Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption l RFC 5282: Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol

  • RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile l RFC 4754: IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA) l RFC 4635: HMAC SHA TSIG Algorithm Identifiers l RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)

 

DHCP

  • RFC 4478: Repeated Authentication in Internet Key Exchange (IKEv2) Protocol l RFC 4106: The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP) l RFC 3947: Negotiation of NAT-Traversal in the IKE l RFC 3602: The AES-CBC Cipher Algorithm and Its Use with IPsec l RFC 3526: More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE) l RFC 2986: PKCS #10: Certification Request Syntax Specification Version 1.7 l RFC 2845: Secret Key Transaction Authentication for DNS (TSIG) l RFC 2631: Diffie-Hellman Key Agreement Method l RFC 2451: The ESP CBC-Mode Cipher Algorithms l RFC 2410: The NULL Encryption Algorithm and Its Use With IPsec l RFC 2405: The ESP DES-CBC Cipher Algorithm With Explicit IV l RFC 2404: The Use of HMAC-SHA-1-96 within ESP and AH l RFC 2403: The Use of HMAC-MD5-96 within ESP and AH l RFC 2315: PKCS #7: Cryptographic Message Syntax Version 1.5 l RFC 2104: HMAC: Keyed-Hashing for Message Authentication l RFC 2085: HMAC-MD5 IP Authentication with Replay Prevention l RFC 1422: Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management l RFC 1321: The MD5 Message-Digest Algorithm l PKCS #12: PKCS 12 v1: Personal Information Exchange Syntax

DHCP

l RFC 4361: Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4) l RFC 3736: Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 l RFC 3633: IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 l RFC 3456: Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode l RFC 3315: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) l RFC 2132: DHCP Options and BOOTP Vendor Extensions l RFC 2131: Dynamic Host Configuration Protocol

Diffserv

l RFC 3260: New Terminology and Clarifications for Diffserv l RFC 2597: Assured Forwarding PHB Group l RFC 2475: An Architecture for Differentiated Services l RFC 2474: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers 7

DNS

DNS

l RFC 6895: Domain Name System (DNS) IANA Considerations l RFC 6604: xNAME RCODE and Status Bits Clarification l RFC 6147: DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers l RFC 4592: The Role of Wildcards in the Domain Name System l RFC 4035: Protocol Modifications for the DNS Security Extensions l RFC 4034: Resource Records for the DNS Security Extensions l RFC 4033: DNS Security Introduction and Requirements l RFC 3597: Handling of Unknown DNS Resource Record (RR) Types l RFC 3226: DNSSEC and IPv6 A6 aware server/resolver message size requirements l RFC 3007: Secure Domain Name System (DNS) Dynamic Update l RFC 2308: Negative Caching of DNS Queries (DNS NCACHE) l RFC 2181: Clarifications to the DNS Specification l RFC 2136: Dynamic Updates in the Domain Name System (DNS UPDATE) l RFC 1996: A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) l RFC 1995: Incremental Zone Transfer in DNS l RFC 1982: Serial Number Arithmetic l RFC 1876: A Means for Expressing Location Information in the Domain Name System l RFC 1706: DNS NSAP Resource Records l RFC 1183: New DNS RR Definitions l RFC 1101: DNS Encoding of Network Names and Other Types l RFC 1035: Domain Names – Implementation and Specification l RFC 1034: Domain Names – Concepts and Facilities

ICMP

l RFC 6918: Formally Deprecating Some ICMPv4 Message Types l RFC 6633: Deprecation of ICMP Source Quench Messages l RFC 4884: Extended ICMP to Support Multi-Part Messages l RFC 4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification l RFC 1191: Path MTU Discovery l RFC 792: Internet Control Message Protocol

IP

  • RFC 5798: Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6 l RFC 4301: Security Architecture for the Internet Protocol l RFC 3272: Overview and Principles of Internet Traffic Engineering

IP multicast

  • RFC 3168: The Addition of Explicit Congestion Notification (ECN) to IP l RFC 2072: Router Renumbering Guide l RFC 2071: Network Renumbering Overview: Why would I want it and what is it anyway?
  • RFC 1918: Address Allocation for Private Internets l RFC 1123: Requirements for Internet Hosts — Application and Support l RFC 1122: Requirements for Internet Hosts — Communication Layers l RFC 791: Internet Protocol

IP multicast

  • RFC 5059: Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)
  • RFC 4604: Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery

Protocol Version 2 (MLDv2) for Source-Specific Multicast l RFC 3973: Protocol Independent Multicast – Dense Mode (PIM-DM): Protocol Specification (Revised) l RFC 3956: Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address l RFC 3306: Unicast-Prefix-based IPv6 Multicast Addresses l RFC 2365: Administratively Scoped IP Multicast l RFC 1112: Host Extensions for IP Multicasting

IPsec

  • RFC 4304: Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet

Security Association and Key Management Protocol (ISAKMP) l RFC 4303: IP Encapsulating Security Payload (ESP)

  • RFC 3706: A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers

IPv4

l RFC 6864: Updated Specification of the IPv4 ID Field l RFC 5177: Network Mobility (NEMO) Extensions for Mobile IPv4 l RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan l RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses l RFC 3021: Using 31-Bit Prefixes on IPv4 Point-to-Point Links l RFC 1812: Requirements for IP Version 4 Routers

IPv6

l RFC 6343: Advisory Guidelines for 6to4 Deployment l RFC 5175: IPv6 Router Advertisement Flags Option

9

IS-IS

  • RFC 5095: Deprecation of Type 0 Routing Headers in IPv6 l RFC 4941: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 l RFC 4862: IPv6 Stateless Address Autoconfiguration l RFC 4861: Neighbor Discovery for IP version 6 (IPv6) l RFC 4389: Neighbor Discovery Proxies (ND Proxy) l RFC 4213: Basic Transition Mechanisms for IPv6 Hosts and Routers l RFC 4193: Unique Local IPv6 Unicast Addresses l RFC 4007: IPv6 Scoped Address Architecture l RFC 3971: SEcure Neighbor Discovery (SEND) l RFC 3596: DNS Extensions to Support IP Version 6 l RFC 3587: IPv6 Global Unicast Address Format l RFC 3493: Basic Socket Interface Extensions for IPv6 l RFC 3056: Connection of IPv6 Domains via IPv4 Clouds l RFC 3053: IPv6 Tunnel Broker l RFC 2894: Router Renumbering for IPv6 l RFC 2675: IPv6 Jumbograms l RFC 2185: Routing Aspects Of IPv6 Transition
  • RFC 1752: The Recommendation for the IP Next Generation Protocol

IS-IS

l RFC 5310: IS-IS Generic Cryptographic Authentication l RFC 5308: Routing IPv6 with IS-IS l RFC 3359: Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System l RFC 1195: Use of OSI IS-IS for Routing in TCP/IP and Dual Environments

LDAP

  • RFC 4513: Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms l RFC 4512: Lightweight Directory Access Protocol (LDAP): Directory Information Models l RFC 4511: Lightweight Directory Access Protocol (LDAP): The Protocol
  • RFC 3494: Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status

MPLS

  • RFC 7026: Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel l RFC 6426: MPLS On-Demand Connectivity Verification and Route Tracing l RFC 6425: Detecting Data-Plane Failures in Point-to-Multipoint MPLS – Extensions to LSP Ping l RFC 6423: Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP) l RFC 5586: MPLS Generic Associated Channel

 

NAT

  • RFC 5462: Multiprotocol Label Switching (MPLS) Label Stack Entry: “EXP” Field Renamed to “Traffic Class” Field l RFC 5332: MPLS Multicast Encapsulations l RFC 5129: Explicit Congestion Marking in MPLS l RFC 4448: Encapsulation Methods for Transport of Ethernet over MPLS Networks l RFC 4182: Removing a Restriction on the use of MPLS Explicit NULL l RFC 3564: Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering l RFC 3469: Framework for Multi-Protocol Label Switching (MPLS)-based Recovery l RFC 3443: Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks l RFC 3270: Multi-Protocol Label Switching (MPLS) Support of Differentiated Services l RFC 3032: MPLS Label Stack Encoding

NAT

  • RFC 6888: Common Requirements for Carrier-Grade NATs (CGNs) l RFC 6146: Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers l RFC 4966: Reasons to Move the Network Address Translator – Protocol Translator (NAT-PT) to Historic Status l RFC 4787: Network Address Translation (NAT) Behavioral Requirements for Unicast UDP l RFC 4380: Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs) l RFC 3948: UDP Encapsulation of IPsec ESP Packets
  • RFC 3022: Traditional IP Network Address Translator (Traditional NAT)

OSPF

l RFC 6860: Hiding Transit-Only Networks in OSPF l RFC 6845: OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type l RFC 5340: OSPF for IPv6 l RFC 4812: OSPF Restart Signaling l RFC 4811: OSPF Out-of-Band Link State Database (LSDB) Resynchronization l RFC 4203: OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) l RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2 l RFC 3623: Graceful OSPF Restart l RFC 3509: Alternative Implementations of OSPF Area Border Routers l RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option l RFC 2328: OSPF Version 2 l RFC 1765: OSPF Database Overflow l RFC 1370: Applicability Statement for OSPF

PPP

PPP

  • RFC 2516: A Method for Transmitting PPP Over Ethernet (PPPoE) l RFC 2364: PPP Over AAL5
  • RFC 1661: The Point-to-Point Protocol (PPP)

RADIUS

  • RFC 5176: Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) l RFC 2866: RADIUS Accounting
  • RFC 2548: Microsoft Vendor-specific RADIUS Attributes

RIP

l RFC 4822: RIPv2 Cryptographic Authentication l RFC 2453: RIP Version 2 l RFC 2080: RIPng for IPv6 l RFC 1724: RIP Version 2 MIB Extension l RFC 1058: Routing Information Protocol

SIP

l RFC 3960: Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP) l RFC 3325: Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks l RFC 3262: Reliability of Provisional Responses in the Session Initiation Protocol (SIP) l RFC 3261: SIP: Session Initiation Protocol

SNMP

  • RFC 4293: Management Information Base for the Internet Protocol (IP) l RFC 4273: Definitions of Managed Objects for BGP-4 l RFC 4113: Management Information Base for the User Datagram Protocol (UDP) l RFC 4022: Management Information Base for the Transmission Control Protocol (TCP) l RFC 3635: Definitions of Managed Objects for the Ethernet-like Interface Types l RFC 3417: Transport Mappings for the Simple Network Management Protocol (SNMP) l RFC 3416: Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP) l RFC 3414: User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) SSL
  • RFC 3413: Simple Network Management Protocol (SNMP) Applications l RFC 3412: Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) l RFC 3411: An Architecture for Describing Simple Network Management Protocol (SNMP) Management

Frameworks l RFC 3410: Introduction and Applicability Statements for Internet Standard Management Framework l RFC 2863: The Interfaces Group MIB l RFC 2578: Structure of Management Information Version 2 (SMIv2)

  • RFC 1238: CLNS MIB for use with Connectionless Network Protocol (ISO 8473) and End System to Intermediate

System (ISO 9542) l RFC 1215: A Convention for Defining Traps for use with the SNMP l RFC 1213: Management Information Base for Network Management of TCP/IP-based internets: MIB-II l RFC 1212: Concise MIB Definitions l RFC 1157: A Simple Network Management Protocol (SNMP) l RFC 1156: Management Information Base for Network Management of TCP/IP-based internets l RFC 1155: Structure and Identification of Management Information for TCP/IP-based Internets

SSL

l RFC 6176: Prohibiting Secure Sockets Layer (SSL) Version 2.0 l RFC 6101:The Secure Sockets Layer (SSL) Protocol Version 3.0

TCP

l RFC 6691: TCP Options and Maximum Segment Size (MSS) l RFC 6298: Computing TCP’s Retransmission Timer l RFC 6093: On the Implementation of the TCP Urgent Mechanism l RFC 793: Transmission Control Protocol

TLS

l RFC 6347: Datagram Transport Layer Security Version 1.2 l RFC 6066:Transport Layer Security (TLS) Extensions: Extension Definitions l RFC 5746: Transport Layer Security (TLS) Renegotiation Indication Extension l RFC 5425: Transport Layer Security (TLS) Transport Mapping for Syslog l RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2 l RFC 4681: TLS User Mapping Extension l RFC 4680: TLS Handshake Message for Supplemental Data

VPN

VPN

  • RFC 4761: Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling
  • RFC 4684: Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS)

Internet Protocol (IP) Virtual Private Networks (VPNs) l RFC 4577: OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) l RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs)

  • RFC 3715: IPsec-Network Address Translation (NAT) Compatibility Requirements

Other protocols

l RFC 5357: A Two-Way Active Measurement Protocol (TWAMP) l RFC 5214: Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) l RFC 4960: Stream Control Transmission Protocol l RFC 4251: The Secure Shell (SSH) Protocol Architecture l RFC 3435: Media Gateway Control Protocol (MGCP) Version 1.0 l RFC 3376 : Internet Group Management Protocol, Version 3 l RFC 2890: Key and Sequence Number Extensions to GRE l RFC 2784: Generic Routing Encapsulation (GRE) l RFC 2661: Layer Two Tunneling Protocol “L2TP” l RFC 2637: Point-to-Point Tunneling Protocol (PPTP) l RFC 2412: The OAKLEY Key Determination Protocol l RFC 2225: Classical IP and ARP over ATM l RFC 2033: Local Mail Transfer Protocol l RFC 1413: Identification Protocol l RFC 1011: Official Internet Protocols l RFC 862: Echo Protocol l RFC 768: User Datagram Protocol l The TACACS+ Protocol

Miscellaneous

  • RFC 7348: Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2

Networks over Layer 3 Networks l RFC 4784: Verizon Wireless Dynamic Mobile IP Key Update for cdma2000(R) Networks for cdma2000(R) Networks l RFC 4470: Minimally Covering NSEC Records and DNSSEC On-line Signing l RFC 3985: Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture l RFC 2979: Behavior of and Requirements for Internet Firewalls

Miscellaneous

  • RFC 2827: Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address

Spoofing l RFC 2780: IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers l RFC 2647: Benchmarking Terminology for Firewall Performance l RFC 2644: Changing the Default for Directed Broadcasts in Routers l RFC 2231: MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations l RFC 1945: Hypertext Transfer Protocol — HTTP/1.0 l RFC 950: Internet Standard Subnetting Procedure l RFC 894: A Standard for the Transmission of IP Datagrams over Ethernet Networks

Security best practices

Security best practices

This chapter describes some techniques and best practices that you can use to improve FortiOS security.

Install the FortiGate unit in a physically secure location

A good place to start with is physical security. Install your FortiGate in a secure location, such as a locked room or one with restricted access. A restricted location prevents unauthorized users from getting physical access to the device.

If unauthorized users have physical access, they can disrupt your entire network by disconnecting your FortiGate (either by accident or on purpose). They could also connect a console cable and attempt to log into the CLI. Also, when a FortiGate unit reboots, a person with physical access can interrupt the boot process and install different firmware.

Register your product with Fortinet Support

You need to register your Fortinet product with Fortinet Support to receive customer services, such as firmware updates and customer support. You must also register your product for FortiGuard services, such as up-to-date antivirus and IPS signatures. To register your product the Fortinet Support website.

Keep your FortiOS firmware up to date

Always keep FortiOS up to date. The most recent version is the most stable and has the most bugs fixed and vulnerabilities removed. Fortinet periodically updates the FortiGate firmware to include new features and resolve important issues.

After you register your FortiGate, you can receive notifications on FortiGate GUI about firmware updates. You can update the firmware directly from the GUI or by downloading firmware updates from the Fortinet Support website.

Before you install any new firmware, be sure to follow these steps:

  • Review the release notes for the latest firmware release.
  • Review the Supported Upgrade Paths guide to determine the best path to take from your current version of FortiOS to the latest version.
  • Back up the current configuration.

Only FortiGate administrators who have read and write privileges can upgrade the FortiOS firmware.

System administrator best practices

This section describes a collection of changes you can implement to make administrative access to the GUI and CLI more secure.

Disable administrative access to the external (Internet-facing) interface

When possible, don’t allow administration access on the external (Internet-facing) interface.

To disable administrative access, go to Network > Interfaces, edit the external interface and disable HTTPS, PING, HTTP, SSH, and TELNET under Administrative Access.

From the CLI:

config system interface edit <external-interface-name> unset allowaccess

end

Allow only HTTPS access to the GUI and SSH access to the CLI

For greater security never allow HTTP or Telnet administrative access to a FortiGate interface, only allow HTTPS and SSH access. You can change these settings for individual interfaces by going to Network > Interfaces and adjusting the administrative access to each interface.

From the CLI:

config system interface edit <interface-name> set allowaccess https ssh

end

Require TLS 1.2 for HTTPS administrator access

Use the following command to require TLS 1.2 for HTTPS administrator access to the GUI:

config system global set admin-https-ssl-versions tlsv1-2

end

TLS 1.2 is currently the most secure SSL/TLS supported version for SSL-encrypted administrator access.

Re-direct HTTP GUI logins to HTTPS

Go to System > Settings > Administrator Settings and enable Redirect to HTTPS to make sure that all attempted HTTP login connections are redirected to HTTPS.

From the CLI:

config system global set admin-https-redirect enable end

 

Change the HTTPS and SSH admin access ports to non-standard ports

Go to System > Settings > Administrator Settings and change the HTTPS and SSH ports.

You can change the default port configurations for HTTPS and SSH administrative access for added security. To connect to a non-standard port, the new port number must be included in the collection request. For example:

l If you change the HTTPS port to 7734, you would browse to https://<ip-address>:7734. l If you change the SSH port to 2345, you would connect to ssh admin@<ip-address>:2345 To change the HTTPS and SSH login ports from the CLI:

config system global set admin-sport 7734 set admin-ssh-port 2345

end

If you change to the HTTPS or SSH port numbers, make sure your changes do not conflict with ports used for other services.

Maintain short login timeouts

Set the idle timeout to a short time to avoid the possibility of an administrator walking away from their management computer and leaving it exposed to unauthorized personnel.

To set the administrator idle timeout, go to System > Settings and enter the amount of time for the Idle timeout. A best practice is to keep the default time of 5 minutes.

To set the administrator idle timeout from the CLI:

config system global set admintimeout 5

end

You can use the following command to adjust the grace time permitted between making an SSH connection and authenticating. The range can be between 10 and 3600 seconds, the default is 120 seconds (minutes). By shortening this time, you can decrease the chances of someone attempting a brute force attack a from being successful. For example, you could set the time to 30 seconds.

config system global set admin-ssh-grace-time 30

end

Restrict logins from trusted hosts

Setting up trusted hosts for an administrator limits the addresses from where they can log into FortiOS. The trusted hosts configuration applies to most forms of administrative access including HTTPS, SSH, and SNMP. When you identify a trusted host for an administrator account, FortiOS accepts that administrator’s login only from one of the trusted hosts. A login, even with proper credentials, from a non-trusted host is dropped.

System administrator best practices

To identify trusted hosts, go to System > Administrators, edit the administrator account, enable Restrict login to trusted hosts, and add up to ten trusted host IP addresses.

To add two trusted hosts from the CLI:

config system admin edit <administrator-name> set trustedhost1 172.25.176.23 255.255.255.255 set trustedhost2 172.25.177.0 255.255.255.0

end

Trusted host IP addresses can identify individual hosts or subnets. Just like firewall policies, FortiOS searches through the list of trusted hosts in order and acts on the first match it finds. When you configure trusted hosts, start by adding specific addresses at the top of the list. Follow with more general IP addresses. You don’t have to add addresses to all of the trusted hosts as long as all specific addresses are above all of the 0.0.0.0 0.0.0.0 addresses.

Set up two-factor authentication for administrators

FortiOS supports FortiToken and FortiToken Mobile 2-factor authentication. FortiToken Mobile is available for iOS and Android devices from their respective application stores.

Every registered FortiGate unit includes two trial tokens for free. You can purchase additional tokens from your reseller or from Fortinet.

To assign a token to an administrator, go to System > Administrators and select Enable Two-factor Authentication for each administrator.

Create multiple administrator accounts

Rather than allowing all administrators to access ForiOS with the same administrator account, you can create accounts for each person or each role that requires administrative access. This configuration allows you to track the activities of each administrator or administrative role.

If you want administrators to have different functions you can add different administrator profiles. Go to System > Admin Profiles and select Create New.

Modify administrator account lockout duration and threshold values

By default, the FortiGate sets the number of password retries at three, allowing the administrator a maximum of three attempts to log into their account before locking the account for a set amount of time.

Both the number of attempts (admin-lockout-threshold) and the wait time before the administrator can try to enter a password again (admin-lockout-duration) can be configured within the CLI.

To configure the lockout options:

config system global set admin-lockout-threshold <failed_attempts> set admin-lockout-duration <seconds>

end

The default value of admin-lockout-threshold is 3 and the range of values is between 1 and 10. The admin-lockout-duration is set to 60 seconds by default and the range of values is between 1 and 4294967295 seconds.

Global commands for stronger and more secure encryption

Keep in mind that the higher the lockout threshold, the higher the risk that someone may be able to break into the FortiGate.

Example:

To set the admin-lockout-threshold to one attempt and the admin-lockout-duration to a five minute duration before the administrator can try to log in again, enter the commands:

config system global set admin-lockout-threshold 1 set admin-lockout-duration 300 end

If the time span between the first failed login attempt and the admin-lockoutthreshold failed login attempt is less than admin-lockout-duration, the lockout will be triggered.

Rename the admin administrator account

You can improve security by renaming the admin account. To do this, create a new administrator account with the super_admin admin profile and log in as that administrator. Then go to System > Administrators and edit the admin administrator and change the User Name. Renaming the admin account makes it more difficult for an attacker to log into FortiOS.

Add administrator disclaimers

FortiOS can display a disclaimer before or after logging into the GUI or CLI (or both). In either case the administrator must read and accept the disclaimer before they can proceed.

Use the following command to display a disclaimer before logging in:

config system global set pre-login-banner enable

end

Use the following command to display a disclaimer after logging in:

config system global set post-login-banner enable

end

You can customize the replacement messages for these disclaimers by going to System > Replacement Messages. Select Extended View to view and edit the Administrator replacement messages.

From the CLI:

config system replacemsg admin pre_admin-disclaimer-text config system replacemsg admin post_admin-disclaimer-text

Global commands for stronger and more secure encryption

This section describes some best practices for employing stronger and more secure encryption.

Disable sending malware statistics to FortiGuard

Turn on global strong encryption

Enter the following command to configure FortiOS to use only strong encryption and allow only strong ciphers (AES, 3DES) and digest (SHA1) for HTTPS, SSH, TLS, and SSL functions.

config sys global set strong-crypto enable

end

Disable MD5 and CBC for SSH

In some cases, you may not be able to enable strong encryption. For example, your FortiGate may be communicating with a system that does not support strong encryption. With strong-crypto disabled you can use the following options to prevent SSH sessions with the FortiGate from using less secure MD5 and CBC algorithms:

config sys global set ssh-hmac-md5 disable set ssh-cbc-cipher disable

end

Disable static keys for TLS

You can use the following command to prevent TLS sessions from using static keys (AES128-SHA, AES256-SHA, AES128-SHA256, AES256-SHA256):

config sys global set ssl-static-key-ciphers disable

end

Require larger values for Diffie-Hellman exchanges

Larger Diffie-Hellman values result in stronger encryption. Use the following command to force Diffie-Hellman exchanges to use 8192 bit values (the highest configurable DH value).

config sys global set dh-params 8192

end

Disable sending malware statistics to FortiGuard

By default FortiOS periodically sends encrypted malware statistics to FortiGuard. The malware statistics record Antivirus, IPS, or Application Control events. This data is used to improved FortiGuard services. The malware statistics that FortiOS sends do not include any personal or sensitive customer data. The information is not shared with any external parties and is used in accordance with Fortinet’s Privacy Policy.

To disable sending malware statistics to FortiGuard, enter the following command: config system global set fds-statistics disable

end

Disable sending Security Rating statistics to FortiGuard

Security Rating is a Fortinet Security Fabric feature that allows customers to audit their Security Fabric and find and fix security problems. As part of the feature, FortiOS sends your security rating to FortiGuard every time a security rating test runs.

You can opt out of submitting Security Rating scores to FortiGuard. If you opt out you won’t be able to see how your organization’s scores compare with the scores of other organizations. Instead, an absolute score is shown. Use the following command to disable FortiGuard Security Rating result submission:

config system global set fortiguard-audit-result-submission disable

end

Disable auto USB installation

If USB installation is enabled, an attacker with physical access to a FortiGate could load a new configuration or firmware on the FortiGate using the USB port. You can disable USB installation by entering the following from the CLI:

config system auto-install set auto-install-config disable set auto-install-image disable

end

Set system time by synchronizing with an NTP server

For accurate time, use an NTP server to set system time. Synchronized time facilitates auditing and consistency between expiry dates used in expiration of certificates and security protocols.

From the GUI go to System > Settings > System Time and select Synchronize with NTP Server. By default, this causes FortiOS to synchronize with Fortinet’s FortiGuard secure NTP server.

From the CLI you can use one or more different NTP servers:

config system ntp set type custom set ntpsync enable config ntpserver edit 1 set server <ntp-server-ip>

next edit 2 set server <other-ntp-server-ip> end

Disable the maintainer admin account

Administrators with physical access to a FortiGate appliance can use a console cable and a special administrator account called maintainer to log into the CLI without a password. This feature allows you to log into a FortiGate if you have lost all administrator passwords. See Resetting a lost Admin password on the Fortinet Cookbook for details.

The maintainer account can be disabled using the following command:

config system global set admin-maintainer disable

end

Enable password policies

Go to System > Settings > Password Policy, to create a password policy that all administrators must follow. Using the available options you can define the required length of the password, what it must contain (numbers, upper and lower case, and so on) and an expiry time.

Use the password policy feature to make sure all administrators use secure passwords that meet your organization’s requirements.

Configure auditing and logging

For optimum security go to Log & Report > Log Settings enable Event Logging. For best results send log messages to FortiAnalyzer or FortiCloud.

From FortiAnalyzer or FortiCloud, you can view reports or system event log messages to look for system events that may indicate potential problems. You can also view system events by going to FortiView > System Events.

Establish an auditing schedule to routinely inspect logs for signs of intrusion and probing.

Encrypt logs sent to FortiAnalyzer/FortiManager

To keep information in log messages sent to FortiAnalyzer private, go to Log & Report > Log Settings and when you configure Remote Logging to FortiAnalyzer/FortiManager select Encrypt log transmission.

From the CLI.

config log {fortianalyzer | fortianalyzer2 | fortianalyzer3} setting set enc-algorithm high end

Disable unused interfaces

To disable an interface from the GUI, go to Network > Interfaces. Edit the interface to be disabled and set Interface State to Disabled.

From the CLI, to disable the port21 interface:

config system interface edit port21 set status down

end

Disable unused protocols on interfaces

You can use the config system interface command to disable unused protocols that attackers may attempt to use to gather information about a FortiGate unit. Many of these protocols are disabled by default. Using the config system interface command you can see the current configuration of each of these options for the selected interface and then choose to disable them if required.

config system interface edit <interface-name> set dhcp-relay-service disable set pptp-client disable set arpforward disable set broadcast-forward disable set l2forward disable set icmp-redirect disable set vlanforward disable set stpforward disable set ident-accept disable set ipmac disable set netbios-forward disable set security-mode none set device-identification disable set lldp-transmission disable end

Option Description
dhcp-relay-service Disable the DHCP relay service.
pptp-client Disable operating the interface as a PPTP client.
arpforward Disable ARP forwarding.
broadcast-forward Disable forwarding broadcast packets.
l2forward Disable layer 2 forwarding.
icmp-redirect Disable ICMP redirect.

 

Option Description
vlanforward Disable VLAN forwarding.
stpforward Disable STP forwarding.
ident-accept Disable authentication for this interface. The interface will not respond to a connection with an authentication prompt.
ipmac Disable IP/MAC binding.
netbios-forward Disable NETBIOS forwarding.
security-mode Set to none to disable captive portal authentication. The interface will not respond to a connection with a captive portal.
device-identification Disable device identification.
lldp-transmission Disable link layer discovery (LLDP).

Use local-in policies to close open ports or restrict access

You can also use local-in policies to close open ports or otherwise restrict access to FortiOS.

Close ICMP ports

Use the following command to close all ICMP ports on the WAN1 interface. The following example blocks traffic that matches the ICMP_ANY firewall service.

config firewall local-in-policy edit 1 set intf wan1 set scraddr all set dstaddr all set action deny set service ICMP_ANY set schedule always

end

Close the BGP port

Use the following command to close the BGP port on the wan1 interface. The following example blocks traffic that matches the BGP firewall service.

config firewall local-in-policy edit 1 set intf wan1 set scraddr all set dstaddr all

Use local-in policies to close open ports or restrict access

set action deny set service BGP set schedule always end