In this video, you will learn how to use virtual domains (VDOMs) to host multiple FortiOS instances on a single FortiGate.

In this example, two companies (called Company A and Company B) use the same FortiGate but have different Internet service providers (ISPs). To provide both companies with network and Internet connectivity, each company has its own VDOM (called VDOM-A and VDOM-B) that are managed independently.

The root VDOM will be used to manage the FortiGate’s global settings.
VDOM-A will be used for direct internet access, using 2 interfaces.
VDOM-B will have a more complex internal network, using 5 interfaces.

The recipe for this video is available here.

Watch more videos

The post Virtual Domains (Video) appeared first on Fortinet Cookbook.

This recipe demonstrates how to set up a web filter security profile with a quota that dynamically limits the amount of time users on an internal network can access websites categorized as “General Interest.”  

You can also apply quotas to specific users on your network by creating granular policies that apply different quotas to different user groups using specific firewall addresses or needing authentication.

See User and device authentication for information about creating user accounts.

_{Find this recipe for other FortiOS versions
5.2 | 5.4}

1. Enabling web filtering
Go to System > Feature Select and confirm that Web Filter is ON. If necessary, click Apply to make your changes.
2. Creating a web filter profile that uses quotas
Go to Security Profiles > Web Filter. Edit the default profile and enable FortiGuard category based filter.   Right-click on the category General Interest – Personal and select Monitor. Do the same for the category General Interest – Business.   These categories include a variety of sites that are commonly blocked in the workplace, such as games, instant messaging, and social media. For a complete description of each web filtering category, visit the FortiGuard Web Filtering page.
Under Category Usage Quota, select Create New.   Select both General Interest – Personal and General Interest – Business. For testing purposes, set the Quota to 5 Minutes.
The web filter now displays all the General Interest sub-categories and the applied quota.
3. Adding web filtering to a security policy
Go to Policy & Objects > IPv4 Policy and edit the policy that allows connections from the internal network to the Internet. Under Security Profiles, turn on Web Filter and use the default profile. Note: If you are applying quotas to specific users or devices, edit Source Address to apply the policy only to them.
4. Results
Browse to www.ebay.com, a website in the General Interest – Personal category.   Access to the website is allowed for 5 minutes, after which time  a “web page blocked” message appears. The message appears each time users affected by the security policy try to access General Interest sites until the quota is reset (every 24 hours at midnight).
Go to FortiView > Threats and select the 5 minutes view. You can see the blocked traffic.

For further reading, check out Blocking Social Media using FortiGuard Categories, Blocking Facebook with Web Filtering, and FortiGuard Web Filtering Service in the FortiOS 5.4 Handbook.

The post Web filtering using quotas appeared first on Fortinet Cookbook.

The FortiVoice Enterprise auto dialing system provides a significant time and resource savings for your organization by assisting you when you need to reach multiple contacts quickly and efficiently. 

This recipe guides you through the quick and easy process of setting up your auto dialer and establishing your contact list.

Setting up an Auto Dialer Campaign
To setup an auto dialer campaign Go to Auto Dialer > Campaign > Campaign. Enter a name for the campaign and the caller ID to display on the phone. Select the message you wish to broadcast when the client is contacted. Enter the amount of times you want the auto dialer to retry calling the client in the Retry field. Select the external phone numbers you want to audodial. You can add numbers by going to Auto Dialer > Contact > Contact/Contact. Select the internal phone numbers you want to automatically dial. These numbers are the internal extensions on the FortiVoice unit. If you wish to create your own personalized message, go to Auto Dialer > Campaign > Audio and select New.
Adding Contacts
With your auto dialer campaign configured, you can now start adding the groups or individuals you want the unit to automatically dial. To add a contact Go to Auto Dialer > Contact > Contact. Select New and enter the necessary contact information. Select Create. To add a contact group Go to Auto Dialer > Contact > Contact Group.  Select New. Enter a name for the group. Select the members for the group. If you have none available, you’ll have to create them by adding contacts.  Select Create.

The post Automatic Dialing in FortiVoice Enterprise appeared first on Fortinet Cookbook.

In this episode, Michael Strickland and Sean Groarke discuss the third generation of the FortiASIC system-on-a-chip, called the SOC3. This chip is used in the new FortiGate 60E series.

More SOC3 Resources:

• Fortinet’s Next-Generation System-on-a-Chip Accelerates the World’s Most Powerful Distributed Enterprise Firewall
• Introducing the World’s Fastest and Most Secure Distributed Enterprise Firewall
• FortiGate/FortiWiFi 60E Series

Subscribe to FortiCast

The post Episode 3: SOC3 appeared first on Fortinet Cookbook.

What if you need a notification indicating a system activity event? FortiVoice Enterprise lets lets you configure your unit to notify selected users  by email when specific events occur.

This recipe guides you through the process of configuring the alert recipients, exploring the user options, and then establishing how a caller navigates through the auto attendant.

Configuring Alert Recipients
To create an auto attendant Go to Call Features > Auto Attendant > Auto Attendant. Select New.  Enter a name for the auto attendant and and set the default language. Select the desired greeting mode from the dropdown menu. Selecting Scheduled will require you to configure a schedule.  Select the desired sound file for your greeting. This option is only available if you selected Simple.  Enter the amount of time the phone will ring before being answered and the time out. Configure the auto attendant keys for callers to use when navigating through the auto attendant hierarchy. So, for example, you could set the number 2 for technical support.  We’ll explore the more advanced features in the next section.
Auto Attendant Advanced Features
Once you’ve finished configuring the auto attendant, you’ll need to establish the auto attendant’s user options. Enable voicemail access to allow external callers to reach their voicemail boxes by dialing the prompt code you’ve established Enable dial local number to enable an external caller to dial local extensions. Enable override schedule to allow a system administrator to dial a code to replace the schedule with a system schedule. Enable Call Bridge and select an account for external users to dial into the FortiVoice unit and use the FortiVoice service like a local extension.  Select the outbound dial plan for users to call the FortiVoice unit and through it to make outbound calls. Select Create.
Viewing Auto Attendant Hierarchies
FortiVoice provides a auto attendant chart for easy reference. To view the auto attendant hierarchy Go to Call Features > Auto Attendant > Auto Attendant. Select the the Auto Attendant you wish to evaluate.  Select View Hierarchy.  In the example to the right, pressing 2 transfers the call to auto attendant 2. Auto attendant 2 configuration allows you to go to auto attendant 3 by pressing 3 and places you on a call queue if you press 5. Auto attendant 3 configuration allows you to go to the operator by pressing 8.
Configuring Key Actions
Next we’ll need to configure the auto attendant dial pad keys to determine how the caller will navigate through our auto attendant hierarchy. To configure a key action Go to Call Features > Auto Attendant > Auto Attendant. In the Dial Pad Key Action section, select New. Enter the key you want to configure in the Key field. Selection the action you want the unit to take when the caller selects the number.  Select Create.

