Tag Archives: ip do roteador fortinet

Logging and Reporting

Logging and Reporting


New Features

A new error log message is recorded when the Antispam engine request does not get a response from FortiGuard (265255)

Error code is ‘sp_ftgd_error‘.


New Report database construction (280398 267019)

This will improve performance with reports and FortiView without requiring any configuration changes.


Communication between FortiGate and FortiAnalyzer supports IPv6 addresses (245620)

When configuring your FortiGate to send logs to a FortiAnalyzer you can specify an IPv4 or an IPv6 address.


Context menu on Log & Report > Forward Traffic has been updated (293188)

Now includes Policy Table and Device Quarantine controls.


Filtering allows control of the log messages sent to each log device (262061)

This includes disk log, memory log, FortiAnalyzer and syslog servers and allows inclusion/exclusion based on type, severity, and log ID.


Use the following CLI command:


config log <device> filter

set filter <new-filter-settings>

set filter-type <include | exclude>


Load Balancing

Load balancing

ChaCha20 and Poly1305 cipher suites added for SSL load balancing (264785)

FortiOS 5.4 adds support for ChaCha20 and Poly1305 for SSL load balancing (see RFC 7539 for information about ChaCha20 and Poly1305). You can use the following command to view the complete list of supported cipher suites:


config firewall vip edit <vip-name>

set type server-load-balance set server-type https

set ssl-algorithm custom config ssl-cipher-suites

edit 0

set cipher ?

In most configurations the matching cipher suite is automatically selected.

All of these cipher suites are available to all of FortiOS’s implementations of SSL but the complete list of supported cipher suites is only viewable using the above command.

You can also use the above command to limit the set of cipher suites that are available for a given SSL offloading configuration. For example, use the following command to limit an SSL load balancing configuration to use the three cipher suites that support ChaCha20 and Poly1305:

config firewall vip edit <vip-name>

set type server-load-balance set server-type https

set ssl-algorithm custom config ssl-cipher-suites

edit 1

set cipher TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256 next

edit 2

set cipher TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256 next

edit 3

set cipher TLS-DHE-RSA-WITH-CHACHA20-POLY1305-SHA256 end






DHCPv6 server is configurable in delegated mode (295007)

Downstream IPv6 interfaces can receive address assignments on delegated subnets from a DHCP server that serves an upstream interface.


DHCPv6-PD configuration

Enable DHCPv6 Prefix Delegation on upstream interface (port10):

config system interface edit “port10”

config ipv6

set dhcp6-prefix-delegation enable end



Assign delegated prefix on downstream interface (port1). Optionally, specific delegated prefixes can be specified:


config system interface edit “port1”

config ipv6

set ip6-mode delegated

set ip6-upstream-interface “port10” set ip6-subnet ::1:0:0:0:1/64

set ip6-send-adv enable

config ipv6-delegated-prefix-list edit 1

set upstream-interface “port10” set autonomous-flag enable

set onlink-flag enable

set subnet 0:0:0:100::/64 end

end end



DHCPv6 Server configuration

Configuring a server that uses delegated prefix and DNS from upstream:


config system dhcp6 server edit 1

set dns-service delegated set interface “wan2”

set upstream-interface “wan1” set ip-mode delegated

set subnet 0:0:0:102::/64 end

FortiAuthenticator For Windows Active Directory Self Service

Using FortiAuthenticator To Perform Account Self Service For AD

I was asked a question on the FortiAuthenticator 4.0 Admin Guide about whether or not the FortiAuthenticator was needed in order for a FortiGate to communicate and authenticate with Windows Active Directory. The answer to that question is a resounding “NO” but it did remind me of a neat trick the FortiAuthenticator does provide when deployed in a LDAP environment. I like to call little things like this configuration the key to #FortiSuccess

When a FortiAuthenticator is deployed in a Windows Active Directory environment and it’s service account (the account you created for it to use when authenticating to AD in order to perform service tasks and lookups) has permissions to read and write to update passwords, you can utilize the FortiAuthenticator self service portal for your users in order to perform AD password resets.

We all know, having worked in help desk style environments before, that one of the most frequent trouble tickets a service desk receives is the dreaded password resets due to users forgetting their credentials.

So buy a FortiAuthenticator, deploy it in your environment, and utilize it for self service so that you can reduce your help desk work load and overhead!

I deployed this configuration for a large university and they were able to greatly reduce the work load and needs of their help desk and at the same time caused their users to feel empowered.


The FortiAuthenticator 4.0 Documentation will tell you everything you need to know to deploy this setup. Specific Password Recovery configurations can be viewed on PAGE 4 of that same documentation.

Fortinet Hardware Installation

Racked Some New Gear

