Category Archives: FortiOS 5.6

What’s new in FortiOS 5.6 IPSec

What’s new in FortiOS 5.6

This chapter describes new IPsec VPN features added to FortiOS 5.6.0 and FortiOS 5.6.1.

FortiOS 5.6.1

These features first appeared in FortiOS 5.6.1.

Support for Brainpool curves specified in RFC 6954 for IKE (412795)

Added support for Brainpool curves specified in RFC 6954 (originally RFC 5639) for IKE. Four new values are added for VPN phase1 and phase2 DH groups.

The allocated transform IDs are 27, 28, 29, 30:

  • 27 – Brainpool 224-Bit Curve
  • 28 – Brainpool 256-Bit Curve
  • 29 – Brainpool 384-Bit Curve
  • 30 – Brainpool 512-Bit Curve

Syntax

config vpn ipsec phase1/phase1-interface edit <name> set dhgrp {1 | 2 | 5 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 27 | 28 | 29 | 30}

next

end

config vpn ipsec phase2/phase2-interface edit <name> set dhgrp {1 | 2 | 5 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 27 | 28 | 29 | 30}

next

end

Removed “exchange-interface-ip” option from “vpn ipsec phase1” (411981)

The command exchange-interface-ip only works for interface-based IPsec VPN (vpn ipsec phase1interface), and so it has been removed from policy-based IPsec VPN (vpn ipsec phase1).

IKEv2 ancillary RADIUS group authentication (406497)

This feature provides for the IDi information to be extracted from the IKEv2 AUTH exchange and sent to a RADIUS server, along with a fixed password configurable via CLI, to perform an additional group authentication step prior to tunnel establishment. The RADIUS server may return framed-IP-address, framed-ip-netmask, and dns-server attributes, which are then applied to the tunnel.

 

5.6.1

It should be noted, unlike Xauth or EAP, this feature does not perform individual user authentication, but rather treats all users on the gateway as a single group, and authenticates that group with RADIUS using a fixed password. This feature also works with RADIUS accounting, including the phase1 acct-verify option.

Syntax

config vpn ipsec phase1-interface edit <name> set mode-cfg enable set type dynamic set ike-version 2

set group-authentication {enable | disable} set group-authentication-secret <password>

next

end

IPsec mode-cfg can assign IPs from firewall address and sharing IP pools (393331)

This feature adds the ability for users to configure assign-IPs from firewall addresses/groups.

Previously, different policies accessing the same network needed to ensure that non-overlapping IP-ranges were assigned to policies to avoid the same IP address being assigned to multiple clients. With this feature, the address name is used to identify an IP pool and different policies can refer to the same IP pool to check for available IPs, thus simplifying the task of avoiding IP conflicts.

Syntax

config vpn ipsec phase1-interface edit <name> set mode-cfg enable set type dynamic

set assign-ip-from {range | dhcp | name} set ipv4-name <name> set ipv6-name <name>

next

end

Improve interface-based dynamic IPsec up/down time (379937)

This feature makes it possible to use a single interface for all instances that spawn via a given phase1. Instead of creating an interface per instance, all traffic will run over the single interface and any routes that need creating will be created on that single interface.

A new CLI option net-device is added in the phase1-interface command sets. The default is disable so that the new feature kicks in for all the new configurations. An upgrade feature will add a set net-device enable for all the existing configurations so that they will keep the old behavior.

Under the new single-interface scheme, instead of relying on routing to guide traffic to the specific instance, all traffic will flow to the specific device and IPsec will need to take care of locating the correct instance for outbound traffic. For this purpose, another new CLI option tunnel-search is created. The option is only available when the above net-device option is set to disable.

There are two options for tunnel-search, corresponding to the two ways to select the tunnel for outbound traffic. One is selectors, meaning selecting a peer using the IPsec selectors (proxy-ids). The other is

5.6.1

nexthop where all the peers use the same default selectors (0/0) while using some routing protocols such as BGP, OSPF, RIPng, etc. to resolve the routing. The default for tunnel-search is selectors.

Syntax

config vpn ipsec phase1-interface edit <name> set net-device {enable | disable} set tunnel-search {selectors | nexthop}

next

end

Hide psksecret option when peertype is dialup (415480)

In aggressive mode and IKEv2, when peertype is dialup, pre-shared key is per-user based. There is no need to configure the psksecret in the phase1 setup. Previously, if left unconfigured, CLI would output psksecret error and fail to create the phase1 profile.

To prevent psksecret length check running on the configuration end, the psksecret option will be hidden. Prior to Mantis 397712, the length check passed because it was incorrectly checking the legnth of encrypted password which is always 204 length long.

Peertype dialup option removed for main mode.

New enforce-ipsec option added to L2TP config (423988)

A new enforce-ipsec option is added in L2TP configuration to force the FortiGate L2TP server to accept only IPsec encrypted connections.

Syntax

config vpn l2tp set eip 50.0.0.100 set sip 50.0.0.1 set status enable

set enforce-ipsec-interface {disable | enable}      (default = disable) set usrgrp <group_name>

end

IPsec VPN Wizard improvements (368069)

Previously, when using wan-load-balance (WLB) feature, and when configuring an IPsec tunnel with the wizard, the setting ‘incoming interface’ list does not contain the wan-load-balance nor the wan2 interface. Disabling the WLB permits the configuration.

The solution in 5.6.1 is as follows:

  • (368069) The IPsec VPN wizard now allows users to select members of virtual-wan-link (VWL) as IPsec phase1interface. Before saving, if the phase1 interface is a VWL member, then the Wizard automatically sets the virtualwan-link as the destination interface in the L2TP policy.
  • (246552) List VPN tunnels for VWL members if VWL is set as the destination interface in policy-based IPsec VPN.

IPsec manual key support removed from GUI (436041)

