IPS Architecture Guide

FortiOS
Table of Contents
What is IPS architecture? 4
Intended audience 4
About this guide 4
Key concepts 5
Operational modes 5
L3 (NAT/route mode) 5
Virtual wire mode 5
Transparent mode 6
Public cloud 7
HA 7
FGCP 7
A-P FGCP cluster 8
A-A FGCP cluster 8
FGSP with IPS inspection 8
Design overview 10
Design concepts and considerations 10
Interfaces 10
Throughput 10
Inspection 10
Solution's access to the Internet 11
Design examples 12
Data center 12
Perimeter 12
DMZ 12
Internal network 13
Enterprise edge 13
Internet to server 13
Client Internet access 13
Remote access 14
Cloud service access 14

IPS Architecture Guide 2

 Partner connections 14
Public cloud 14
VPC or VNet 14
Cloud management security 16
FortiGuard intelligence in cloud-provided firewalls 18
More information 19
Appendix A: Documentation references 19
Feature documentation 19
Solution hub 19
Other 19

IPS Architecture Guide 3

W hat is IPS architecture?
FortiGate Intrusion Prevention System (IPS) architecture is designed to provide real-time threat protection to
enterprise networks. FortiGate IPS leverages a combination of signature-based, behavior-based, and
anomaly-based detection techniques to detect and prevent a wide range of security threats.

IPS architecture addresses how and where you can leverage IPS to bolster a company’s security posture.

Intended audience

This guide has primarily been created for a technical audience, including system architects and design
engineers who want to understand how and where IPS can benefit their company. This guide benefits those
in the assessment and planning phase.

About this guide

The guide is meant to provide high-level insight on FortiGate IPS architectures for different deployment
modes. You are meant to use this guide in conjunction with other technical documentation for each
component that the guide lists. W here relevant, the guide lists links to the administrative guides and other
technical reference guides.

IPS Architecture Guide 4

Key concepts
Before discussing the various architectures, this guide explores a couple key components integral to the
operation. These components are FortiGate operational modes and high availability. Understanding these
concepts and how you can implement them in your deployment and the benefit each can bring when
implemented correctly is imperative.

Operational modes

FortiGate can apply intrusion prevention through a variety of different operational modes. Each mode has
benefits and drawbacks which you should consider when choosing where to deploy your IPS solution. All
installation methods have the same IPS functionality, so the mode becomes the main consideration for each
architecture. You should examine your existing topology or review your planned deployment, then choose
your operation mode wisely. The placement of your FortiGate/FortiGates dictates what mode to use.

L3 (NAT/route mode)
In this mode, the FortiGate firewall operates as a Layer 3 (L3) router and is responsible for routing traffic
between different network segments.

W hen FortiGate operates in L3 mode (NAT/route mode), FortiGate places an L3 network where the traffic is
routed. Typically, perimeter SD-W AN installations require FortiGate to run in NAT route mode. To run
FortiGate in NAT route mode, you must configure an IP address statically or dynamically to each interface.
MAC-based policies are only applicable for the IPS policy source address in NAT route mode as the
destination MAC address is the FortiGate interface MAC address.

Virtual wire mode

This operation mode deploys the FortiGate between two network segments. The FortiGate operates like a
"virtual wire." It does not perform routing or NAT and does not require any changes to the existing network

IPS Architecture Guide 5

OPERATIONAL MODES

topology or IP addressing.

In virtual wire operation mode, you must pair two interfaces in the configuration. You can configure multiple
pairs of virtual wire pair interfaces on the same firewall in a single VDOM. In case the paired ports are trunk
ports, you can configure policies based on the VLAN or you can apply a global policy to all VLANs passing
through the virtual wire. Configuring policies based on VLAN allows you to granularly control the traffic per
VLAN.

In virtual wire operation mode, FortiGate does not act like a bridge, and firewall policies control traffic flow.
To forward any L2 traffic like STP, LACP, there are specific parameters under the physical interface that you
must enable. Enabling corresponding L2 packet types is important if FortiGate is between two switches. The
advantage is that there is no L3 address change required for virtual wire operation. Using virtual wire mode
does not require changing the FortiGate overall operation mode or introducing VDOMs. A virtual wire pair
configuration is sufficient to make the FortiGate operate in NAT mode. In virtual wire mode, you can use both
source and destination MAC address objects in IPS policies.