We got some new hardware in the other day that we decided to rack today. Nothing too fancy, a few FortiGate 300D’s for an HA cluster, a few FortiSwitches, A FortiManager 200D and a FortiAnalyzer 200D. This are replacing older antiquated 100C units that we have hacked (installed a SSD in each) and prodded until they just couldn’t keep up anymore. The below picture is a quick shot of the devices before cable management and full connectivity has been completed.

You could say we have a pretty strong affinity for Fortinet Hardware. Hopefully this shows a bit of it. What is NOT in the photo are the AP’s throughout and a few other items.

Fortinet Hardware Installation

Policy Based IPSec and NAT

Think of the little things

This is going to be a quick guide on things to check when your Policy based IPSec tunnels decide to not work properly with NAT enabled.

Have this client, they were getting ready to migrate a bunch of IPSec tunnels from one of their client’s firewalls. The firewall that was originally hosting these tunnels is a Dell Sonicwall (threw up a little in my mouth right there).

We get the tunnels loaded and all are working fine except for the ones that require NAT due to overlapping subnets.

Just a reminder boys and girls, when your settings APPEAR to be correct but things still aren’t working…..it’s going to be something simple.

It is always something simple!

When you create a phase 2 for your tunnels through the GUI certain parameters are predefined. This is fine if you are using a simple tunnel with no NAT being applied.

One of these settings is the “use-natip enabled” setting that comes swinging right out the gate. If you have never looked at your phase 2 through the CLI you wouldn’t even know this existed.

Proof is in the pudding:

There is nothing more frustrating than having your policy setup improperly (no NAT applied through policy) and the tunnel come up, but no traffic flows……but if you enable NAT in the policy all of a sudden no tunnel OR traffic.

The two conflict. So if you are doing policy based IPSec tunnels that ALSO happen to be performing NAT on the policy (which you can only enable on the policy through CLI by the way…) you are going to be in for a bad time until you turn off the NAT setting on the phase 2

In Conclusion:

I know this entire post is basically a giant run on sentence but I wanted to get it on paper as it was fresh in my head. I tend to forget things you know. By all means express your findings on these types of situations in the comments. Would love a healthy dialogue regarding these types of things! If I need to expand on anything to make it easier to understand please let me know. I am always available to answer questions.




IKE/IPsec Extended Sequence Number (ESN) support (255144)

This feature implements negotiation of 64-bit Extended Sequence numbers as described in RFC 4303, RFC 4304 as an addition to IKEv1, and RFC 5996 for IKEv2.


Updates and enhancements to the IPsec VPN wizard (222339 290377 287021 289251)

The IPsec VPN wizard has been simplified to more clearly identify tunnel template types, remote device types, and NAT configuration requirements. Example topological diagrams are now also included.

New Dialup – FortiGate and Dialup – Windows (Native L2TP/IPsec) tunnel template options.


Cisco compatible keep-alive support for GRE (261595)

The FortiGate can now send a GRE keep-alive response to a Cisco device to detect a GRE tunnel. If it fails, it will remove any routes over the GRE interface.



config system gre-tunnel edit <id>

set keepalive-interval <value: 0-32767>

set keepalive-failtimes <value: 1-255>

next end


Repeated Authentication in Internet Key Exchange (IKEv2) Protocol (282025)

This feature provides the option to control whether a device requires its peer to re-authenticate or whether re-key is sufficient. It does not influence the re-authentication or re-key behavior of the device itself, which is controlled by the peer (with the default being to re-key).

This solution is in response to RFC 4478. As described by the IETF, “the purpose of this is to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer”.



config vpn ipsec phase1-interface edit p1

set reauth [enable | disable]

next end


Improvements to IPsec VPN in ADVPN hub-and-spoke (275322)

IPsec VPN traffic is now allowed through a tunnel between an ADVPN hub-and-spoke config vpn ipsec phase1-interface edit “int-fgtb”

set auto-discovery-sender [enable | disable] set auto-discovery-receiver [enable | disable] set auto-discovery-forwarder [enable | disable]

… next


config vpn ipsec phase2-interface edit “int-fgtb”

set auto-discovery-sender phase1 [enable | disable]

… next




ADVPN support for NAT device (299798)

The ADVPN feature has been extended so that it allows ADVPN shortcuts to be negotiated as long as one of the devices is not behind NAT.

The on-the-wire format of the ADVPN messages was changed so that they use TLV encoding. Since the on-the- wire format has changed this is not compatible with any previous ADVPN builds.



AESGCM support (281822)

AES-GCM (128 | 256) AEAD has been added, as specified in RFC 4106:

config vpn ipsec phase1-interface edit “tofgta”

set suite-b disable | suite-b-gcm-128 | suite-b-gcm-256

… next


config vpn ipsec phase2-interface

edit “tofgta”

set phase1name “tofgta”

set proposal aes128gcm aes256gcm

… next


High Availability

High Availability

FGCP supports BFD enabled BGP graceful restart after an HA failover (255574)