The majority of customers are not using policy-based IPsec today, and beyond that, very few are using manual key VPN. As a result, the IPsec manual key feature is removed from the GUI; the feature store option is removed as well.

Added GUI support for local-gw when configuring custom IPsec tunnels (423786)

Previously, the local-gw option was not available on the GUI when configuring a custom IPsec tunnel. This feature adds the local-gw setting to the IPsec VPN Edit dialog. The user is able to choose the primary or secondary IP address from the currently selected interface, or specify an ip address manually. Both local-gw and local-gw6 are supported.

Moved the dn-format CLI option from phase1 config to vdom settings (435542)

Previous fix for dn-format didn’t take into account that, at the time isakmp_set_peer_identifier is used, we don’t have a connection and haven’t matched our gateway yet, so we can’t use that to determine the dn-format configuration setting.

The solution was to move the dn-format CLI option from phase1 config to vdom settings. It is renamed to ike-dn-format.

FGT IKE incorrect NAT detection causes ADVPN hub behind VIP to not generate shortcuts (416786)

When ADVPN NAT support was added, only spokes behind NAT was considered. No thought was given to a hub behind a VIP or the problems that occurred due to the way that FortiOS clients behind NAT enable NAT-T even when it is not required.

The solution in 5.6.1 is as follows:

  • Moved shortcut determination out of the kernel and up to IKE. The shortcut message now contains the ID of both tunnels so that IKE can check the NAT condition of both.
  • Added IKE debug to cover sending the initial shortcut query. The lack of this previously meant it could be awkard to determine if the offer had been converted into a query correctly.
  • Added “nat:” output in diag vpn ike gateway list output to indicate whether this device or the peer is behind NAT.
  • Tweaked the diag vpn tunnel list output so that the auto-discovery information now includes symbolic as well as numeric values, which makes it easier to see what type of auto-discovery was enabled.

FortiOS 5.6.0

These features first appeared in FortiOS 5.6.0.

5.6.0

Improvement to stats crypto command output (403995)

The CLI command get vpn ipsec stats crypto now has a better format for the information it shows in differentiating between NP6 lite and SOC3 (CP). To further avoid confusion, all engine’s encryption (encrypted/decrypted) and integrity (generated/validated) information is shown under the same heading, not separate headings.

Improved certificate key size control commands (397883)

Proxy will choose the same SSL key size as the HTTPS server. If the key size from the server is 512, the proxy will choose 1024. If the key size is bigger than 1024, the proxy will choose 2048.

As a result, the firewall ssl-ssh-profile commands certname-rsa, certname-dsa, and certname-ecdsa have been replaced with more specific key size control commands under vpn certificate setting.

CLI syntax

config vpn certificate setting set certname-rsa1024 <name> set certname-rsa2048 <name> set certname-dsa1024 <name> set certname-dsa2048 <name> set certname-ecdsa256 <name> set certname-ecdsa384 <name>

end

Support bit-based keys in IKE (397712)

As per FIPS-CC required standards, as well as RFC 4306, IKE supports pre-shared secrets to be entered as both ASCII string values and as hexadecimal encoded values. This feature parses hex encoded input (indicated by the leading characters 0x) and converts the input into binary data for storage.

With this change, the psksecret and psksecret-remote entries under the IPsec VPN CLI command config vpn ipsec-phase1-interface have been amended to differentiate user input as either ASCII string or hex encoded values.

IKEv2 asymmetric authentication (393073)

Support added for IKEv2 asymmetric authentication, allowing both sides of an authentication exchange to use different authentication methods, for example the initiator may be using a shared key, while the responder may have a public signature key and certificate.

A new command, authmethod-remote, has been added to config vpn ipsec phase1-interface.

For more detailed information on authentication of the IKE SA, see RFC 5996 Internet Key Exchange Protocol Version 2 (IKEv2).

Allow mode-cfg with childless IKEv2 (391567)

An issue that prevented childless-ike from being enabled at the same time as mode-cfg has been resolved. Both options can now be enabled at once under config vpn ipsec phase1-interface.

IKEv2 Digital Signature Authentication support (389001)

FortiOS supports the use of Digital Signature authentication, which changes the format of the Authentication Data payload in order to support different signature methods.

Instead of just  containing a raw signature value calculated as defined in the original IKE RFCs,  the Auth Data now includes an ASN.1 formatted object that provides  details on how the signature was calculated, such as the signature type, hash algorithm, and signature padding method.

For more detailed information on IKEv2 Digital Signature authentication, see RFC 7427 Signature Authentication in the Internet Key Exchange Version 2 (IKEv2).

Passive static IPsec VPN (387913)

New commands have been added to config vpn ipsec phase1-interface to prevent initiating

VPN connection. Static IPsec VPNs can be configured in tunnel mode, without initiating tunnel negotiation or rekey.

To allow a finer configuration of the tunnel, the rekey option is removed from config system global and added to config vpn ipsec phase1-interface.

CLI syntax

config vpn ipsec phase1-interface edit <example> set rekey {enable | disable} set passive-mode {enable | disable} set passive-tunnel-interface {enable | disable}

end

Phase 2 wizard simplified (387725)

Previously, for a site-to-site VPN, phase 2 selectors had their static routes created in the IPsec VPN wizard by adding IP addresses  in string format. Now, since addresses and address groups are already created for these addresses, the address group can be used in the route directly. This means that the route can be modified simply by modifying the address/groups that were created when the VPN was initially created.

With this change, the VPN wizard will create less objects internally, and reduce complexity.

In addition, a blackhole route route will be created by default with a higher distance-weight set than the default route. This is to prevent traffic from flowing out of another route if the VPN interface goes down. In these instances, the traffic will instead be silently discarded.

Unique IKE ID enforcement (383296)