Transparent mode
Transparent mode is an operation mode where the FortiGate acts like a bridge. It is similar to virtual wire
mode except that in transaparent mode, all interfaces in the same VDOM are in the same L2 forwarding
domain. Therefore, using multiple interfaces in transparent mode needs special attention as the wrong
configuration can easily create a loop.

Transparent mode operation applies to overall FortiGate operation. Using VDOMs where transparent mode is
required is best practice. In transparent mode, all ports belong to the same forwarding domain by default.
You can assign ports to different forwarding domains within the same FortiGate/VDOM, or you may use
individual VDOMs to separate ports into different forwarding domains. If the connected ports are trunk

IPS Architecture Guide 6

HA

ports, you should isolate each VLAN interface pair in its own VDOM or forwarding domain. You must
configure a policy with an IPS profile for inspection to occur. You can use both source and destination MAC
address objects in IPS policies.

Considering virtual wire mode over transparent mode is best practice, since deployment is simpler and
virtual wire mode offers the same capabilities as transparent mode with the added benefit of operating in
NAT mode.

Public cloud
Networking is specific to each supported public cloud solution. The common denominator is the Layer 3
routing mode using routing tables and routes available in Transit Gateway, VPCs, and VNets alike.

In public cloud, there are other solutions that have FortiGate IPS engine inspect traffic. For AW S, you can use
architecture using AW S Gateway Load Balancer and FortiGate-VM, or FortiGate Cloud-Native Firewall (CNF).
For Azure, you can use integrations with Azure virtual W AN, which uses the routing intent concept, as well
as Azure Gateway Load Balancer in combination with FortiGate-VM or FortiGate CNF.

HA

You may use multiple FortiGates in an IPS solution to provide resiliency and redundancy. The ability to share
the inspection load, as well as take over completely in the event of failure, helps ensure your network has
uninterrupted security. You can implement high availability (HA) in a few ways. The following describe
Fortinet recommendations for FortiGate HA implementation. If traffic passes through a single site, but is on a
highly critical path, implementing the FortiGate Clustering Protocol is recommended.

FGCP
High availability (HA) is usually required in a system where there is high demand for little downtime. There
are usually hot-swaps, backup routes, or standby backup units and as soon as the active entity fails, backup
entities start functioning. This results in minimal interruption for users.

The FortiGate Clustering Protocol (FGCP) is a proprietary HA solution whereby FortiGates can find other
member FortiGates to negotiate and create a cluster with. A FortiGate HA cluster consists of at least two
FortiGates (members) configured for HA operation. All FortiGates in the cluster must be the same model and
have the same firmware installed. Cluster members must also have the same hardware configuration, such
as the same number of hard disks. All cluster members share the same configurations except for their
hostname and priority level in the HA settings.

IPS Architecture Guide 7

HA

A-P FGCP cluster

FortiGates work in a cluster setup in an active-passive (A-P) manner. There is one primary unit in the cluster
that is responsible for traffic forwarding. You can have one or more standby units, which have the exact
same configuration as the primary. The intention is to reduce the impact of device or corresponding
connectivity failure to mission-critical traffic. Failover conditions ae L2 connectivity failure, L3 connectivity
failure, or power failure on the primary unit. As soon as the conditions are met, traffic starts to flow from the
standby device. For IPS inspection, if you enable session synchronization, the existing sessions continue
flow from the secondary device.

SSL deep inspection sessions do not continue after failover as the cluster does not synchronize SSL deep
inspection sessions.

A-A FGCP cluster

FortiGates work in a cluster in an active-active (A-A) manner. An A-A high availability (HA) cluster consists
of a primary unit that receives all communication sessions and load balances them among the primary and all
subordinate units. In an A-A cluster, the subordinate units are also considered active since they also
process content processing sessions. In all other ways, A-A HA operates the same as active-passive HA. For
IPS operation, you must enable the load-balance-all parameter to balance traffic applied with the IPS
profile.

FGSP with IPS inspection