If an HA cluster is part of a Border Gateway Protocol (BGP) bidirectional forwarding detection (BFD) configuration where both the cluster and the BGP static neighbor are configured for graceful restart, after an HA failover BGP enters graceful restart mode and both the cluster and the BGP neighbor keep their BGP routes.

To support HA and BFD enabled BGP graceful:

l  From the cluster, configure the BFD enabled BGP neighbor as a static BFD neighbor using the config router bfd command.Set the BGP auto-start timer to 5 seconds so that after an HA failover BGP on the new primary unit waits for 5 seconds before connect to its BFD neighbors, and then registers BFD requests after establishing the connections. With static BFD neighbors, BFD requests and sessions can be created as soon as possible after the failover.The command get router info bfd requests shows the BFD peer requests.

l  The BFD session created for a static BFD neighbor/peer request initializes its state as INIT instead of DOWN and its detection time as bfd-required-min-rx * bfd-detect-mult msecs.

l  When a BFD control packet with a nonzero Your Discriminator (your_discr) value is received, if no session can be found to match the your_discr, instead of discarding the packet, other fields in the packet, such as addressing information, are used to choose one session that was just initialized, with zero as its remote discriminator.

l  When a BFD session in the UP state receives a control packet with zero as Your Discriminator and DOWN as State, the session changes its state to DOWN but will not notify this DOWN event to BGP and/or other registered clients.


FRUP is not supported by FortiOS 5.4 (295198)

With the changes to switch mode, FRUP is no longer available on the FortiGate-100D.


VOIP application control sessions are no longer blocked after an HA failover (273544)

After an HA failover, VoIP sessions that are being scanned by application control will now continue with only a minor interruption, if any. To support this feature, IPS UDP expectation tables are now synchronized between cluster units.


Firewall local-in policies are supported for the dedicated HA management interface (276779


To add local in polices for the dedicated management interface, enable ha-mgmt-inft-only and set intf to any. Enabling ha-mgmt-intf-only means the local-in policy applies only to the VDOM that contains the dedicated HA management interface.


config firewall local-in-policy edit 0

set ha-mgmt-intf-only enable set intf any

etc… end





HA heartbeat traffic set to the same priority level as data traffic (276665)

Local out traffic, including HA heartbeat traffic, is now set to high priority to make sure it is processed at the same priority level as data traffic. This change has been made because HA heartbeat traffic can be processed by NP6 processors that are also processing data traffic. When HA heartbeat traffic was set to a lower priority it may have be delayed or dropped by very busy NP6 processors resulting in HA failovers.


FGSP CLI command name changed (262340)

The FortiOS 5.2 command config system session-sync has been changed in FortiOS 5.4 to config system cluster-sync. Otherwise the command syntax is the same and the config system ha commands used for FGSP settings have not changed.


FGSP now supports synchronizing IPsec sessions (262340)

The FGSP now synchronizes IPsec tunnels between FortiGates in an FGSP configuration. IPsec tunnel synchronization synchronizes keys and other run time data between the FortiGates in an FGSP configuration. No additional configuration is required to synchronize IPsec sessions. Also you cannot disable IPsec tunnel synchronization.


The FGSP synchronizes IPsec keys and other runtime data but not actual tunnel sessions. This means that if one of the cluster units goes down the cluster unit that is still operating can quickly get IPsec tunnels re-established without re-negotiating them but all existing tunnel sessions on the failed FortiGate have to be restarted on the still operating FortiGate.

IPsec tunnel sync only supports dialup IPsec. The interfaces on both FortiGates that are tunnel endpoints must have the same IP addresses and external routers must be configured to load balance IPsec tunnel sessions to the FortiGates in the cluster.


Monitoring VLAN interfaces (220773)

When operating in HA mode and if you have added VLAN interfaces to the FortiGates in the cluster, you can use the following command to monitor all VLAN interfaces and send a message if one of the VLAN interfaces is found to be down.


config system ha-monitor

set monitor-vlan enable/disable

set vlan-hb-interval <interval_seconds>

set vlan-hb-lost-threshold <vlan-lost-heartbeat-threshold>


Once configured, this feature works by verifying that the primary unit can connect to the subordinate unit over each VLAN. This verifies that the switch that the VLAN interfaces are connected to is configured correctly for each VLAN. If the primary unit cannot connect to the subordinate unit over one of the configured VLANs the primary unit writes a link monitor log message indicating that the named VLAN went down (log message id 20099).


FortiGate HA cluster support for managed switches (276488 266084)

Added the capability to support managed switches from a FortiGate HA cluster. If a standby FortiGate becomes active, it automatically establishes connectivity with the managed switches. See Managing a FortiGate with a FortiSwitch for details.


HA cluster health displayed on the Unit Operation dashboard widget (260547)

The Unit Operation dashboard widget now includes the serial number and hostname of all of the FortiGate units in the cluster as well as an indication of the sync status of each cluster member.