The post Configuring Alerts in FortiVoice Enterprise appeared first on Fortinet Cookbook.

This recipe will walk you through the configuration of FortiAuthenticator as the RADIUS server for a FortiGate wireless controller. WPA2-Enterprise with 802.1X authentication can be used to authenticate wireless users with FortiAuthenticator. 802.1X utilizes the Extensible Authentication Protocol (EAP) to establish a secure tunnel between participants involved in an authentication exchange.

EAP-TLS is the most secure form of wireless authentication because it replaces the client username/password with a client certificate. Every end user, including the authentication server, that participates in EAP-TLS must possess at least two certificates: 1) A client certificate signed by the certificate authority (CA) and 2) a copy of the CA root certificate.

This recipe specifically focus on the configuration of the FortiAuthenticator, FortiGate and Windows 7 computer.

1. Creating a local CA on FortiAuthenticator The FortiAuthenticator will act as the certificate authority for all certificates authenticated for client access. To enable a this functionality, a self-signed root CA certificate must be generated.
On the FortiAuthenticator, go to Certificate Management > Certificate Authorities > Local CAs. Click Create New. Complete the information in the fields pertaining to your organization.
2. Creating a local service certificate on FortiAuthenticator In order for the FortiAuthenticator to use a certificate in mutual authentication (supported by EAP‐TLS), a local services certificate has to be created on behalf of the FortiAuthenticator.
Go to Certificate Management > End Entities > Local Services. Click Create New. Complete the information in the fields pertaining to your organization.
3. Configuring RADIUS EAP on FortiAuthenticator In order for the FortiAuthenticator to present the newly created Local Services certificate as its authentication to the WiFi client, the RADIUS­‐EAP must be configured to use this certificate.
Go to Authentication > RADIUS Service > EAP. Click Create New. Select the corresponding Local Services certificate in the EAP Server Certificate section. Choose the Local CA certificate previous configured in the Local CAs section.
4. Configuring RADIUS client on FortiAuthenticator The FortiAuthenticator has to be configured to allow RADIUS clients to make authorization requests to it.
Go to Authentication > RADIUS Service > Clients. Click Create New. Enter Name, then Client name IP which is the FortiGate’s IP address. Enter the Secret (password). On Authentication method select Password-only authentication and on Username input format select username@realm.
EAP-­‐TLS should be the only EAP type selected to prevent fallback to a less secure version of authentication if a certificate is not presented by the WiFi client.
5. Configuring local user on FortiAuthenticator The authentication of the WiFi client will be tied to a user account on the FortiAuthenticator. In this scenario, a local user will be configured but remote users associated with LDAP can be configured as well.
Go to Authentication > User Management > Local Users. Click Create New. Fill out applicable user information.
6. Configuring end user certificate on FortiAuthenticator The certificate created locally on the FortiAuthenticator will be associated with the local user. It is important to note that the Name (CN) must match the username exactly of the user that is registered in the FortiAuthenticator (i.e. eap-­‐user in this case).
Go to Certificate Management > End Entities > Users. Click Create New. Fill out applicable user information to map the certificate to the correct user.
7. Creating RADIUS server on FortiGate In order to proxy the authentication request from the wireless client, the FortiGate will need to have a RADIUS server to submit the authentication request to.
On the FortiGate, go to User & Device > RADIUS Servers. Select Create New. Type FortiAuth. Enter the FortiAuthenticator’s IP address and the Server Secret (password). Optionally, you can click Test Connectivity. Enter a RADIUS user’s ID and password. The result should be “Successful”.
8. Creating WiFi SSID on FortiGate In order for the WiFi client to connect using its certificate a SSID has to be configured on the FortiGate to accept this type of authentication.
Go to WiFi & Switch Controller > SSID. Create an SSID and set up DHCP for clients.
Set WPA2-Enterprise with RADIUS Server authentication, and choose FortiAuth.
9. Exporting user certificate from FortiAuthenticator In order for the WiFi client to authenticate with the RADIUS server, the user certificate created in the FortiAuthenticator must first be exported.
On the FortiAuthenticator, go to Certificate Management > End Entities > Users. Click the checkbox beside the certificate. Click Export PKCS#12.
In the Export User Certificate and Key File type a password in Passphrase, and confirm it. This password will be used when importing the certificate into a Windows 7 computer. Click OK.
Click Download PKCS#12 file to pull this certificate to the Widows 7 computer. Click Finish.
9. Importing user certificate into Windows 7
On the Windows 7 computer, double-click the downloaded certificate file from the FortiAuthenticator. This will launch the Welcome to Certificate Import Wizard. Click Next.
Make sure the correct certificate is shown in the File Name section in the File to Import window. Click Next.
Below Password, type the password created on the FortiAuthenticator during the export of the certificate. Select Mark this key as exportable. Leave remaining defaults. Click Next.
In the Certificate Store, choose the Place all certificates in the following store. Click Browse and choose Personal. Click Next, and then Finish. A dialog box will show up confirming the certificate was imported successfully.
10. Configuring Windows 7 wireless profile to use certificate
Create a new wireless SSID for this secure connection, in this case EAP-TLS. On Windows 7, got to Control Panel > Network and Sharing Center > Manage Wireless Networks > Add. Select Security type: WPA2-Enterprise and Encryption type: AES.
Modify the newly created wireless connection EAP-TLS by right clicking and choosing Propeties.
On EAP-TLS Wireless Network Properties, Under Choose a network authentication method select Microsoft: Smart card or other certificates. Then click on Settings.
On Smart Card or other Certificates Properties. Under When connecting, select Use a certificate on this computer, and check Use simple certificate selection. Click OK and click OK. Please note, for simplification purposes, the Validate server certificate has been disabled but EAP-­‐TLS allows the client to validate the server as well as the server validate the client. To enable this, you will need to import the CA from the FortiAuthenticator to the Windows 7 computer and make sure that it is enabled as a Trusted Root Certification Authority. The configuration for the Windows 7 computer has been completed and the user should be able to authenticate to WiFi via the certificate without using username and password.
11. Results on FortiAuthenticator
When the user attempts to authenticate to WiFi using the certificate, they will have a specific log entry in the FortiAuthenticator.
12. Results on FortiGate
The log on the FortiGate show plenty of details, such as the client’s MAC address, IP address, SSID, Security Mode, Encryption, AP, Radio, Band and Channel

