Configure an MCLAG with managed FortiSwitches (366617)

To configure a multichassis LAG (MCLAG) with managed FortiSwitches:

1. For each MCLAG peer switch, log into the FortiSwitch to create a LAG:

config switch trunk edit “LAG-member” set mode lacp-active set mclag-icl enable set members “<port>” “<port>”

next

2. Enable the MCLAG on each managed FortiSwitch:

config switch-controller managed-switch edit “<switch-id>” config ports edit “<trunk name>” set type trunk

set mode {static | lacp-passive | lacp-active} set bundle {enable | disable}

set members “<port>,<port>” set mclag {enable | disable}

next

end

next

3. Log into each managed FortiSwitch to check the MCLAG configuration:

diagnose switch mclag

After the FortiSwitches are configured as MCLAG peer switches, any port that supports advanced features on the FortiSwitch can become a LAG port. When mclag is enabled and the LAG port names match, an MCLAG peer set is automatically formed. The member ports for each FortiSwitch in the MCLAG do not need to be identical to the member ports on the peer FortiSwitch.

Override the admin password for all managed FortiSwitches (416261)

By default, each FortiSwitch has an admin account without a password. To replace the admin passwords for all FortiSwitches managed by a FortiGate, use the following commands:

config switch-controller switch-profile edit default set login-passwd-override {enable | disable} set login-passwd <password>

next

end

If you had already applied a profile with the override enabled and the password set and then decide to remove the admin password, you need to apply a profile with the override enabled and use the unset login-passwd command; otherwise, your previously set password will remain in the FortiSwitch.

Enable and disable switch-controller access VLANs through FortiGate (406718)

Access VLANs are VLANs that aggregate client traffic solely to the FortiGate. This prevents direct client-to-client traffic visibility at the layer-2 VLAN layer. Clients can only communicate with the FortiGate. After the client traffic reaches the FortiGate, the FortiGate can then determine whether to allow various levels of access to the client by shifting the client’s network VLAN as appropriate.

config system interface edit <VLAN name> set switch-controller-access-vlan {enable | disable}

next

end

Assign untagged VLANs to a managed FortiSwitch port (410828)

Use the following commands to assign untagged VLANs to a managed FortiSwitch port:

config switch-controller managed-switch edit <managed-switch> config ports edit <port> set untagged-vlans <VLAN-name>

next

end

next

end

View, create, and assign multiple 802.1X policy definitions (408389 and 403901)

Previously, you could create one 802.1X policy for all managed FortiSwitches in a virtual domain. Now, you can create multiple 802.1X policies and assign a different 802.1X policy to each managed FortiSwitch port.

View security policies for managed FortiSwitches

You can view security policies for managed FortiSwitches in two places:

• Go to WiFi & Switch Controller > FortiSwitch Security Policies.
• Go to WiFi & Switch Controller > FortiSwitch Ports and click the + next to a FortiSwitch. The security policy for each port is listed in the Security Policy column.

Create and assign multiple 802.1X policy definitions for managed FortiSwitches

Previously, you could create one 802.1X policy for all managed FortiSwitches in a virtual domain. Now, you can create multiple 802.1X policies and assign a different 802.1X policy to each managed FortiSwitch port.

To create an 802.1X security policy:

1. Go to WiFi & Switch Controller > FortiSwitch Security Policies.
2. Click Create New.
3. Enter a name for the new FortiSwitch security policy.
4. For the security mode, select Port-based or MAC-based.
5. Click + to select which user groups will have access.
6. Enable or disable guest VLANs on this interface to allow restricted access for some users.
7. Enter the number of seconds for authentication delay for guest VLANs. The range is 60-900 seconds.
8. Enable or disable authentication fail VLAN on this interface to allow restricted access for users who fail to access the guest VLAN.
9. Enable or disable MAC authentication bypass (MAB) on this interface.
10. Enable or disable EAP pass-through mode on this interface.
11. Enable or disable whether the session timeout for the RADIUS server will overwrite the local timeout.
12. Click OK.

To apply an 802.1X security policy to a managed FortiSwitch port:

1. Go to WiFi & Switch Controller > FortiSwitch Ports.
2. Click the + next to a FortiSwitch.
3. In the Security Policy column for a port, click + to select a security policy.
4. Click OK to apply the security policy to that port.

Override 802.1X settings