All IPsec VPN peers now connect with unique IKE identifiers. To implement this, a new phase1 CLI command has been added (enforce-unique-id) which, when enabled, requires all IPsec VPN clients to use a unique identifier when connecting.

CLI syntax

config vpn ipsec phase1 edit <name>

5.6.0

set enforce-unique-id {keep-new | keep-old | disable} Default is disable. next

end

 

Use keep-new to replace the old connection if an ID collision is detected on the gateway. Use keep-old to reject the new connection if an ID collision is detected.

FortiView VPN tunnel map feature (382767)

A geospatial map has been added to FortiView to help visualize IPsec and SSL VPN connections to a FortiGate using Google Maps. Adds geographical-IP API service for resolving spatial locations from IP addresses.

This feature can be found under FortiView > VPN.

Childless IKEv2 initiation (381650)

As documented in RFC 6023, when both sides support the feature, no child IPsec SA is brought up during the initial AUTH of the IKEv2 negotiation. Support for this mode is not actually negotiated, but the responder indicates support for it by including a CHILDLESS_IKEV2_SUPPORTED Notify in the initial SA_INIT reply. The initiator is then free to send its AUTH without any SA or TS payloads if it also supports this extension.

CLI syntax

config vpn ipsec phase1-interface edit ike set ike-version 2 set childless-ike enable

next

end

Due to the way configuration payloads (IKEV2_PAYLOAD_CONFIG) are handled in the current code base, mode-cfg and childless-ike aren’t allowed to be enabled at the same time. Processing config payloads for mode-cfg requires a child ph2handle to be created, but with childless-ike we completely avoid creating the child ph2 in the first place which makes the two features incompatible. It may be possible to support both in the future, but a deeper rework of the config payload handling is required.

Allow peertype dialup for IKEv2 pre-shared key dynamic phase1 (378714)

Restored peertype dialup that was removed in a previous build (when IKEv2 PSK gateway re-validation was not yet supported).

If peertype is dialup, IKEv2 AUTH verify uses user password in the user group “usrgrp” of phase1. The “psksecret” in phase1 is ignored.

CLI syntax

config vpn ipsec phase1-interface edit “name” set type dynamic set interface “wan1” set ike-version 2 set peertype dialup

set usrgrp “local-group”

next

end

IPsec default phase1/phase1-interface peertype changed from ‘any’ to ‘peer’ (376340)

Previously, when authmethod was changed to signature, peertype automatically changed to peer and required a peer to be set. This change was done to try to provide a more secure initial configuration, while allowing the admin to set peertype back to any if that’s what they really wanted. The default value was kept at any in the CLI. However, this caused problems with copy/pasting configurations and with FMG because if peertype any wasn’t explicitly provided, the CLI was switched to peertype peer.

This patch changes the default peertype to peer now; peertype any is considered non-default and will be printed out on any config listing. Upgrade code has been written to ensure that any older build that was implicitly using set peertype any has this setting preserved.

IPsec GUI bug fixes (374326)

Accept type “Any peer ID” is available when creating IPsec tunnel with authmethod, pre-shared key, ikev1 main mode/aggressive mode, and ikev2.

Support for IKEv2 Message Fragmentation (371241)

Added support for IKEv2 Message Fragmentation, as described in RFC 7383.

Previously, when sending and IKE packets with IKEv1, the whole packet is sent once, and it is only fragmented if there is a retransmission. With IKEv2, because RFC 7383 requires each fragment to be individually encrypted and authenticated, we would have to keep a copy of the unencrypted payloads around for each outgoing packet, in case the original single packet was never answered and we wanted to retry with fragments. So with this implementation, if the IKE payloads are greater than a configured threshold, the IKE packets are preemptively fragmented and encrypted.

CLI syntax

config vpn ipsec phase1-interface edit ike set ike-version 2

set fragmentation [enable|disable] set fragmentation-mtu [500-16000]

next

end

IPsec monitoring pages now based on phase 1 proposals not phase 2 (304246)

The IPsec monitor, found under Monitor > IPsec Monitor, was in some instances showing random uptimes even if the tunnel was in fact down.

Tunnels are considered as “up” if at least one phase 2 selector is active. To avoid confusion, when a tunnel is down, IPsec Monitor will keep the Phase 2 Selectors column, but hide it by default and be replaced with Phase 1 status column.

 

FortiOS 5.6 IPSec VPN Introduction

Introduction

This  FortiOS Handbook chapter contains the following sections:

IPsec VPN concepts explains the basic concepts that you need to understand about virtual private networks (VPNs).

IPsec VPN overview provides a brief overview of IPsec technology and includes general information about how to configure IPsec VPNs using this guide.

IPsec VPN in the web-based manager describes the IPsec VPN menu of the web-based manager interface.

Gateway-to-gateway configurations  explains how to set up a basic gateway-to-gateway (site-to-site) IPsec VPN. In a gateway-to-gateway configuration, two FortiGate units create a VPN tunnel between two separate private networks.

Hub-and-spoke configurations describes how to set up hub-and-spoke IPsec VPNs. In a hub-and-spoke configuration, connections to a number of remote peers and/or clients radiate from a single, central FortiGate hub.

Dynamic DNS configuration describes how to configure a site-to-site VPN, in which one FortiGate unit has a static IP address and the other FortiGate unit has a dynamic IP address and a domain name.

FortiClient dialup-client configurations guides you through configuring a FortiClient dialup-client IPsec VPN. In a FortiClient dialup-client configuration, the FortiGate unit acts as a dialup server and VPN client functionality is provided by the FortiClient Endpoint Security application installed on a remote host.

FortiGate dialup-client configurations  explains how to set up a FortiGate dialup-client IPsec VPN. In a FortiGate dialup-client configuration, a FortiGate unit with a static IP address acts as a dialup server and a FortiGate unit with a dynamic IP address initiates a VPN tunnel with the FortiGate dialup server.