The post WiFi using FortiAuthenticator RADIUS (EAP-TLS) appeared first on Fortinet Cookbook.

Often times callers outnumber available agents. Forcing a caller to call back repeatably to reach an available agent is bad for customer satisfaction and business. Thankfully, FortiVoice Enterprise  queues multiple incoming calls and prioritizing them. 

This recipe guides you through the process of creating a call queue to handle large volumes of incoming calls and then set up the appropriate department to handle the calls.

Creating a Call Queue
First we’ll need to create a call queue that will establish the order in which to place incoming calls when an agent is unavailable. To create a call queue Go to Call Center > Call Queue. Select New. Enter or select a suggested number.  Enter a display name and a brief description. Enter the desired queue settings and select the music to play while the client is on hold. Select the desired call distribution policy from the dropdown menu: • Ring all: Dials all available agents.  • Round robin: Dials all agents in order from top to bottom and then bottom to top. • Sequential: Dials each agent in a sequential manner. • Random: Dials an agent at random. • Least recent: Dials the agent that least recently received a call. • Fewest calls: Dials the agent that has completed the fewest calls in this queue. • Weight random: Dials a random agent, but uses the agent’s penalties as a weight. • Skill based: Dials agents based on the agents’ rated ability to handle calls in that call center Select your desired agent login mode. Static agents are always connected to the queues while dynamic agents need to lon in. Enter time needed by agents to complete a queue call. Select Create.  More information on additional settings can be found in the FortiVoice Enterprise Administrator Guide.
Configuring Departments
With the call queue created, we’ll now need to configure the department the client will contact. To set up a department Go to Call Center > Agents > Department. Select New. Enter a name for the department and any notes you may require for the department. Move the individuals you want to be department managers to the Selected column and then select done. Move the members of the department to the Selected column and then select done. Move the call queues of the department to the Selected column and then select done. Select Create.

The post Establishing a Call Center in FortiVoice Enterprise appeared first on Fortinet Cookbook.

In this episode, Sandip Borle, Eric Schulhof, and Alan Russell discuss FortiSwitch and how FortiLink can be used to extend FortiGate security across a network.

More FortiSwitch/FortiLink resources

• Managing FortiSwitches using FortiGate (for FortiOS 5.4.1+)
• FortiSwitch Secure Access Switches datasheet

Subscribe to FortiCast

The post Episode 4: FortiSwitch & FortiLink appeared first on Fortinet Cookbook.

What if you want someone from your documentation team to have access to the mailbox of your customer service department? Sharing voice mail between multiple users, both inside and outside of a department, is an important service provided by FortiVoice Enterprise. 

With a general voice mailbox, an entire group is notified when there is a new voice mail. Any member can access the voice mail, which will deactivate the notification so others know that the voice mail has been handled.

This recipe guides you through the process of establishing a general voice mailbox in FortiVoice Enterprise.

Creating a General Voice Mailbox

To set up a general voice mailbox To create a call queue Go to Extensions > General Voicemail > General Voicemail. Select New or double-click an existing record. Enter your User ID and the mailbox extension number. Enter the password for the user to access voicemail. Select either Local or LDAP as your authentication type. If you select LDAP, be sure to select LDAP profile to apply to the extension. SElect the way to deliver the voicemail from this mailbox extension to the users sharing this mailbox. – Centralized: Copies or notifies the entire group when a new voicemail is received. Any member can access the voicemail, which will end the notification for other users. – Broadcast: The voicemail is sent to the voicemail boxes of its individual users. Users can access the voicemail by dialing a customized code. Select the users or groups in the Participants field that require notification when a voicemail is received Select Create or OK.

The post Establishing a Voice Mailbox in FortiVoice Enterprise appeared first on Fortinet Cookbook.

As is common on websites with a comments section, the user feedback on this site is moderated. Submitted comments may be held in a pending state until one of the site moderators takes a look at it and decides on whether or not to publish it for public viewing. In addition, published comments may later be deleted. We thought we should explain why some make the cut and others do not.

Let’s start with the least likely and most likely to get published.

The first and easiest comments to eliminate from contention to be published are the ones that are considered “Spam” or offensive. I don’t think I even need to go into the reasons for these. Only FortiGuard enjoys getting spam, and that’s to analyze its content for malware. Offensive comments have no place on our cookbook site.

The comments section for articles on the site are for feedback, requests for more content, or questions about the topic of the article or recipe. Comments can also enhance the article by answering questions or providing additional content that may be helpful to subsequent readers. The two principle criteria for making sure a comment is retained is to have it be on topic and have it be specific. A specific question about the topic of the article that you comment on in the best way to ensure that the comment will be addressed and no removed.

While we like comments that tell us how great an article or our site is, we also appreciate constructive criticism. The important word in the phrase being “constructive”.  No writer is perfect and occasionally, readers see ways to improve our documentation. If you do see something like this, you are encouraged to let us know. We happily take any suggestions we can use to make ourselves look like we’re smarter and better writers than we actually are. But again, specifics help. It does nobody any good to say an article is horrible if there is no reason why it’s horrible. In a case like this, the comment is likely to be removed because it doesn’t help us improve the article and it doesn’t provide any new or usable information to subsequent readers. On the other hand, if someone comments that an article is incorrect and should instead be (fill in correct information here), that information is useful and actionable. It can be used to improve the article. You are likely to be thanked. But please, don’t use words like “horrible”. Writers have feelings too.

Sometimes, people wish to leave comments on the products themselves. These can be problematic if they are not relevant to the article itself. If the comment is something that can help users make use of the product, we will consider keeping it on a case by case basis. If the comment is constructive but not applicable to the documentation, it may be deleted but the feedback will be forwarded to the appropriate people.