W ith the FortiGate Session Life Support Protocol (FGSP), each FortiGate receives traffic by means of an
external balancing method. It can be L2 with LACP or L3 with ECMP/VRRP. Sessions are synchronized
between members. W ith IPS policies, traffic is forwarded to the session owner by L2 or L3 for inspection.
The peer who receives the first packet of a session becomes the session owner. W hen the session owner
synchronizes the session with its peers, the session owner's member ID is added to the session information.
Other peers learn the session owner's member ID. If a peer receives any packet that is part of this session, it
forwards the packet to the correct member. This eliminates any asymmetry to the traffic and each session is
completey inspected by one FortiGate.

W hen there are multiple redundant sites, FGSP is preferred over FGCP. Traffic to each site may be routed by
a L3 router or load balancer to the active site. Sessions are synchronized over a dedicated link. If traffic
disruption is detected in one site, traffic can immediately switch to the backup site. If additional redundancy
is needed, you can deploy FGCP clusters on each site and operate them in a FGCP over FGSP manner. You
can apply IPS inline on the FortiGate protecting each site.

IPS Architecture Guide 8

HA

See High Availability.

IPS Architecture Guide 9

Design overview
Design concepts and considerations

After you understand the operational modes and high availability (HA) options, there are a few more
considerations that can apply to any of the aforementioned choices. You should consider and include these
in the initial design, as they must be present regardless of the operational mode and HA decisions. The
following topics assist in selecting the right model FortiGate to meet your current and forecasted needs and
limitations.

Interfaces
Choose the media to use to connect the appliance to your network: 100G, 40G, 10G interfaces, and so on.
You should consider both the immediate need and estimated growth, as well as redundancy. Redundant links
and link aggregation can help to provide resiliency against single points of failure and additional throughput
without incurring the expense of supporting high throughput interfaces and cabling. You must also consider
the appliance that the FortiGate will connect to. For example, you may consider how many available ports
and kinds of ports to use. This can help determine which FortiGate model best meets your needs.

Throughput
Throughput can refer to the amount of data the interface can send and receive. This guide uses throughput
to describe the maximum amount of traffic measured in (Giga/Mega)-bytes per second that the FortiGate’s
IPS engine needs to inspect. FortiGate datasheet values help to choose the correct solution to fit your
estimated needs. In addition to the data quantity that must be processed, the inspection level plays a
significant role in the FortiGate’s IPS throughput.

Inspection
Encrypted traffic can be a Trojan horse for malware or exploits. For this reason, an IPS solution is most
effective when it can “see inside” the encrypted traffic. This is known as deep inspection and requires
careful planning to be implemented. Deep inspection consumes more resources and plays a factor in sizing
your deployment. It also requires an advanced understanding of Public Key Infrastructure (PKI) for
implementation. See Deep inspection.

IPS Architecture Guide

DESIGN CONCEPTS AND CONSIDERATIONS

Solution's access to the Internet

As cyberattacks constantly evolve, for the FortiGate to keep up with these new attack methods, the
FortiGate too must constantly evolve. This is accomplished through updates to the IPS database. These
updates come from the FortiGuard threat labs, the threat intelligence and research organization at Fortinet
which counters threats in real-time both as they are reported and through extensive testing of both Fortinet
and third-party products.

If your design has no Internet access, such as in an air-gapped environment, you should consider
FortiManager to provide IPS database updates. FortiManager may function as a proxy to the FortiGuard
network, downloading and maintaining a copy of the threat database such that the FortiGate may update its
database from the FortiManager.

IPS Architecture Guide

Design examples
The following considers some example architecture designs:

Data center

Intrusion prevention is a key component in many enterprise security strategies, especially in the data center
where it plays a particularly critical role. After all, that is where a company's most important assets reside.

IPS deployed in the data center usually handles significantly higher traffic levels than an IPS deployed at the
corporate network edge. Data center IPS must provide a high performance level while maintaining low
latency so as not to interfere with application performance.

Scalability and redundancy (both inter-datacenter and intra-datacenter networks) can be a challenging
factor. Fortinet product portfolio offers wide range of products with scalable and redundant solutions.

FortiGate integration with third-party solutions like Cisco ACI or VMware NSX-T give flexibility for adding IPS
functionality to existing deployments.

Configuration and automation flexibility of the FortiGate IPS solution is key to easily integrate with working
automation orchestration solutions.

The following provides common areas within a data center where you can apply IPS:

Perimeter
Deploying IPS at the perimeter of the data center, such as at the edge routers or firewalls, can help to detect
and block malicious traffic before it enters the data center.

DMZ
Deploying IPS within a demilitarized zone can help to protect externally-facing servers, such as web or email
servers, from attacks such as SQL injection, cross-site scripting, and other web-based attacks.

IPS Architecture Guide

ENTERPRISE EDGE

Internal network
Deploying IPS within the internal network can help to detect and block lateral movement by attackers,
preventing them from moving laterally within the network and accessing critical assets.

Enterprise edge

A network perimeter is the secured boundary between the private and locally managed side of a network,
often a company’s intranet, and the public facing side of a network, often the Internet. IPS is typically
deployed at this edge to protect the internal network from external threats such as malware, hacking
attempts, and other malicious activities. In addition, perimeter IPS protects outbound traffic, such as critical
assets reaching public networks. The IPS is typically placed in-line with the traffic flow at the edge of the
network, between the perimeter firewall and the internal network.

IPS is commonly applied in the following locations within the enterprise edge:

Internet to server
In effective perimeter networks, incoming packets flow through security appliances that are hosted in
secure subnets, before the packets can reach back-end servers. Security appliances include firewalls,
network virtual appliances (NVAs), and other intrusion detection and prevention systems. Internet-bound
packets from workloads must also flow through security appliances in the perimeter network before they
can arrive the secure network.

Usually, central IT teams and security teams are responsible for defining operational requirements for
perimeter networks. Perimeter networks can provide policy enforcement, inspection, and auditing.

W hen creating IPS rules to protect the backend servers, deep packet inspection is also required. For details
how to select deep packet inspection profiles, see the deployment documentation.

Client Internet access

Vulnerabilities on client applications, like web browsers, are an increasing attack vector. Client to Internet
IPS protection is becoming more important. Enabling client-targeted IPS signatures on general Internet
policies is common practice as minimum IPS protection.

IPS Architecture Guide

PUBLIC CLOUD

Remote access
IPS is applied to remote access connections such as VPNs to ensure that only authorized users are allowed
to access the network. This includes analyzing remote access traffic for suspicious activity, such as brute
force attacks or unauthorized access attempts.

Cloud service access

You can apply IPS to cloud services to protect against threats originating from cloud-based applications and
services. This includes analyzing traffic to and from cloud services, such as cloud-based email or storage
services, to detect and prevent malicious activity.

Partner connections
You can apply IPS to partner connections, such as connections to other corporate networks or third-party
vendors, to ensure that these connections do not pose a threat to the internal network. This includes
analyzing partner traffic for suspicious activity and blocking any malicious activity before it can reach the
internal network.

Public cloud

Deploying an Intrusion Prevention System (IPS) on a public cloud infrastructure can help to protect against
various types of cyber threats, including network-based attacks, targeted attacks, and data breaches. Here
are some common areas within a public cloud environment where you can apply IPS.

VPC or VNet
These overlay Layer 3 networks offer their own dedicated routing. Deploying IPS within a VPC/VNet can help
to protect the virtual network from malicious traffic and cyber threats. You can deploy IPS at the edge of the
VPC to provide perimeter security or within the VPC to provide internal network security. Deployment can be
as small as a single VPC/VNet or expand into hub-spoke network setups using AW S Transit Gateway, Azure
VNeet peering, Google Cloud VPC peering, or Oracle Cloud Dynamic Routing Gateway v2. Different
architectures have different capabilities to inspect North-South and East-W est traffic. You must validate the
capabilities during the design phase.

FortiGate-VM or FortiGate CNF placed within a VPC/VNet

FortiGate IPS is contained or accessible in the VPC/VNet traffic between subnets. Ingress or egress traffic is
routed via the interfaces of the FortiGate-VM or endpoints of the FortiGate CNF.

IPS Architecture Guide

PUBLIC CLOUD

This diagram shows one VNet containing the FortiGate, which has an external network for W AN connectivity,
an internal network, and multiple protected subnets. W hen using user-defined routing, you can forward
different traffic types to the FortiGate-VM for IPS inspection.

FortiGate CNF uses a Gateway Load Balancer endpoint to receive or send traffic to your regional FortiGate
CNF instance. This configuration leverages routing to send traffic between subnets as well as ingress and
egress traffic to the endpoint.