Supporting IKE Mode config clients explains how to set up a FortiGate unit as either an IKE Mode Config server or client. IKE Mode Config is an alternative to DHCP over IPsec.

Internet-browsing configuration explains how to support secure web browsing performed by dialup VPN clients, and hosts behind a remote VPN peer. Remote users can access the private network behind the local FortiGate unit and browse the Internet securely. All traffic generated remotely is subject to the security policy that controls traffic on the private network behind the local FortiGate unit.

Redundant VPN configurations discusses the options for supporting redundant and partially redundant tunnels in an IPsec VPN configuration. A FortiGate unit can be configured to support redundant tunnels to the same remote peer if the FortiGate unit has more than one interface to the Internet.

Transparent mode VPNs describes two FortiGate units that create a VPN tunnel between two separate private networks transparently. In transparent mode, all FortiGate unit interfaces except the management interface are invisible at the network layer.

IPv6 IPsec VPNs describes FortiGate unit VPN capabilities for networks based on IPv6 addressing. This includes IPv4-over-IPv6 and IPv6-over-IPv4 tunnelling configurations. IPv6 IPsec VPNs are available in FortiOS 3.0 MR5 and later.

L2TP and IPsec (Microsoft VPN) explains how to support Microsoft Windows native VPN clients.

Introduction

GRE over IPsec (Cisco VPN) explains how to interoperate with Cisco VPNs that use Generic Routing Encapsulation (GRE) protocol with IPsec.

Protecting OSPF with IPsec provides an example of protecting OSPF links with IPsec.

Redundant OSPF routing over IPsec provides an example of  redundant secure communication between two remote networks using an OSPF VPN connection.

OSPF over dynamic IPsec provides an example of  how to create a dynamic IPsec VPN tunnel that allows OSPF.

BGP over dynamic IPsec provides an example of how to create a dynamic IPsec VPN tunnel that allows BGP.

Phase 1 parameters provides detailed step-by-step procedures for configuring a FortiGate unit to accept a connection from a remote peer or dialup client. The basic Phase 1 parameters identify the remote peer or clients and support authentication through preshared keys or digital certificates. You can increase VPN connection security further using methods such as extended authentication (XAuth).

Phase 2 parameters provides detailed step-by-step procedures for configuring an IPsec VPN tunnel. During Phase 2, the specific IPsec security associations needed to implement security services are selected and a tunnel is established.

Defining VPN security policies explains how to specify the source and destination IP addresses of traffic transmitted through an IPsec VPN tunnel, and how to define a security encryption policy. Security policies control all IP traffic passing between a source address and a destination address.

Logging and monitoring and Troubleshooting provide VPN monitoring and troubleshooting procedures.

CSF – Cooperative Security Fabric

CSF – Cooperative Security Fabric

Cooperative Security Fabric (CSF) – also known as a Fortinet Security Fabric – spans across an entire network linking different security sensors and tools together to collect, coordinate, and respond to malicious behavior in real time. CSF can be used to coordinate the behavior of different Fortinet products in your network, including FortiGate, FortiAnalyzer, FortiClient, FortiSandbox, FortiAP, FortiSwitch, and FortiClient Enterprise Management Server (EMS). CSF supports FortiOS 5.4.1+, FortiSwitchOS 3.3+, and FortiClient 5.4.1+.

Port TCP/8009 is the port FortiGate uses for incoming traffic from the FortiClient Portal, as user information (such as IP address, MAC address, avatar, and other profile information) is automatically synchronized to the FortiGate and EMS.

The brief example below assumes that FortiTelemetry has been enabled on the top-level FortiGate (FGT1), OSPF routing has been configured, and that policies have been created for all FortiGate units to access the

Internet.

For more details on how to configure a security fabric between FortiGate units, see Installing internal FortiGates and enabling a security fabric on the Fortinet Cookbook website.

CSF – Cooperative Security Fabric

Enabling CSF on the FortiGate:

  1. On the upstream FortiGate (FGT1), go to System > Cooperative Security Fabric and enable Cooperative Security Fabric (CSF).
  2. Enter a Group name and Group password for the fabric.
  3. On a downstream FortiGate (such as FGT2 or FGT3), configure the same fabric settings as were set on FGT1.
  4. Enable Connect to upstream FortiGate.

Be sure you do not enable this on the topmost-level FortiGate (in this example, FGT1).

  1. In FortiGate IP, enter the FGT1 interface that has FortiTelemetry The FortiTelemetry port (set to 8013) can be changed as required.

Once set up, you can view your network’s CSF configuration under FortiView through two topology dashboards.

  1. On top-level FortiGate, go to FortiView > Physical Topology. This dashboard shows a vizualization of all access layer devices in the fabric.
  2. Go to FortiView > Logical Topology to view information about the interfaces (logical or physical) that each device in the fabric is connected to.

Other CSF configurations for your network are available through the Fortinet Cookbook Cooperative Security Fabric page.

Examples and Troubleshooting

Examples and Troubleshooting

This chapter provides an example of a FortiGate unit providing authenticated access to the Internet for both Windows network users and local users. The following topics are included in this section:

  • Firewall authentication example
  • LDAP Dial-in using member-attribute example
  • RADIUS SSO example
  • Troubleshooting

Firewall authentication example

Example configuration

Overview

In this example, there is a Windows network connected to Port 2 on the FortiGate unit and another LAN, Network_1, connected to Port 3.

All Windows network users authenticate when they logon to their network. Members of the Engineering and Sales groups can access the Internet without entering their authentication credentials again. The example assumes that the Fortinet Single Sign On (FSSO) has already been installed and configured on the domain controller.