The last broad category is comments that are off on a tangent or completely unrelated to the article. The information may well be useful, but if the subject is so far removed from the topic of the article, readers who would find the information useful will have no way to find it and it will likely be a distraction to readers who are interested in the topic of the article. Unless the comment somehow touches on something that would be useful to readers of the article, this sort of feedback will likely be removed. If you can, find a more appropriate article to make the comment.

As mentioned before, at times, comments may get removed. The two most likely causes for this are that the user’s feedback has been incorporated into the article itself and the comment will just confuse readers because it refers to an aspect of the article that is no longer there or the information in the comment is no longer relevant.

This is a corporate web site rather than a public forum. While we wish to be as fair and inclusive to everybody’s feedback as possible, we do have the final say on what appears on our site. Our primary objective is to promote the intent and purpose of the site, which is to provide useful information and knowledge regarding the use and maintenance of the discussed Fortinet products. If your comment was not published or later removed, chances are it didn’t or no longer furthered that agenda.

The post Site policy on comments appeared first on Fortinet Cookbook.

In this video, you’ll learn how to block access to social media websites using FortiGuard categories. You’ll need an active license for FortiGuard Web Filtering services. FortiGuard categories allow you to take action against a group of websites in a certain category. Computers on your internal network will not have access to any websites that are fall into FortiGuard’s social media category. 

The recipe for this video is available here.

Watch more videos

The post Blocking Social Media (Video) appeared first on Fortinet Cookbook.

Ben Wilson and Philip Keeley discus the key features of FortiCloud, our cloud-based management platform for FortiGate and FortiAP.

More FortiCloud resources

• FortiCloud website
• FortiCloud 3.1 FAQ
• FortiCloud datasheet
• Fortinet Cookbook recipes using FortiCloud

Subscribe to FortiCast

The post Episode 5: FortiCloud appeared first on Fortinet Cookbook.

This is an example on how to configure a simple full mesh VPN with:

• Three FortiGate (FGT) devices
• Pre-shared key for authentication
• Auto-up tunnel setting
• Static Routes

1. Add FortiGate Devices and Map all Interfaces
Go to Device Manager, and add three FortiGate devices, by clicking Add Device. Follow the wizard to add each device. Go to Policy & Objects > Policy Packages and define Zone interfaces. Go to Device Manager and select a device. Go to System: Interface and map interfaces to the Zone interfaces.
2. Create Firewall Address for Protected Subnets
Go to Policy & Objects > Object Configurations > Firewall Objects > Address to manage the firewall addresses. VPN only supports firewall address with the type set to subnet (IP/Netmask). The firewall addresses will be used as protected subnets to generate static routes among the FortiGate devices.
3. Create a VPN Community
Go to VPN Manager > VPN Community list > Create New. Set the VPN topology type to Full Meshed.
Define the authentication method with a pre-shared key. Specify encryption and hash methods.
After defining authentication methods and encryption properties, click Next. Configure VPN Phase 1 and Phase 2 settings.
For the IPSec Phase 2 setting, set the tunnel to Auto-Negotiate. Optionally, under Advanced Options > the IKE version must be set to two in order to use IPv6 over tunnels.
VPN configuration summary:
4. Add VPN Gateway
Go to VPN Manager > VPN Community. In the content pane, from the Create New menu, select Managed Gateway. Add a Protected Network. There can be more than one protected networks.
Select a Device.
Select a default VPN interface. The default VPN interface should have a valid IP and mapped.
Optionally, specify the local gateway. This option can be left blank in most cases.
Routing > select Automatic to generate static routes. If Manual is selected, go to the Device Manager to set the IP on the relevant IPSec interfaces and define the routings manually.
VPN gateway configuration settings summary:
5. Create Firewall Policies
Go to Policy & Objects > Policy Packages to create policies among the default VPN zones and protected-subnet interfaces. Use the Install-On option to restrict policies applied on specific FortiGate devices. Do not forget to create policies for bi-directional traffic.

For further FortiManager information, refer to the FortiManager Administration Guides available on the Fortinet Document Library.

The post FortiManager: Configure a Full Mesh VPN Topology within VPN Console appeared first on Fortinet Cookbook.

The first episode of FortiCast, the podcast for all things Fortinet. This episode includes a brief overview of what you can expect from the podcast and a preview from an upcoming episode.

Subscribe to FortiCast

The post Episode 1: Introduction to FortiCast appeared first on Fortinet Cookbook.

This recipe is a followup to the ADVPN basic recipe. As we have seen in the base configuration, ADVPN provides the means for spokes to automatically establish VPN sessions in a peer-to-peer fashion without the hub being involved in data forwarding. This recipe explores how redundancy can be achieved for the hub functions within an ADVPN environment.

As ADVPN leverages BGP, a redundant hub configuration involves having a second hub device that will also act as a route reflector for the topology. That redundant hub device could be located in a geographically distinct site, in the same datacenter or even as an additional VDOM on the same physical device. Each ADVPN topology generally benefits from residing in its own VDOM or physical device.

ADVPN topologies can be regrouped under 3 deployment scenarios. While each of these scenario can benefit from FGCP for physical device redundancy, only the dual hub scenario provides logical redundancy for a given group of spokes (which we will term a “region”):

• Single hub: this offers no logical redundancy. A single hub with a single ADVPN IPSec topology running in a single BGP autonomous system.
• Dual hub: this offers logical redundancy. Each additional hub role runs on a distinct VDOM or physical device. Each additional hub runs a topology within the same BGP autonomous system, however hubs (route reflectors) are unaware of each other.
• Dual regions: this offers no logical redundancy. This reflects a configuration in which we have distinct BGP autonomous systems, each with distinct hubs which are interconnected and have shortcut forwarding enabled between the hubs. Spokes are only connected to the hub of their own region. While this scenario can be combined with “dual hub” to effectively create logically redundant regions, it is not in itself a redundancy technique as spokes are not peered with more than a single BGP route reflector. It is redundant only in the sense that one hub being unavailable would result in only partial availability issues.

More information on dual region setups can be obtained here: http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD39360