To override the 802.1X settings for a virtual domain:

1. Go to WiFi & Switch Controller > Managed FortiSwitch.
2. Click on a FortiSwitch faceplate and click Edit.
3. In the Edit Managed FortiSwitch page, move the Override 802-1X settings slider to the right.
4. In the Reauthentication Interval field, enter the number of minutes before reauthentication is required. The maximum interval is 1,440 minutes. Setting the value to 0 minutes disables reauthentication.
5. In the Max Reauthentication Attempts field, enter the maximum times that reauthentication is attempted. The maximum number of attempts is 15. Setting the value to 0 disables reauthentication.
6. Select Deauthenticate or None for the link down action. Selecting Deauthenticate sets the interface to unauthenticated when a link is down, and reauthentication is needed. Selecting None means that the interface does not need to be reauthenticated when a link is down.
7. Click OK.

Quarantines (410828)

Quarantined MAC addresses are blocked on the connected FortiSwitches from the network and the LAN.

NOTE: You must enable the quarantine feature in the FortiGate CLI using the set quarantine enable command. You can add MAC addresses to the quarantine list before enabling the quarantine feature, but the quarantine does not go into effect until enabled.

Quarantining a MAC address

Using the FortiGate GUI

1. Select the host to quarantine.
   • Go to Security Fabric > Physical Topology, right-click on a host, and select Quarantine Host on FortiSwitch.
   • Go to Security Fabric > Logical Topology, right-click on a host, and select Quarantine Host on FortiSwitch.
   • Go to FortiView > Sources, right-click on an entry in the Source column, and select Quarantine Host on FortiSwitch.
2. Click OK to confirm that you want to quarantine the host.

Using the FortiGate CLI

config switch-controller quarantine set quarantine enable edit <MAC_address> set description <string>

set tags <tag1 tag2 tag3 …>

next

next

end

Viewing quarantine entries

Quarantine entries are created on the FortiGate that is managing the FortiSwitch.

Using the FortiGate GUI

1. Go to Monitor > Quarantine Monitor.
2. Click Quarantined on FortiSwitch.

Using the FortiGate CLI

Use the following command to view the quarantine list of MAC addresses: show switch-controller quarantine

When the quarantine feature is enabled on the FortiGate, it creates a quarantine VLAN (qtn.<FortiLink_port_ name>) on the virtual domain. The quarantine VLAN is applied to the allowed and untagged VLANs on all connected FortiSwitch ports.

Use the following command to view the quarantine VLAN: show system interface qtn.<FortiLink_port_name>

Use the following command to view how the quarantine VLAN is applied to the allowed and untagged VLANs on all connected FortiSwitch ports:

show switch-controller managed-switch

Releasing MAC addresses from quarantine

Using the FortiGate GUI

1. Go to Monitor > Quarantine Monitor.
2. Click Quarantined on FortiSwitch.
3. Right-click on one of the entries and select Delete or Remove All.
4. Click OK to confirm your choice.

Using the FortiGate CLI

Use the following commands to delete a quarantined MAC address:

config switch-controller quarantine config targets delete <MAC_address>

end

When the quarantine feature is disabled, all quarantined MAC addresses are released from quarantine. Use the following commands to disable the quarantine feature:

config switch-controller quarantine set quarantine disable

end

Managed FortiSwitch OS 3.6.0 (FortiOS 5.6.1)

New managed FortiSwitch features added to FortiOS 5.6.1 if the FortiSwitch is running FortiSwitch OS 3.6.0.

Simplified method to convert a FortiSwitch to standalone mode (393205)

There is an easier way to convert a FortiSwitch from FortiLink mode to standalone mode so that it will no longer be managed by a FortiGate:

• execute switch-controller factory-reset <switch-id>

This command returns the FortiSwitch to the factory defaults and then reboots the FortiSwitch. If the FortiSwitch is configured for FortiLink auto-discovery, FortiGate can detect and automatically authorize the FortiSwitch.

• execute switch-controller set-standalone <switch-id>

This command returns the FortiSwitch to the factory defaults, reboots the FortiSwitch, and prevents the FortiGate from automatically detecting and authorizing the FortiSwitch.

You can disable FortiLink auto-discovery on multiple FortiSwitches using the following commands:

config switch-controller global set disable-discovery <switch-id>

end