LAN users who belong to the Internet_users group can access the Internet after entering their username and password to authenticate. This example shows only two users, User1 is authenticated by a password stored on the FortiGate unit, User2 is authenticated on an external authentication server. Both of these users are referred to as local users because the user account is created on the FortiGate unit.

Creating a locally-authenticated user account

User1 is authenticated by a password stored on the FortiGate unit. It is very simple to create this type of account.

To create a local user – web-based manager:

  1. Go to User & Device > User Definition and select Create New.
  2. Follow the User Creation Wizard, entering the following information and then select Create:
User Type Local User
User Name User1
Password hardtoguess
Email Address

SMS

(optional)
Enable Select.

To create a local user – CLI:

config user local edit user1 set type password set passwd hardtoguess

end

Creating a RADIUS-authenticated user account

To authenticate users using an external authentication server, you must first configure the FortiGate unit to access the server.

To configure the remote authentication server – web-based manager:

  1. Go to User & Device > RADIUS Servers and select Create New.
  2. Enter the following information and select OK:
Name OurRADIUSsrv
Primary Server Name/IP 10.11.101.15
Primary Server Secret OurSecret
Authentication Scheme Select Use Default Authentication Scheme.

To configure the remote authentication server – CLI:

config user radius edit OurRADIUSsrv set server 10.11.102.15 set secret OurSecret set auth-type auto

Firewall authentication example

end

Creation of the user account is similar to the locally-authenticated account, except that you specify the RADIUS authentication server instead of the user’s password.

To configure a remote user – web-based manager:

  1. Go to User & Device > User Definition and select Create New.
  2. Follow the User Creation Wizard, entering the following information and then select Create:
User Type Remote RADIUS User
User Name User2
RADIUS server OurRADIUSsrv
Email Address

SMS

(optional)
Enable Select

To configure a remote user – CLI:

config user local edit User2 set name User2 set type radius

set radius-server OurRADIUSsrv

end

Creating user groups

There are two user groups: an FSSO user group for FSSO users and a firewall user group for other users. It is not possible to combine these two types of users in the same user group.

Creating the FSSO user group

For this example, assume that FSSO has already been set up on the Windows network and that it uses Advanced mode, meaning that it uses LDAP to access user group information. You need to

  • configure LDAP access to the Windows AD global catalog l specify the collector agent that sends user logon information to the FortiGate unit l select Windows user groups to monitor
  • select and add the Engineering and Sales groups to an FSSO user group

To configure LDAP for FSSO – web-based manager:

  1. Go to User & Device > LDAP Servers and select Create New.
  2. Enter the following information:
Name ADserver
Server Name / IP 10.11.101.160
Distinguished Name dc=office,dc=example,dc=com
Bind Type Regular
User DN cn=FSSO_Admin,cn=users,dc=office,dc=example,dc=com
Password set_a_secure_password
  1. Leave other fields at their default values.
  2. Select OK.

To configure LDAP for FSSO – CLI”

config user ldap edit “ADserver” set server “10.11.101.160”

set dn “cn=users,dc=office,dc=example,dc=com”

set type regular

set username “cn=administrator,cn=users,dc=office,dc=example,dc=com” set password set_a_secure_password

next

end

To specify the collector agent for FSSO – web-based manager

  1. Go to User & Device > Single Sign-On and select Create New.
  2. Enter the following information:
Type Fortinet Single Sign-On Agent
Name WinGroups
Primary Agent IP/Name 10.11.101.160
Password fortinet_canada
LDAP Server ADserver
  1. Select Apply & Refresh.

In a few minutes, the FortiGate unit downloads the list of user groups from the server.

To specify the collector agent for FSSO – CLI:

config user fsso edit “WinGroups” set ldap-server “ADserver” set password ENC

G7GQV7NEqilCM9jKmVmJJFVvhQ2+wtNEe9T0iYA5Sa+EqT2J8zhOrbkJFDr0RmY3c4LaoXdsoBczA

1dONmcGfthTxxwGsigzGpbJdC71spFlQYtj set server “10.11.101.160” end

Firewall authentication example

To create the FSSO_Internet-users user group – web-based manager:

  1. Go to User & Device > User Groups and select Create New.
  2. Enter the following information and then select OK:
Name FSSO_Internet_users
Type Fortinet Single Sign-On (FSSO)
Members Engineering, Sales

To create the FSSO_Internet-users user group – CLI:

config user group edit FSSO_Internet_users set group-type fsso-service

set member CN=Engineering,cn=users,dc=office,dc=example,dc=com

CN=Sales,cn=users,dc=office,dc=example,dc=com end

Creating the Firewall user group

The non-FSSO users need a user group too. In this example, only two users are shown, but additional members can be added easily.

To create the firewall user group – web-based manager:

  1. Go to User & Device > User Groups and select Create New.
  2. Enter the following information and then select OK:
Name Internet_users
Type Firewall
Members User1, User2

To create the firewall user group – CLI:

config user group edit Internet_users set group-type firewall set member User1 User2

end

Defining policy addresses

  1. Go to Policy & Objects > Addresses.
  2. Create the following addresses:
Address Name Internal_net
Type Subnet
Subnet / IP Range 10.11.102.0/24
Interface Port 3
Address Name Windows_net
Type Subnet
Subnet / IP Range 10.11.101.0/24
Interface Port 2

Creating security policies

Two security policies are needed: one for firewall group who connect through port3 and one for FSSO group who connect through port2.

To create a security policy for FSSO authentication – web-based manager:

  1. Go to Policy & Objects > IPv4 Policy and select Create New.
  2. Enter the following information:
Incoming Interface Port2
Source Address Windows_net
Source User(s) FSSO_Internet_users
Outgoing Interface Port1
Destination Address all
Schedule always
Service ALL
NAT ON
Security Profiles Optionally, enable security profiles.
  1. Select OK.

To create a security policy for FSSO authentication – CLI:

config firewall policy edit 0 set srcintf port2 set dstintf port1 set srcaddr Windows_net set dstaddr all

LDAP Dial-in using member-attribute example

set action accept set groups FSSO_Internet_users set schedule always set service ANY set nat enable

end

To create a security policy for local user authentication – web-based manager

  1. Go to Policy & Objects > IPv4 Policy and select Create New.
  2. Enter the following information:
Incoming Interface Port3
Source Address Internal_net
Source User(s) Internet_users
Outgoing Interface Port1
Destination Address all
Schedule always
Service ALL
NAT ON
Security Profiles Optionally, enable security profiles.
  1. Select OK.

To create a security policy for local user authentication – CLI

config firewall policy edit 0 set srcintf port3 set dstintf port1 set srcaddr internal_net set dstaddr all set action accept set schedule always set groups Internet_users set service ANY set nat enable

end

Monitoring authenticated users

Monitoring authenticated users

This section describes how to view lists of currently logged-in firewall and VPN users. It also describes how to disconnect users.

The following topics are included in this section:

  • Monitoring firewall users
  • Monitoring SSL VPN users
  • Monitoring IPsec VPN users
  • Monitoring users Quarantine

Monitoring firewall users

To monitor firewall users, go to Monitor > Firewall User Monitor.

You can de-authenticate a user by selecting the Delete icon for that entry.

You can filter the list of displayed users by selecting the funnel icon for one of the column titles or selecting Filter Settings.

Optionally, you can de-authenticate multiple users by selecting them and then selecting De-authenticate.

SSO using RADIUS accounting records

SSO using RADIUS accounting records

A FortiGate unit can authenticate users transparently who have already authenticated on an external RADIUS server. Based on the user group to which the user belongs, the security policy applies the appropriate UTM profiles. RADIUS SSO is relatively simple because the FortiGate unit does not interact with the RADIUS server, it only monitors RADIUS accounting records that the server forwards (originating from the RADIUS client). These records include the user’s IP address and user group.

After the initial set-up, changes to the user database, including changes to user group memberships, are made on the external RADIUS server, not on the FortiGate unit.

This section describes:

  • User’s view of RADIUS SSO authentication l Configuration Overview l Configuring the RADIUS server l Creating the FortiGate RADIUS SSO agent l Defining local user groups for RADIUS SSO l Creating security policies
  • Example: webfiltering for student and teacher accounts

User’s view of RADIUS SSO authentication

For the user, RADIUS SSO authentication is simple:

  • The user connects to the RADIUS server and authenticates.
  • The user attempts to connect to a network resource that is reached through a FortiGate unit. Authentication is required for access, but the user connects to the destination without being asked for logon credentials because the FortiGate unit knows that the user is already authenticated. FortiOS applies UTM features appropriate to the user groups that the user belongs to.

Configuration Overview

The general steps to implement RADIUS Single Sign-On are:

  1. If necessary, configure your RADIUS server. The user database needs to include user group information and the server needs to send accounting messages.
  2. Create the FortiGate RADIUS SSO agent.
  3. Define local user groups that map to RADIUS groups.
  4. Create a security policy which specifies the user groups that are permitted access.

 

Configuring the RADIUS server

You can configure FortiGate RSSO to work with most RADIUS-based accounting systems. In most cases, you only need to do the following to your RADIUS accounting system:

  • Add a user group name field to customer accounts on the RADIUS server so that the name is added to the RADIUS Start record sent by the accounting system to the FortiOS unit. User group names do not need to be added for all users, only to the accounts of users who will use RSSO feature on the FortiGate unit.
  • Configure your accounting system to send RADIUS Start records to the FortiOS unit. You can send the RADIUS Start records to any FortiGate network interface. If your FortiGate unit is operating with virtual domains (VDOMs) enabled, the RADIUS Start records must be sent to a network interface in the management VDOM.

IPv6 RADIUS Support

RADIUS authentication is supported with IPv6, allowing administrators to configure an IPv6 RADIUS server on the FortiGate for IPv6 RADIUS authentication traffic to pass between the server and FortiGate.

Syntax

Allow IPv6 access on an interface:

config system interface edit <name> config ipv6 set ip6-allowaccess {ping | https | ssh | snmp | http | telnet | fgfm | capwap} set ip6-address <xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/xxx>

next

next

end

Configure the IPv6 RADIUS server:

config user radius edit <name> set server <xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx> …

next

end

Agent-based FSSO

Agent-based FSSO

FortiOS can provide single sign-on capabilities to Windows AD, Citrix, Novell eDirectory, or, as of FortiOS 5.4, Microsoft Exchange users with the help of agent software installed on these networks. The agent software sends information about user logons to the FortiGate unit. With user information such as IP address and user group memberships from the network, FortiGate security policies can allow authenticated network access to users who belong to the appropriate user groups without requesting their credentials again.

For Windows AD networks, FortiGate units can provide SSO capability without agent software by directly polling the Windows AD domain controllers. For information about this type of SSO, seeSingle Sign-On to Windows AD on page 133.

The following topics are included:

  • Introduction to agent-based FSSO
  • FSSO NTLM authentication support
  • Agent installation
  • Configuring the FSSO Collector agent for Windows AD
  • Configuring the FSSO TS agent for Citrix
  • Configuring FSSO with Novell networks
  • Configuring FSSO Advanced Settings
  • Configuring FSSO on FortiGate units
  • FortiOS FSSO log messages
  • Testing FSSO
  • Troubleshooting FSSO

Introduction to agent-based FSSO

Fortinet Single Sign-On (FSSO), through agents installed on the network, monitors user logons and passes that information to the FortiGate unit. When a user logs on at a workstation in a monitored domain, FSSO