When multiple ADVPN hubs are deployed, careful consideration should be given to ensure that traffic will use the same forward and reverse path due to the issues that can arise from symmetric routing in a firewall environment. While a layered model with a stateless ADVPN topology can be leveraged for ECMP load balancing, in this recipe we will explore a simpler version of redundancy in which one hub is designated as primary, with the secondary hub’s topology being only leveraged upon failure of the first hub.

Our topology is the following:

When compared with our original ADVPN article, this topology sees the addition of a hub unit. Our example assumes WAN connectivity between the hub sites, which could be replaced with additional hub-to-hub VPN links. We are also adding an additional device to this scenario, termed “ISFW”, which we use to advertise a route in OSPF in order to test connectivity.

A few topology notes are in order before we go over the configuration:

• The topology makes use of a second BGP route reflector however neither route reflector is aware of the other, as this introduces complexity related to route advertisement.
• The topology prioritizes ADVPN1. 
• The topology assumes that both hubs and spokes have a single ISP link. In the case of multiple ISPs at either hub or spoke, a decision must be made as to which ADVPN topology is used for each ISP and how fully meshed the overlay VPNs must be. A common scenario is to have dual ISPs for the spokes where one ISP is used for ADVPN1 and the second is used for ADVPN2, in which case the configuration is no different from the topology we use in this article.
• This example however does maintain that ADVPN2‘s hub direct attached subnets are being sent towards ADVPN2 directly. All other hub-destined traffic will cross ADVPN1.

Things are going to get slightly more complex that a standard ADVPN configuration here, however this article will try to clarify the configurations made as they are listed below.

config vpn ipsec phase1-interface
    edit "ADVPN"
        set type dynamic
        set interface "port1"
        set proposal aes128-sha1
        set add-route disable
        set dhgrp 14
        set auto-discovery-sender enable
        set psksecret somereallysecuresauuuuce
        set dpd-retrycount 3
        set dpd-retryinterval 2
        set dpd on-idle
    next
end

config vpn ipsec phase2-interface
    edit "ADVPN-P2"
        set phase1name "ADVPN"
        set proposal aes128-sha1
    next
end

config system interface
    edit "ADVPN"
        set vdom "root"
        set ip 10.10.10.1 255.255.255.255
        set type tunnel
        set remote-ip 10.10.10.254
        set interface "port1"
    next
end

config router prefix-list
    edit "PF_REDIS_CONNECTED"
        config rule
            edit 1
                set prefix 192.168.1.0 255.255.255.0
                unset ge
                unset le
            next
            edit 2
                set prefix 192.168.0.0 255.255.255.0
                unset ge
                unset le
            next
        end
    next
end
config router route-map
    edit "RM_REDIS_CONNECTED"
        config rule
            edit 1
                set match-ip-address "PF_REDIS_CONNECTED"
            next
            edit 2
                set action deny
            next
        end
    next
    edit "RM_OSPF_TO_BGP"
        config rule
            edit 1
                set set-local-preference 50
                set set-weight 0
            next
        end
    next
end

config router bgp
    set as 65000
    set router-id 192.168.1.1
    set distance-internal 100
    config neighbor-group
        edit "ADVPN"
            set advertisement-interval 10
            set next-hop-self enable
            set remote-as 65000
            set keep-alive-timer 2
            set holdtime-timer 6
            set route-reflector-client enable
        next
    end
    config neighbor-range
        edit 1
            set prefix 10.10.10.0 255.255.255.0
            set neighbor-group "ADVPN"
        next
    end
    config redistribute "connected"
        set status enable
        set route-map "RM_REDIS_CONNECTED"
    end
    config redistribute "ospf"
        set status enable
        set route-map "RM_OSPF_TO_BGP"
    end
end

config router ospf
    set router-id 192.168.0.1
    config area
        edit 0.0.0.0
        next
    end
    config network
        edit 1
            set prefix 192.168.0.0 255.255.0.0
        next
    end
    config redistribute "bgp"
        set status enable
    end
end

config firewall policy
    edit 0
        set name "OUT ADVPN"
        set srcintf "port1" "port2" "port3" "ADVPN"
        set dstintf "port1" "port2" "port3" "ADVPN"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set status enable
    next
end

config vpn ipsec phase1-interface
    edit "ADVPN"
        set type dynamic
        set interface "port1"
        set proposal aes128-sha1
        set add-route disable
        set dhgrp 14
        set auto-discovery-sender enable
        set psksecret somereallysecuresauuuuce
        set dpd-retrycount 3
        set dpd-retryinterval 2
        set dpd on-idle
    next
end

config vpn ipsec phase2-interface
    edit "ADVPN-P2"
        set phase1name "ADVPN"
        set proposal aes128-sha1
    next
end

config system interface
    edit "ADVPN"
        set vdom "root"
        set ip 10.10.11.1 255.255.255.255
        set type tunnel
        set remote-ip 10.10.11.254
        set interface "port1"
    next
end

config router prefix-list
    edit "PF_REDIS_CONNECTED"
        config rule
            edit 1
                set prefix 192.168.2.0 255.255.255.0
                unset ge
                unset le
            next
            edit 2
                set prefix 192.168.0.0 255.255.255.0
                unset ge
                unset le
            next
        end
    next
end
config router route-map
    edit "RM_REDIS_CONNECTED"
        config rule
            edit 1
                set match-ip-address "PF_REDIS_CONNECTED"
            next
            edit 2
                set action deny
            next
        end
    next
    edit "RM_OSPF_TO_BGP"
        config rule
            edit 1
                set set-local-preference 25
                set set-weight 0
            next
        end
    next
end

config router bgp
    set as 65000
    set router-id 192.168.2.1
    set distance-internal 100
    config neighbor-group
        edit "ADVPN"
            set advertisement-interval 10
            set next-hop-self enable
            set remote-as 65000
            set keep-alive-timer 2
            set holdtime-timer 6
            set route-reflector-client enable
        next
    end
    config neighbor-range
        edit 1
            set prefix 10.10.11.0 255.255.255.0
            set neighbor-group "ADVPN"
        next
    end
    config redistribute "connected"
        set status enable
        set route-map "RM_REDIS_CONNECTED"
    end
    config redistribute "ospf"
        set status enable
        set route-map "RM_OSPF_TO_BGP"
    end
end

config router ospf
    set router-id 192.168.0.2
    config area
        edit 0.0.0.0
        next
    end
    config network
        edit 1
            set prefix 192.168.0.0 255.255.0.0
        next
    end
    config redistribute "bgp"
        set status enable
        set metric 5
    end