FortiGate-VM or FortiGate CNF placed within a dedicated VPC/VNet

This implementation establishes a security VPC or hub VNet that enables FortiGates to scan traffic to and
from each VPC/VNet.

IPS Architecture Guide

PUBLIC CLOUD

This diagram shows one VNet containing the FortiGate, which has an external network for W AN connectivity
and peering between VNets. Spokes connecting to the hub VNet must pass through the FortiGate-VM or
FortiGate CNF before reaching any other spoke network. Traffic which does not go through the main VNet is
not subject to IPS security.

This diagram demonstrates different VPCs that are all interconnected through the Transit Gateway. Security
is provided in a specific Security VPC so that North-South and East-W est traffic can be scanned. Inbound
traffic arriving on the Transit Gateway destined for the individual VPCs are first routed to the Security VPC
and inspected by the FortiGate before being routed to the destination. Similarly, inter-VPC traffic is routed
through the Security VPC for inspection.

Cloud management security

Many cloud providers offer a managed construct which supports sending traffic “through” a security
product, such as a FortiGate or FortiW eb. This allows the cloud provider to configure and maintain routing,

IPS Architecture Guide

PUBLIC CLOUD

peering, and so on while incorporating security vendors inline.

AWS

In AW S, there is an architecture available using AW S Gateway Load Balancer and FortiGate-VM or FortiGate
CNF. These solutions provide excellent scalability and focus on traffic inspection.

Azure

The Azure virtual W AN (vW AN) solution enables third-party vendors to provide security by deploying their
network virtual appliances (NVAs) within the Azure vW AN hub. You can integrate FortiGate-VMs in this way
to a next-generation firewall solution with routing intent or an SD-W AN solution with routing intent. These
leverage Microsoft Azure components to ease the routing and management of the traffic flows between
VNets (East-W est traffic) as well as to the Internet (North-South traffic). You can apply IPS on the FortiGate
NVAs to inspect traffic.

IPS Architecture Guide

PUBLIC CLOUD

FortiGuard intelligence in cloud-provided firewalls

Fortinet also offers managed IPS rules for the AW S Network Firewall. This is an AW S-operated firewall that
offers third-party signatures for inspection. FortiGuard Labs offers the latest threat information packaged
ready to go into the AW S Network Firewall. See Fortinet Managed IPS Rules for AW S Network Firewall.

IPS Architecture Guide

More information
Appendix A: Documentation references

Feature documentation
l FortiOS Administration Guide:
l Intrusion prevention
l High Availability

Solution hub
l NGFW 4-D Resources

Other
l FortiGate Public Cloud:
l HA for FortiGate-VM on AW S
l Azure:
l HA for FortiGate-VM on Azure
l Azure vW AN NGFW Deployment Guide
l Azure vW AN SD-W AN NGFW Deployment Guide
l FortiGate CNF Administration Guide:
l Security profiles
l Deployment scenarios

IPS Architecture Guide

 www.fortinet.com

Copyright© 2024 Fortinet, Inc. All rights reserved. Fortinet®, FortiGate®, FortiCare® and FortiGuard®, and certain other marks are registered trademarks of Fortinet, Inc., and other Fortinet names herein may also be registered and/or common
law trademarks of Fortinet. All other product or company names may be trademarks of their respective owners. Performance and other metrics contained herein were attained in internal lab tests under ideal conditions, and actual performance
and other results may vary. Network variables, different network environments and other conditions may affect performance results. Nothing herein represents any binding commitment by Fortinet, and Fortinet disclaims all warranties, whether
express or implied, except to the extent Fortinet enters a binding written contract, signed by Fortinet’s Chief Legal Officer, with a purchaser that expressly warrants that the identified product will perform according to certain expressly-
identified performance metrics and, in such event, only the specific performance metrics expressly identified in such binding written contract shall be binding on Fortinet. For absolute clarity, any such warranty will be limited to performance in
the same ideal conditions as in Fortinet’s internal lab tests. Fortinet disclaims in full any covenants, representations, and guarantees pursuant hereto, whether express or implied. Fortinet reserves the right to change, modify, transfer, or
otherwise revise this publication without notice, and the most current version of the publication shall be applicable.

01-74-908318-20240215