l detects the logon event and records the workstation name, domain, and user, l resolves the workstation name to an IP address, l determines which user groups the user belongs to, l sends the user logon information, including IP address and groups list, to the FortiGate unit l creates one or more log entries on the FortiGate unit for this logon event as appropriate.

When the user tries to access network resources, the FortiGate unit selects the appropriate security policy for the destination. If the user belongs to one of the permitted user groups associated with that policy, the connection is allowed. Otherwise the connection is denied.

FSSO can also provide NTLM authentication service for requests coming from FortiGate. SSO is very convenient for users, but may not be supported across all platforms. NTLM is not as convenient, but it enjoys wider support. See FSSO NTLM authentication support on page 148.

Introduction to FSSO agents

There are several different FSSO agents that can be used in an FSSO implementation:

  • Domain Controller (DC) agent
  • eDirectory agent
  • Citrix/Terminal Server (TS) agent
  • Collector (CA) agent

Consult the latest FortiOS and FSSO Release Notes for operating system compatibility information.

Domain Controller (DC) agent

The Domain Controller (DC) agent must be installed on every domain controller if you will use DC Agent mode, but is not required if you use Polling mode. See FSSO for Windows AD on page 144.

eDirectory agent

The eDirectory agent is installed on a Novell network to monitor user logons and send the required information to the FortiGate unit. It functions much like the Collector agent on a Windows AD domain controller.The agent can obtain information from the Novell eDirectory using either the Novell API or LDAP.

Citrix/Terminal Server (TS) agent

The Citrix/Terminal Server (TS) agent is installed on a Citrix terminal server to monitor user logons in real time. It functions much like the DC Agent on a Windows AD domain controller.

Collector (CA) agent

This agent is installed as a service on a server in the Windows AD network to monitor user logons and send the required information to the FortiGate unit. The Collector agent can collect information from

  • Domain Controller agent (Windows AD)
  • TS agent (Citrix Terminal Server)

In a Windows AD network, the Collector agent can optionally obtain logon information by polling the AD domain controllers. In this case, DC agents are not needed.

The Collector can obtain user group information from the DC agent or optionally, a FortiGate unit can obtain group information directly from AD using Lightweight Directory Access Protocol (LDAP).

On a Windows AD network, the FSSO software can also serve NT LAN Manager (NTLM) requests coming from client browsers (forwarded by the FortiGate unit) with only one or more Collector agents installed. See FSSO NTLM authentication support on page 148.

The CA is responsible for DNS lookups, group verification, workstation checks, and as mentioned FortiGate updates of logon records. The FSSO Collector Agent sends Domain Local Security Group and Global Security Group information to FortiGate units. The CA communicates with the FortiGate over TCP port 8000 and it listens on UDP port 8002 for updates from the DC agents.

The FortiGate unit can have up to five CAs configured for redundancy. If the first on the list is unreachable, the next is attempted, and so on down the list until one is contacted. See Configuring FSSO on FortiGate units on page 175.

All DC agents must point to the correct Collector agent port number and IP address on domains with multiple DCs.

A FortiAuthenticator unit can act much like a Collector agent, collecting Windows AD user logon information and sending it to the FortiGate unit. It is particularly useful in large installations with several FortiGate units. For more information, see the FortiAuthenticator Administration Guide.

FSSO for Microsoft Exchange Server

As of FortiOS 5.4, FSSO supports monitoring Microsoft Exchange Server. This is useful for situations when the user accesses the domain account to view their email, even when the client device might not be in the domain.

Support for the Exchange server is configured on the Back-end FSSO collector agent. For more information on the collector agent, see Collector agent installation:

  1. On the FSSO collector agent, go to Advanced Settings > Exchange Server.
  2. Select Add and enter the following information and select OK:
Domain Name Enter your domain name.
Server IP/Hostname Enter the IP address or the hostname of your exchange server.
Polling forwarded event log This option for scenarios when you do not want that CA polls the Exchange Server logs directly. In this case you need to configure event log forwarding on the Exchange server. Exchange event logs can be forwarded to any member server. If you enable this, instead of the IP of the Exchange server configured in the previous step, you must then configure the IP of this member server. CA will then contact the member server.
Ignore Name Because CA will also check Windows log files for logon events and when a user authenticates to Exchange Server there is also a logon event in Windows event log, which CA will read and this will overwrite the Exchange Server logon event (ESEventLog) on CA. So it is recommended to set the ignore list to the domain the user belongs to.

To do so, enter the domain name in the Ignore Name field and select Add.

FSSO for Windows AD

FSSO for Windows AD requires at least one Collector agent. Domain Controller agents may also be required depending on the Collector agent working mode. There are two working modes to monitor user logon activity: DC Agent mode or Polling mode.

Collector agent DC Agent mode versus Polling mode

DC Agent mode Polling Mode
Installation Complex — Multiple installations: one agent per DC plus Collector agent, requires a reboot Easy — Only Collector agent installation, no reboot required
Resources Shares resources with DC system Has own resources
Network load Each DC agent requires minimum 64kpbs bandwidth, adding to network load Increase polling period during busy period to reduce network load
Level of

Confidence

Captures all logons Potential to miss a login if polling period is too great
DC Agent mode

DC Agent mode is the standard mode for FSSO. In DC Agent mode, a Fortinet authentication agent is installed on each domain controller. These DC agents monitor user logon events and pass the information to the Collector agent, which stores the information and sends it to the FortiGate unit.

The DC agent installed on the domain controllers is not a service like the Collector agent — it is a DLL file called dcagent.dll and is installed in the Windows\system32 directory. It must be installed on all domain controllers of the domains that are being monitored.

FSSO in DC agent mode

DC Agent mode provides reliable user logon information, however you must install a DC agent on every domain controller. A reboot is needed after the agent is installed. Each installation requires some maintenance as well. For these reasons it may not be possible to use the DC Agent mode.