end

config firewall policy
    edit 0
        set name "OUT ADVPN"
        set srcintf "port1" "port2" "port3" "ADVPN"
        set dstintf "port1" "port2" "port3" "ADVPN"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set status enable
    next
end

config vpn ipsec phase1-interface
 edit "ADVPN"
  set interface "port1"
  set proposal aes128-sha1
  set add-route disable
  set dhgrp 14
  set auto-discovery-receiver enable
  set remote-gw 192.0.2.11
  set psksecret ***
  set dpd-retrycount 3
  set dpd-retryinterval 2
  set dpd on-idle
 next
 edit "ADVPN2"
  set interface "port1"
  set proposal aes128-sha1
  set add-route disable
  set dhgrp 14
  set auto-discovery-receiver enable
  set remote-gw 192.0.2.12
  set psksecret ***
  set dpd-retrycount 3
  set dpd-retryinterval 2
  set dpd on-idle
 next
end

config vpn ipsec phase2-interface
    edit "ADVPN-P2"
        set phase1name "ADVPN"
        set proposal aes128-sha1
	set auto-negotiate enable
    next
    edit "ADVPN2-P2"
        set phase1name "ADVPN2"
        set proposal aes128-sha1
	set auto-negotiate enable
    next
end

config system interface
    edit "ADVPN"
        set vdom "root"
        set ip 10.10.10.3 255.255.255.255
        set type tunnel
        set remote-ip 10.10.10.1
        set interface "port1"
    next
    edit "ADVPN2"
        set vdom "root"
        set ip 10.10.11.3 255.255.255.255
        set type tunnel
        set remote-ip 10.10.11.1
        set interface "port1"
    next
end

config router route-map
    edit "RM_ADVPN1"
        config rule
            edit 1
                set set-local-preference 200
            next
        end
    next
end
config router bgp
    set as 65000
    set router-id 192.168.3.1
    config neighbor
        edit "10.10.10.1"
            set remote-as 65000
            set route-map-out "RM_ADVPN1"
        next
        edit "10.10.11.1"
            set remote-as 65000
        next
    end
    config network
        edit 1
            set prefix 192.168.3.0 255.255.255.0
        next
    end
end

config router static
    edit 0
        set dst 10.10.10.0 255.255.255.0
        set device "ADVPN"
    next
    edit 0
        set dst 10.10.11.0 255.255.255.0
        set device "ADVPN2"
    next
    edit 0
        set dst 10.10.10.0 255.255.255.0
        set distance 254
        set blackhole enable
    next
    edit 0
        set dst 10.10.11.0 255.255.255.0
        set distance 254
        set blackhole enable
    next
end

config firewall policy
    edit 0
        set name "Allowed traffic"
        set srcintf "lan" "ADVPN" "ADVPN2"
        set dstintf "lan" "ADVPN" "ADVPN2"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set status enable
    next
end

Results

The following schemas help understand the routing logic implemented by this article:

OSPF routes are redistributed into BGP using a local preference of 50 for HUB1 and 25 for HUB2 (#1 in diagram). Connected routes are redistributed with the default local preference of 100 (#2 in diagram) . As BGP prefers routes with higher local preferences, this logic ensures that a connected route advertised by a HUB to its spokes is preferred over that connected route being redistributed in OSPF and advertised by the other HUB (#3 in diagram). Take a look at this output from SPOKE1:

SPOKE1 # get router info bgp network
BGP table version is 2, local router ID is 192.168.3.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>i192.168.0.0      10.10.10.1               0    100      0 ?
* i                 10.10.11.1               0    100      0 ?
* i192.168.1.0      10.10.11.1               2     25      0 ?
*>i                 10.10.10.1               0    100      0 ?
* i192.168.2.0      10.10.10.1               2     50      0 ?
*>i                 10.10.11.1               0    100      0 ?
*> 192.168.3.0      0.0.0.0                       100  32768 i
*>i192.168.4.0      10.10.10.4               0    200      0 i
* i                 10.10.11.4               0    100      0 i

Total number of prefixes 5

SPOKE1 # 

In this topology’s use case, this is preferable as it ensures traffic going to 192.168.1.0/24 or 192.168.2.0/24 will, under normal conditions, use the VPN to the hub the route is directly connected to rather than circling around through the other hub. As the output illustrates, while SPOKE1 has alternate paths for both HUB networks but prefers using the direct path through each respective network’s hub.

When receiving routes from spokes on either HUB, BGP routes are redistributed into OSPF. Metrics of 1 on the preferred path and 5 on the backup path ensure that traffic flowing in and out of the datacenter’s shared subnets (e.g. 192.168.100.0/24) follows the same path. The following output from our ISFW device (which is a basic OSPF router for the intent of this topology) shows those metrics applied with preference for SPOKE1 prefix 192.168.3.0/24 taking the path through ADVPN1 (HUB1):

FGT-5 # get router info routing-table details 192.168.3.0
Routing entry for 192.168.3.0/24
  Known via "ospf", distance 110, metric 1, best
  Last update 00:03:21 ago
  * 192.168.0.1, via port1

FGT-5 # get router info ospf database external lsa 192.168.3.0

                AS External Link States 

  LS age: 816
  Options: 0x2 (*|-|-|-|-|-|E|-)
  LS Type: AS-external-LSA
  Link State ID: 192.168.3.0 (External Network Number)
  Advertising Router: 192.168.0.1
  LS Seq Number: 80000001
  Checksum: 0x1adf
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 1
        Forward Address: 0.0.0.0
        External Route Tag: 1

  LS age: 133
  Options: 0x2 (*|-|-|-|-|-|E|-)
  LS Type: AS-external-LSA
  Link State ID: 192.168.3.0 (External Network Number)
  Advertising Router: 192.168.0.2
  LS Seq Number: 80000002
  Checksum: 0x28cc
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 5
        Forward Address: 0.0.0.0
        External Route Tag: 0

Spokes advertise their own routes by setting a local preference of 200 on the primary ADVPN topology and leaving the default local preference of 100 on the secondary ADVPN topology. This is consistent with the goals of this architecture by ensuring spoke-originated routes are systematically preferred using ADVPN1. 

Both local preferences associated with spoke originated routes (200 and 100) are higher than those of OSPF redistribution (50 and 25) – again, this is to ensure we never favour spoke routes that have looped through OSPF for inter-spoke traffic. In the above example of routing, SPOKE1 has advertised its routes to HUB1 using local preference of 200. HUB1 reflects this route to SPOKE2 and we have reachability as shown from the below output from SPOKE2:

SPOKE2 # get router info bgp network 192.168.3.0
BGP routing table entry for 192.168.3.0/24
Paths: (2 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  Local
    10.10.10.3 from 10.10.10.1 (192.168.3.1)
      Origin IGP metric 0, localpref 200, valid, internal, best
      Originator: 192.168.3.1, Cluster list: 10.10.10.1 
      Last update: Mon Jan  9 12:37:06 2017

  Local
    10.10.11.3 from 10.10.11.1 (192.168.3.1)
      Origin IGP metric 0, localpref 100, valid, internal
      Originator: 192.168.3.1, Cluster list: 10.10.11.1 
      Last update: Mon Jan  9 12:37:06 2017

As expected, SPOKE2 prefers routes from SPOKE1 when advertised over ADVPN1 due to the local preference being higher. As the output confirms however, there is predictably no route originating from either HUB and injected from OSPF – both hubs having an administrative distance of 100 for internal BGP results in BGP routes always being preferred over OSPF routes and thus, “backdoor” routes going through OSPF are not normally inserted into BGP by either hub. However, if we simulate a failure between SPOKE1 and HUB2 (ADVPN2):

SPOKE1 # config sys int
SPOKE1 (interface) # edit ADVPN2
SPOKE1 (ADVPN2) # set status down 
SPOKE1 (ADVPN2) # end
SPOKE1 # 

SPOKE2 # get router info bgp network 192.168.3.0
BGP routing table entry for 192.168.3.0/24
Paths: (2 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  Local
    10.10.10.3 from 10.10.10.1 (192.168.3.1)
      Origin IGP metric 0, localpref 200, valid, internal, best
      Originator: 192.168.3.1, Cluster list: 10.10.10.1 
      Last update: Mon Jan  9 12:37:06 2017

  Local
    10.10.11.1 from 10.10.11.1 (10.10.11.1)
      Origin incomplete metric 1, localpref 25, valid, internal
      Last update: Mon Jan  9 13:02:19 2017

… SPOKE2’s route that was redistributed by HUB1 into OSPF now does indeed appear in the list as HUB2 no longer receives a better iBGP route from SPOKE1. That route is still not being used given that our primary ADVPN1 path is still quite functional. Should we however add another failure, this time between SPOKE2 and HUB1 (ADVPN1):

SPOKE2 # config sys int
SPOKE2 (interface) # edit ADVPN
SPOKE2 (ADVPN) # set status down
SPOKE2 (ADVPN) # end
SPOKE2 # 

SPOKE2 # get router info bgp network 192.168.3.0
BGP routing table entry for 192.168.3.0/24
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  Local
    10.10.11.1 from 10.10.11.1 (10.10.11.1)
      Origin incomplete metric 1, localpref 25, valid, internal, best
      Last update: Mon Jan  9 13:02:19 2017


SPOKE2 # exec ping-options source 192.168.4.1

SPOKE2 # exec ping 192.168.3.1
PING 192.168.3.1 (192.168.3.1): 56 data bytes
64 bytes from 192.168.3.1: icmp_seq=0 ttl=253 time=6.5 ms
64 bytes from 192.168.3.1: icmp_seq=1 ttl=253 time=0.9 ms
64 bytes from 192.168.3.1: icmp_seq=2 ttl=253 time=1.1 ms
64 bytes from 192.168.3.1: icmp_seq=3 ttl=253 time=1.1 ms
^C
--- 192.168.3.1 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.9/2.4/6.5 ms

SPOKE2 # get router info routing-table details 192.168.3.0
Routing entry for 192.168.3.0/24
  Known via "bgp", distance 200, metric 1, best
  Last update 00:09:42 ago
  * 10.10.11.1, via ADVPN2

… SPOKE2 now only has the path going through HUB2, then HUB1 in order to reach SPOKE1. Worthwhile to note that in this condition, no ADVPN SHORTCUT will establish as spoke devices are on segregated ADVPN topologies and do not share a common ADVPN hub. If we restore services:

SPOKE1 # config sys int
SPOKE1 (interface) # edit ADVPN2
SPOKE1 (ADVPN2) # set status up 
SPOKE1 (ADVPN2) # end
SPOKE1 # 

SPOKE2 # config sys int
SPOKE2 (interface) # edit ADVPN
SPOKE2 (ADVPN) # set status up
SPOKE2 (ADVPN) # end
SPOKE2 # 

… we return to correct routing tables. If we then issue some traffic towards SPOKE1’s subnet, we get the initiation of an ADVPN SHORTCUT directly to SPOKE1:

SPOKE2 # get router info routing-table details 192.168.3.0
Routing entry for 192.168.3.0/24
  Known via "bgp", distance 200, metric 0, best
  Last update 00:00:37 ago
  * 10.10.10.3 (recursive via 10.10.10.1)

SPOKE2 # exec ping 192.168.3.1
PING 192.168.3.1 (192.168.3.1): 56 data bytes
64 bytes from 192.168.3.1: icmp_seq=0 ttl=254 time=1.8 ms
64 bytes from 192.168.3.1: icmp_seq=1 ttl=255 time=0.5 ms
64 bytes from 192.168.3.1: icmp_seq=2 ttl=255 time=0.4 ms
64 bytes from 192.168.3.1: icmp_seq=3 ttl=255 time=0.5 ms
64 bytes from 192.168.3.1: icmp_seq=4 ttl=255 time=0.4 ms

--- 192.168.3.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.4/0.7/1.8 ms

SPOKE2 # 
SPOKE2 # get router info routing-table details 192.168.3.0
Routing entry for 192.168.3.0/24
  Known via "bgp", distance 200, metric 0, best
  Last update 00:00:04 ago
  * 10.10.10.3, via ADVPN_0

SPOKE2 # get vpn ipsec tunnel summary 
'ADVPN_0' 192.0.2.13:0  selectors(total,up): 1/1  rx(pkt,err): 4/0  tx(pkt,err): 4/0
'ADVPN' 192.0.2.11:0  selectors(total,up): 1/1  rx(pkt,err): 148/0  tx(pkt,err): 149/0
'ADVPN2' 192.0.2.12:0  selectors(total,up): 1/1  rx(pkt,err): 4102/0  tx(pkt,err): 4103/2

The post Configuring ADVPN in FortiOS 5.4: Redundant hubs (Expert) appeared first on Fortinet Cookbook.

Sometimes two good useful features don’t work together well. That is the case with the WAN Link Load Balancing (WAN LLB) function and the Asymmetric Routing function. In case you may be under the impression that this is a situation that is so unlikely as to never occur, this article is inspired by an actual TAC issue and is being highlighted so that others can avoid the situation.

The expected behavior is that with measure-based load balancing, a session once created should use the same link and there should be no switching between IPS in the middle of a session. The symptom that presented itself was that the sessions were being disconnected and automatically reconnected. It turns out that in an asymmetric routing environment, one of the mechanisms of measure-based load balancing method causes an unintended side effect.

WAN LLB

In order for WAN LLB to work optimally, session level persistence of the connection is required. In an asymmetric environment, when using Bandwidth (GUI) or measure-based (CLI) load balancing methods, the routing information can change in the middle of a session.

Asymmetric Routing

Off

When asymmetric routing is turned off (asymroute disabled),  SNAT is typically enabled on the policy allowing traffic out of the Virtual-WAN-Link or WAN LLB to one of many ISP links. If a session falls into a dirty state and SNAT is enabled, the route-lookup for that session will use the existing interface as a match condition when going through the routing table. This means that unless the change was due to the link actually going down, the outgoing interface will not change and the routing path will remain unchanged.

On

When asymmetric routing is turned on (asymroute enabled), the session revalidation behavior is different. Even if SNAT is enabled, the option of checking the existing interface is not present as a matching condition in the search. When the routing table is scanned, it will just pick the best route regardless of what the previous interface was. Due to the measure-based Virtual WAN LLB algorithm, there is a high probability that the best route is going to be different from the existing one.

Result of the combination

When you have the combination of the WAN LLB, which works best with a persistent connection, and asymmetric routing which does not take measures to preserve a persistent connection, there is a high probability of dropped sessions. An example could  be something like this:

You’re running a connection, such as RDP. Suddenly, the outgoing interfaced changes. Because Source NAT IP does not try to preserve the existing interface, the session is dropped. Now, as per asymmetric routing behavior, packets not matching a session are simply matched against a route and sent out the interface, but they are not NATed. The end result at the other end is that the RDP does not recognize the packets as being part of the same session and rejects them. The RDP connection is lost.

Conclusion

What this means is that it is not impossible to run WAN LLB and asymmetric routing in combination but due to the potential impact it is recommended that it be avoided if at all possible. On the other hand, you may have circumstances that require this combination and the impact of the dropping connections is acceptable to the stake holders. In the end, it is your network and you know it best, so it is your decision to make, but it’s best to make sure your decisions are informed ones.

The post Interactions between WAN LLB and Asymmetric Routing appeared first on Fortinet Cookbook.

In this recipe, you will learn how to authorize FortiMail in FortiSandbox.

In FortiMail 5.2.0 and later, you can configure your FortiMail device to send suspicious files and suspicious attachments to FortiSandbox for inspection and analysis. FortiSandbox is able to perform additional analysis on files that have been scanned by your FortiMail gateway. 

Suspicious email attachments include:

• Suspicious files detected by the AV engine heuristic scan
• Executable files and executable files embedded in archive file types
• Type six hashes (binary hashes) of spam email detected by FortiGuard Antispam device

For further FortiSandbox information, refer to the FortiSandbox Administration Guides available on the Fortinet Document Library.

The post FortiSandbox: Authorizing FortiMail in FortiSandbox appeared first on Fortinet Cookbook.

If you are installing and configuring your applications on Amazon Elastic Compute
Cloud (EC2) dynamically at instance launch time, you will typically need to pull and
install packages, deploy files, and ensure services are started. This bootstrapping
instruction helps simplify, automate, and centralize FortiGate next-generation firewall deployment directly from the configuration scripts stored in AWS Simple Storage Services (S3).

1. Storing configuration and license information
On the AWS console, create an Amazon S3 bucket at the root level for the bootstrap files.
2. Setting up IAM roles
IAM roles need S3 bucket read access. In this example, you are applying the existing policy AmazonS3ReadOnlyAccess to the role by adding the following code: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:Get*", "s3:List*" ], "Resource": "*" } ] } If you need further instructions, please refer to the AWS documentation on IAM Roles for Amazon EC2.
3. Creating S3 buckets with license and firewall configurations
Upload the license file and configuration file(s) to the S3 bucket. In this example, one license file and two configuration files are uploaded.
Amazon S3 creates bucket in a region you specify. You can choose any AWS Region that is geographically close to you to optimize latency, minimize costs, or address regulatory requirements. To choose a region, use the following code: { "bucket" : "confftnt", "region" : "us-west-2", "license" : "/FGVM080000066848.lic", "config" : "/configfirewall.conf", } Although the S3 bucket and the firewall can be in different regions, it is highly recommended that they are in the same region in order to speed up the bootstrapping process.
4. Launching the instance using roles and user data
Follow the normal procedure to launch the instance from the AWS marketplace. When selecting the VPC subnet, the instance needs to be with the role that was created and must specify the information about the license file and configuration file from the AWS S3 bucket previously configured under Advanced Settings.
5. Result
After the instance is launched, check the FortiGate’s System Information widget and verify that the settings and the license information are correct.

For more information on how to bootstrap the FortiGate firewall with configuration and license files within the S3 bucket, please email aws@fortinet.com.

The post Bootstrapping a FortiGate-AWS appeared first on Fortinet Cookbook.

Michael Strickland and Sean Groarke tackle key questions about hardware testing and using FortiTester.

More resources

• FortiTester website
• FortiTester datasheet
• RFC 2544

Subscribe to FortiCast

The post Episode 6: Hardware Testing appeared first on Fortinet Cookbook.

In this video, you’ll learn how to use the Localization features in the FortiPresence dashboard. You’ll find out how to access the information, interpret the results, and how these features can benefit your business.

Watch more videos

The post FortiPresence Overview Part 1(Video) appeared first on Fortinet Cookbook.