You can also add or remove entries from the list of FortiSwitches that have FortiLink auto-discovery disabled using the following commands:

config switch-controller global append disable-discovery <switch-id> unselect disable-discovery <switch-id>

end

Support HTTP policy for flow-based inspection (411666)

It is possible to impliment an HTTP-policy in a VDOM that is using the Flow-based inspection mode. Enabling the HTTP-policy causes the traffic to be redirected to WAD so that the traffic can be properly matched and processed.

NGFW mode in the VDOM – NAT & SSL Inspection considerations (407547)

Due to how the NGFW Policy mode works, it can get complicated in the two areas of NAT and SSL Deep

Inspection. To match an application against a policy, some traffic has to pass through the FortiGate in order to be properly identified. Once that happens may end up getting mapped to a different policy, where the new policy will be appropriately enforced.

NAT

In the case of NAT being used, the first policy that is triggered to identify the traffic might require NAT enabled for it to work correctly. i.e., without NAT enabled it may never be identified, and thus not fall through. Let’s use a very simple example:

Policy 1: Block Youtube

Policy 2: Allow everything else (with NAT enabled)

Any new session established will never be identified immediately as Youtube, so it’ll match policy #1 and let some traffic go to try and identify it. Without NAT enabled to the Internet, the session will never be setup and thus stuck here.

Solution:

• NAT for NGFW policies must be done via Central SNAT Map l Central SNAT Map entries now have options for ‘srcintf’, ‘dstintf’ and ‘action’. l If no IP-pools are specified in the Central SNAT entry, then the outgoing interface address will be used.
• NGFW policies now must use a single default ssl-ssh-profile. The default ssl-ssh-profile can be configured under the system settings table.

SSL

In the case of SSL inspection, the issue is a bit simpler. For each policy there are 3 choices:

1. No SSL,
2. Certificate Only
3. Deep Inspection.

For 1. and 2. there is no conflict and the user could enable them inter-changeably and allow policy fallthrough.

The issue happens when:

• The first policy matched, uses Certificate Only
• After the application is detected, it re-maps the session to a new policy which has Deep Inspection enabled This switching of behavior is the main cause of the issue.

Solution:

• Multiple SSL profiles have been replaced with a single page of settings l The user can setup exemptions for destination web category, source IP or etc.

CLI

Changes

config system settings set inspection-mode flow set policy-mode [standard | ngfw]

Has been changed to:

config system settings set inspection-mode flow

set ngfw-mode [profile-based | policy-based]

l ngfw-mode – Next Generation Firewall mode. l profile-based – Application and web-filtering is configured using profiles applied to policy entries. l policy-based – Application and web-filtering is configured as policy match conditions.

Additions

Setting the vdom default ssl-ssh-profile

config system settings set inspection-mode flow set ngfw-mode policy-based set ssl-ssh-profile <profile> ssl-ssh-profile – VDOM SSL SSH profile.

Setting srcintf, dstintf, action on the central-snat policy

config firewall central-snat-map edit <id> set srcintf <names or any> set dstintf <names or any> set action (permit | deny)

l srcintf – Source interface name. l dstintf – Destination interface name. l action – Action of central SNAT policy.

GUI

System settings, VDOM settings list/dialog: l A field has been added to show the default ssl-ssh-profile IPv4/v6 Policy list and dialogs:

• In NGFW policy-based mode, there are added tool tips under NAT columns/fields to indicate that NAT must be configured via Central SNAT Map. Additionally, links to redirect to Central SNAT list were added.
• Default ssl-ssh-profile is shown in the policy list and dialog for any policies doing NGFW (`application, application-categories, url-categories`) or UTM (`av-profile etc.) inspection. l Default ssl-ssh-profile is disabled from editing in policy list dialog Central SNAT Policy list and dialogs:
• In both profile-based & policy-basedngfw-mode, fields for srcintf, dstintf were added to Central

SNAT policies entries.

• In policy-based mode only, a toggle-switch for NAT Action was added in Central SNAT policy dialog. The action is also configurable from the Action column in Central SNAT policy list.

SSL/SSH Inspection list:

• In policy-based mode only, the navigation bar link to SSL/SSH Inspection redirects to the profiles list l In policy-based mode only, the SSL/SSH Inspection list table indicates which profile is the current VDOM default.

Additionally, options are provided in the list menu and context menu to change the current VDOM default.