Each domain controller connection needs a minimum guaranteed 64kpbs bandwidth to ensure proper FSSO functionality. You can optionally configure traffic shapers on the FortiGate unit to ensure this minimum bandwidth is guaranteed for the domain controller connections.

Introduction to agent-based

Polling mode

In Polling mode there are three options — NetAPI polling, Event log polling, and Event log using WMI. All share the advantages of being transparent and agentless.

NetAPI polling is used to retrieve server logon sessions. This includes the logon event information for the Controller agent. NetAPI runs faster than Event log polling but it may miss some user logon events under heavy system load. It requires a query round trip time of less than 10 seconds.

Event log polling may run a bit slower, but will not miss events, even when the installation site has many users that require authentication. It does not have the 10 second limit on NetAPI polling. Event log polling requires fast network links. Event log polling is required if there are Mac OS users logging into Windows AD.

Event log using WMI polling: WMI is a Windows API to get system information from a Windows server, CA is a WMI client and sends WMI queries for user logon events to DC, which in this case is a WMI server. Main advantage in this mode is that CA does not need to search security event logs on DC for user logon events, instead, DC returns all requested logon events via WMI. This also reduces network load between CA and DC.

In Polling mode, the Collector agent polls port 445 of each domain controller for user logon information every few seconds and forwards it to the FortiGate unit. There are no DC Agents installed, so the Collector agent polls the domain controllers directly.

FSSO in Polling mode

A major benefit of Polling mode is that no FSSO DC Agents are required. If it is not possible to install FSSO DC Agents on your domain controllers, this is the alternate configuration available to you. Polling mode results in a less complex install, and reduces ongoing maintenance. The minimum permissions required in Polling mode are to read the event log or call NetAPI.

Collector agent AD Access mode – Standard versus Advanced

The Collector agent has two ways to access Active Directory user information. The main difference between Standard and Advanced mode is the naming convention used when referring to username information.

Standard mode uses regular Windows convention: Domain\Username. Advanced mode uses LDAP convention: CN=User, OU=Name, DC=Domain.

If there is no special requirement to use LDAP— best practices suggest you set up FSSO in Standard mode. This mode is easier to set up, and is usually easier to maintain and troubleshoot.

Standard and advanced modes have the same level of functionality with the following exceptions:

  • Users have to create Group filters on the Collector agent. This differs from Advanced mode where Group filters are configured from the FortiGate unit. Fortinet strongly encourages users to create filters from CA.
  • Advanced mode supports nested or inherited groups. This means that users may be a member of multiple monitored groups. Standard mode does not support nested groups so a user must be a direct member of the group being monitored.

FSSO for Citrix

Citrix users can enjoy a similar Single Sign-On experience as Windows AD users. The FSSO TS agent installed on each Citrix server provides user logon information to the FSSO Collector agent on the network. The FortiGate unit uses this information to authenticate the user in security policies.

Citrix SSO topology

Citrix users do not have unique IP addresses. When a Citrix user logs on, the TS agent assigns that user a range of ports. By default each user has a range of 200 ports.

FSSO for Novell eDirectory

FSSO in a Novell eDirectory environment works similar to the FSSO Polling mode in the Windows AD environment. The eDirectory agent polls the eDirectory servers for user logon information and forwards the information to the FortiGate unit. There is no need for the Collector agent.

When a user logs on at a workstation, FSSO:

  • detects the logon event by polling the eDirectory server and records the IP address and user ID, l looks up in the eDirectory which groups this user belongs to,

 

FSSO NTLM authentication support

  • sends the IP address and user groups information to the FortiGate unit.

When the user tries to access network resources, the FortiGate unit selects the appropriate security policy for the destination. If the user belongs to one of the permitted user groups, the connection is allowed.

FSSO is supported on the Novell E-Directory 8.8 operating system.

For a Novell network, there is only one FSSO component to install — the eDirectory agent. In some cases, you also need to install the Novell Client.

FSSO security issues

When the different components of FSSO are communicating there are some inherent security features.

FSSO installation requires an account with network admin privileges. The security inherent in these types of accounts helps ensure access to FSSO configurations is not tampered with.

User passwords are never sent between FSSO components. The information that is sent is information to identify a user including the username, group or groups, and IP address.

NTLM uses base-64 encoded packets, and uses a unique randomly generated challenge nonce to avoid sending user information and password between the client and the server.

Single Sign-On to Windows AD

Single Sign-On to Windows AD

The FortiGate unit can authenticate users transparently and allow them network access based on their privileges in Windows AD. This means that users who have logged on to the network are not asked again for their credentials to access network resources through the FortiGate unit, hence the term “Single Sign-On”.

The following topics are included:

  • Introduction to Single Sign-On with Windows AD
  • Configuring Single Sign On to Windows AD
  • FortiOS FSSO log messages
  • Testing FSSO
  • Troubleshooting FSSO

Introduction to Single Sign-On with Windows AD

Introduced in FortiOS 5.0, Single Sign-On (SSO) support provided by FortiGate polling of domain controllers is simpler than the earlier method that relies on agent software installed on Windows AD network servers. No Fortinet software needs to be installed on the Windows network. The FortiGate unit needs access only to the Windows AD global catalog and event log.

When a Windows AD user logs on at a workstation in a monitored domain, the FortiGate unit l detects the logon event in the domain controller’s event log and records the workstation name, domain, and user, l resolves the workstation name to an IP address, l uses the domain controller’s LDAP server to determine which groups the user belongs to, l creates one or more log entries on the FortiGate unit for this logon event as appropriate.

When the user tries to access network resources, the FortiGate unit selects the appropriate security policy for the destination. The selection consist of matching the FSSO group or groups the user belongs to with the security policy or policies that match that group. If the user belongs to one of the permitted user groups associated with that policy, the connection is allowed. Otherwise the connection is denied.