Fortigate Transparent Mode Technical Guide FortiOS 4.0
Fortigate Transparent Mode Technical Guide FortiOS 4.0
Fortigate Transparent Mode Technical Guide FortiOS 4.0
Technical Guide
–
FortiOS v4.0
2.1 FortiGate features and capabilities matrix - NAT and Transparent mode ................................ 10
3.4 Network operation : source MAC addresses in frames sent by or through the Fortigate........... 15
8.3 IPSec configuration example 2 : remote sites in the same subnet and one remote subnet ........ 43
Additional Fortinet technical information is available from the Fortinet Knowledge Base http://kb.fortinet.com or Product
documentation site http://docs.forticare.com.
Trademarks
Dynamic Threat Prevention System (DTPS), APSecure, FortiASIC, FortiBIOS, FortiBridge, FortiClient, FortiGate®, FortiGate Unified
Threat Management System, FortiGuard®, FortiGuard-Antispam, FortiGuard-Antivirus, FortiGuard-Intrusion, FortiGuard-Web,
FortiLog, FortiAnalyzer, FortiManager, Fortinet®, FortiOS, FortiPartner, FortiProtect, FortiReporter, FortiResponse, FortiShield,
FortiVoIP, and FortiWiFi are trademarks of Fortinet, Inc. in the United States and/or other countries. The names of actual
companies and products mentioned herein may be the trademarks of their respective owners.
NAT and Transparent (also called TP) mode are the two modes in which a Fortigate or a VDOM can
operate.
NAT or Transparent mode will only depict the way that the Fortigate is making IP packets routing or
Ethernet frames forwarding decision, while the UTM features will be available in both modes.
Any VDOM configured in a Fortigate can be set in any of those two modes.
For additional information about VDOM, please consult the Fortigate Administration Guide or VDOM and
VLAN Guide at http://docs.forticare.com or the Knowledge Base at http://kb.fortinet.com
In NAT mode, the FortiGate is processing IPv4 or IPv6 packets at the L3 OSI model, and from the network
side, is acting as a router (or default-gateway) between the networks attached. Figure 1 shows an
example of deployment in NAT mode.
The FortiGate in NAT mode supports the following routing protocols or routing capabilities: Static Routing,
RIPv1/v2, OSPF, BGP, Multicast, or Policy Based Routing.
In Transparent mode, the FortiGate is processing packets at the L2 OSI network model, and from the
network side is acting as L2 switch between different network elements (between a router and a mail
server for example.)
A Fortigate in Transparent mode is deployed when, for example, the IP addressing cannot change on the
existing network, or the routers in place must not be changed.
Placing a Fortigate in Transparent in a network does not require any changes on the existing devices as
they do not know the presence of the Fortigate which is acting “transparently” on a L2 network level.
Router1 Router1
` `
port1 port1
FortiGate FortiGate
port2 port2
` `
Router2
Next-Hop =
Router1
` Servers
Default Gateway
= Router1
Servers
Default Gateway
= Router2
Maximum number of Interfaces (VLAN+ physical) per VDOM: 255 (all FortiGate models)
For any other scaling information please consult the FortiGate maximum values matrix available at
http://docs.forticare.com
config vdom
edit <vdom_name>
config system settings
set opmode transparent
end
When operating in Transparent mode, the Fortigate behaves like a L2 switch in accordance with 802.1d
principles:
The FDB (forwarding Data Base) is populated with the network devices MAC addresses during a
MAC learning process, based on the source MAC addresses seen in the Ethernet frames ingressing
a FortiGate port. Static MAC entries can also be configured. See example in section Adding a static
MAC entry
As Spanning Tree in not running on the Fortigate, a port that comes up goes immediately into
forwarding or flooding state. This last state will not occur once unicast MAC addresses are present
in the FDB
Important note : If the FortiGate in Transparent mode bridges traffic to a router or host using a virtual
MAC for one direction and a different physical MAC for the other direction (for example when VRRP or
HSRP protocols are used), it is highly recommended to create a static MAC entry for the virtual MAC. This
is to make sure that the virtual MAC address is present in the FDB.
In Transparent like in NAT mode, no IPv4 packets are forwarded by the Fortigate from a port to another
port unless a firewall policy is matched with action ACCEPT or IPSEC. Here below are some exceptions.
Note that only IP Ethernet frames are considered by the Fortigate. For other frame types, please see
section Non IP frames forwarding
o ARP : by default, ARP broadcasts and ARP reply packets are flooded/forwarded on all ports
or VLANs belonging to the same forwarding domain, without the need of firewall policies
between the ports. This default behavior is necessary to allow the population of the FDB and
allow further firewall policy lookup (see section Transparent mode Firewall processing for
more details) . This option is configurable at the interface settings level with the parameter
arpforward (enabled by default).
L2 (IP) Multicast frames forwarding: the FortiGate does not forward frames with multicast
destination MAC addresses by default. Multicast traffic such as one used by routing protocols or
streaming media may need to traverse the FortiGate which should not interfere this
communication.
Fortinet recommends that the FortiGate is set up using Multicast policies. This allows for greater
control and predictability on traffic behavior. However Multicast traffic may be forwarded through a
Transparent mode device using the multicast-skip-policy setting. This is detailed in the section
Multicast processing and forwarding
L2 (IP) Unicast frames forwarding: a frame with a unicast destination MAC address is subject
to firewall processing before being forwarded. (see section Transparent mode Firewall processing
for more details). This does not apply to ARP replies (see above).
Ethernet frames that are traversing and processed by the Fortigate and not altered from their
original source and destination MAC addresses. End devices do not “see” the MAC address of the
Fortigate. If NAT is enabled on a firewall policy, the source MAC address will be the Fortigate
management MAC address.
IP packets initiated by the Fortigate (remote management, access to FortiGuard server…) are sent
in L2 Ethernet frames that have a source MAC address of the interface in the VDOM with the lowest
MAC address.
See below an example with port2 and port3 in the same VDOM, remote access done via port2, but
the sniffer trace showing MAC address of port2.
A forwarding domain is used to create separated broadcast domains between VLANs and allow
independent VLAN learning – IVL (MAC addresses in the FDB). This would be equivalent to creating
VLANs on a regular L2 switch.
o Note: when VLANs are used in the network, configuring different forwarding domains is
essential to avoid broadcast duplications. See also section Default VLAN forwarding behavior
for additional information.
The packets processed by the direct interface (or port) itself are always sent untagged and must be
received untagged.
A forwarding domain is used to create separate broadcast domains and confine traffic across two or more
ports. It also allows learning the same MAC in different VLANs (IVL). See section VLAN trunking and MAC
address learning for more details.
A forwarding domain and its associated ID number are unique across one VDOM, or a Fortigate with VDOM
disabled.
Notes:
o Even though the forwarding domain ID is not in relation with the actual VLAN numbers, It
recommended, for maintenance and troubleshooting purpose to configure of forwarding domain
per VLAN and use the same forwarding domain ID as the VLANs ID.
o Once forwarding domains are configured, it is possible to configure Firewall Policy(ies) only
between ports or VLAN belonging to the same forwarding domain
Each new VDOM will create a new bridge instance in the Fortigate.
The figure 4 shows an example with 3 forwarding domains and VLANs configured (forwarding domain 0 is
the default on a Fortigate or VDOM in TP mode).
In this example there are two VDOMs in TP mode: root and MGMT.
Packets untagged ingressing port1, port3 and port4 belong to the same broadcast domain in
the root VDOM
Packets tagged with VLAN 340 ingressing port1 and Packets untagged ingressing port2 belong
to the same broadcast domain in the root VDOM
Packets tagged with VLAN 341 ingressing port1 and Packets untagged ingressing port5 belong
to the same broadcast domain in the root VDOM
Packets untagged ingressing port6 belong to a different broadcast domain in the MGMT VDOM
A VLAN configured on a physical port is used to classify a packet in a broadcast domain in ingress, and to
tag packet in egress.
When a Fortigate receives a tagged frame with an unknown VLAN ID, the processing is the following:
By default, the ports are set with the parameter vlanforward = enable ; in this scenario, all tagged
frames are forwarded to the ports belonging to the same forwarding domain. This allows inserting
the Fortigate between two devices using trunk ports without any further configuration.
When using forwarding domains in association with VLANs, the parameter vlanforward should be
set to disable whenever applicable. In this scenario any new tagged frames with unknown VLAN
IDs are dropped by the FortiGate. This is the solution recommended by Fortinet.
VLAN configuration example: see section Configuration example: Forwarding domain, VLAN and trunk
A Fortigate port becomes a trunk when 2 or more VLANs are configured on this port, in the same or
different forwarding domains.
o Important note: when trunks are configured on a Fortigate, it is essential, to avoid packets
looping back on the VLANs of the trunk, to create forward-domain. This will confine all
broadcasts and multicast traffic between the interfaces belonging to a same forward-domain.
In the case where a trunk port is configured with VLAN in different forwarding domains, the MAC address
of the network device connected to this port is learned in the FDB of each forwarding domain. This is
Independent VLAN Learning (IVL).
A same forwarding domain can include several different VLANs. Therefore, a frame ingressing an interface
with a certain VLAN ID can be forwarded to another port with another VLAN ID. This is sometimes referred
as VLAN translation.
Viewing the FDB is done from the global mode. Type “config global” from the main prompt before
executing the commands below.
Example:
Here above we can see two bridge instances for 2 VDOMs in Transparent mode : root and mgmt
For IP traffic received or originated by the Fortigate itself, and in destination of the
management device or next-hop.
When IPSec is used, the Fortigate uses its ARP table to forward the traffic from the IPSec tunnel
to the local destination host(s).
All other forwarding decision is based on the FDB table or optional settings.
A Fortigate or a VDOM in Transparent can be assigned with a single IP address for remote access
management, and multiple static routes can be configured. This can be used if in-band management
wants to be applied.
When out-of-band management is desired (dedicated interface for remote management access), it is
recommended to use a separate VDOM in NAT mode.
The management IP address of a VDOM in Transparent mode is bound to ALL ports or VLANs belonging to
the same VDOM.
The remote access services such as Telnet, HTTPS, SNMP, etc… are subject to the same rules as in NAT
mode, and must be enabled/disabled on each port.
config vdom
edit <vdom_name>
When VDOM is enabled and the VDOMs are operating in Transparent mode, it is recommended, to avoid
L2 loops and allow more routing flexibility, to keep one VDOM (generally the root VDOM) in NAT mode,
with one or more VLAN or physical interface as out-of-band management.
Important note: the management VDOM must have IP connectivity to the Internet to allow
communication with the FDS and retrieve services information (AV,IPS, Fortiguard filtering, Support…). All
syslog and FortiManager communication also go through the management VDOM.
Figure 7, 8 and 9 show an example where the root VDOM is used as out-of-band management VDOM in
NAT mode, with 2 physical ports in two different subnets.
Figure 8: FortiGate Web based manager – Network window with VDOMs assignment
FortiManager, logging and reporting and FortiAnalyzer are supported similarly to NAT mode. For more
information about this please consult the Fortinet documentation at http://docs.fortinet.com or the
Knowledge base at http://kb.fortinet.com
Establishing a secured IPSec communication to a FortiAnalyzer is done as per the example hereafter (from
global level if VDOM is enabled). This setting is independent from being in Transparent mode.
However, as stated earlier in this section the management VDOM must have IP connectivity to the
FortiAnalyzer.
Note: for complete information about HA, please refer to the Fortigate Administration Guide or the HA
Technical guides available at http://docs.fortinet.com or the Knowledge Base at http://kb.fortinet.com
Any other statement and feature description in this document apply to a Fortigate Cluster running in
Active-Passive mode.
If a cluster is operating in Transparent mode, the FortiGate Clustering Protocol (FGCP) assigns a virtual
MAC address for the Master unit management IP address. Since you can connect to the management IP
address from any interface, all of the FortiGate interfaces appear to have the same virtual MAC address.
Failover protection between two instances of a VDOM operating on two different FortiGate in
the cluster.
Load balancing between the FortiGate units on a per-VDOM basis
interfaces
Heartbeat
In case of a failure or reboot of a FortiGate, the remaining unit will become Master for Vdom1 and Vdom2.
Note 1: the VDOMs given in this example are showing physical ports but a VDOM can also include VLAN
interfaces.
Note 2: the L2 connectivity between the FortiGate is showing 4 separate L2 switches, but it could also be
one single switch one each side configured with appropriate VLANs
FortiGate 1:
config system ha
set mode a-p
set hbdev "port5" 0 "port6" 0
set vcluster2 enable
set override disable
set priority 200
config secondary-vcluster
set override enable
set priority 100
set vdom "Vdom2"
end
end
FortiGate 2:
config system ha
set mode a-p
set hbdev "port5" 0 "port6" 0
set vcluster2 enable
set override disable
set priority 100
config secondary-vcluster
set override enable
set priority 200
set vdom "Vdom2"
end
end
In Transparent mode like in NAT mode, a firewall policy lookup is based on the couple < source interface
+ destination interface >.
The matching Firewall Policy will tell what processing and action to apply to the frames: Accept, Deny,
IPSec, Protection Profile (content inspection), etc…
The Fortigate proceeds as follows to look for a matching Firewall Policy in Transparent mode:
o Step1: an Ethernet IP frame ingresses a port (or a VLAN on a port), corresponding to a specific
bridge instance (from the port VDOM and Forwarding domain). This frame contains a
destination MAC address that we will call MAC_D.
o Step2: The Fortigate is making a MAC_D address lookup in the bridge instance to determine the
port where MAC_D has been learned. This will be the destination interface.
o Step3 : The Fortigate is then looking for a Firewall Policy corresponding to the couple < source
interface + destination interface >. If multiple policies with the same couple < source interface
+ destination interface > exist, the Fortigate screens all of them from TOP to BOTTOM (as
displayed in the configuration), until a match is found. Firewall Policy match lookup is based on
“stop-on-match”, therefore the Firewall Policy ordering is important: from most specific in the
first position to least specific in last position.
The flag br in the state line will indicate that this is a “bridged” session.
The rules and concept for AV, IPS, and any other content inspection and protection profile settings are the
same in NAT mode and Transparent mode.
When a protection profile is enabled on a firewall policy for content inspection, the FortiGate acts like a
transparent proxy (*) for the protocols that need to be inspected (HTTP, SMTP…).
The FortiGate will therefore intercept the TCP sessions and create its own session from client to server and
server to client. The source and destination MAC addresses of the original L2 frames are however not
altered in this communication, as described in the section Network operation : source MAC addresses in
frames sent by or through the Fortigate
(*) Devices in the network communicating through the FortiGate do not know the presence of the
Fortigate.
Refer to the Fortigate Administration Guide for more information about UTM features and settings, at
http://docs.forticare.com or the Knowledge Base at http://kb.fortinet.com
IPSec can be used to tunnel network-layer (layer 3) traffic between two VPN peers or between a VPN
server and its client. When an IPSec VPN tunnel is established between a FortiGate unit and a remote VPN
peer or client, packets are transmitted using Encapsulated Security Payload (ESP) in tunnel mode (AH is
not supported).
In Transparent mode, IPSec VPN is supported in Policy based configuration mode only.
Encrypt data over routed networks without changing anything on the routers. See example 1 later.
Encrypt data over a non-routed transport network (extension of a LAN for example). See example
2 later.
If both remote FortiGate IPSec gateways are not in the same broadcast domain (separated by
routers) :
o The hosts on each side must be on different subnets.
o The FortiGate management IP addresses must be in the same subnet as the local hosts
If both remote FortiGate IPSec gateways are in the same broadcast domain (separated by optical
switches for examples), the hosts on each side can be :
o On the same subnet
o On different subnet if the appropriate static route is configured on the remote Fortigate
o The FortiGate management IP addresses can be in any different subnet than the local hosts
A firewall Policy with the action IPSec is used to send traffic to the remote device into the tunnel.
Therefore, it is important to place all remote devices on the appropriate ports of the Fortigate to
allow a proper match < source interface + destination interface > . See section Transparent mode
Firewall processing for more details.
This example provides a configuration example for IPSec VPN tunnels between three FortiGate in
Transparent Mode (TP) in different subnets, as well as some troubleshooting steps.
The expectation for this example is that PC1 will be able to communicate via the IPSec tunnels with PC2
and PC3, which are in different subnets.
Because both FortiGate are not in the same broadcast domain (separated by routers), the hosts on
each side must be on different subnets.
FortiGate management IP addresses must be in the same subnet as the local hosts
The default gateways (router1 ,router2, router3) for PC1 , PC2 and PC3 must be behind port2 in
order for the FortiGate to match the appropriate Encrypt firewall policy (port1 --> port2)
C - Using the debug flow command on the initiator side (example on FortiGate1)
Note : the message "id=36870 trace_id=615 msg="SA is not ready yet, drop" simply means that the
tunnel was not up yet.
D - Using the debug flow command on the receiver side (example on FortiGate2)
Note : the above ARP process in Transparent mode with IPSec is allowing to Fortigate to :
- Identify the MAC address of the destination device 10.2.2.10
- Populate the MAC table (see below), which in turn will give a destination interface and allow a Firewall
policy look-up
This example provides a configuration example for IPSec VPN tunnels between two FortiGate in
Transparent Mode (TP) in the same subnet separated by a L2 transparent network, and one remote
subnet on the second site.
IPSEC VPN
POLICY BASED
Server1
10.1.1.20
10.3.3.254/24
IPSEC VPN
POLICY BASED
Server2
10.3.3.30
The expectation for this example is that PC1 will be able to communicate via the IPSec tunnel with
Server1 in the same subnet, and Server2 in a different subnet.
The default gateway (FGT3) for PC1 and all remote device must be behind port2 of FGT1, in order
for this FortiGate to match the appropriate Encrypt firewall policy (port1 --> port2)
Despite being in Transparent mode, FGT2 must have a valid route to Server2
FGT3 is used as a router between subnet 10.1.1.0/24 and 10.3.3.0/24
Note : Firewall Policy 3 is not mandatory and is only used to allow PC1 to test a ping reachability to its
default gateway 10.1.1.254
C:\ arp –a
Note 1: MAC address 00:09:0f:23:01:d6 is “internal” port MAC address of FGT2 00:09:0F:23:01:D6.
This is the MAC address used for management in the Transparent mode VDOM of FGT2, chosen between
the lowest MAC address between wan1 (00:09:0F:78:00:74) and internal (00:09:0F:23:01:D6)
Note : it is important to have the entry for 10.1.1.254 which is the route to 10.3.3.0/24
8.3.3.5 Sniffer trace on FGT1 when PC1 pings all 3 remote destinations
interfaces=[any]
filters=[icmp]
0.342268 port1 in 10.1.1.10 -> 10.3.3.30: icmp: echo request
0.342844 port2 in 10.3.3.30 -> 10.1.1.10: icmp: echo reply
0.342884 port1 out 10.3.3.30 -> 10.1.1.10: icmp: echo reply
0.771700 port1 in 10.1.1.10 -> 10.1.1.20: icmp: echo request
0.772504 port2 in 10.1.1.20 -> 10.1.1.10: icmp: echo reply
0.772539 port1 out 10.1.1.20 -> 10.1.1.10: icmp: echo reply
0.907377 port1 in 10.1.1.10 -> 10.1.1.254: icmp: echo request
0.907850 port2 in 10.1.1.254 -> 10.1.1.10: icmp: echo reply
0.907883 port1 out 10.1.1.254 -> 10.1.1.10: icmp: echo reply
interfaces=[port2]
filters=[proto 50]
pcap_lookupnet: port2: no IPv4 address assigned
Note : From the trace above, dst-mac-00:09:0f:23:01:d6 is “internal” port MAC address of FGT2
00:09:0F:23:01:D6. This is the MAC address used for management in the Transparent mode VDOM of
FGT2, chosen between the lowest MAC address between wan1 (00:09:0F:78:00:74) and internal
(00:09:0F:23:01:D6)
The FortiGate will in this condition detect a replay packet and drop it.
If the network topology or culprit devices cannot be changed to avoid this, the workaround on the
Fortigate can be to disable TCP replay verification packets.
(*) For additional diagnosis and troubleshooting procedures, please consult the Knowledge Base at
http://kb.fortinet.com
Example on how to add a static MAC entry (this is a per VDOM command):
Multicast MAC addresses are destined for an identified group of devices in the broadcast domain.
Broadcasting video might actually use multicast MAC address to address only the devices that need a
specific stream. Routing protocols such as RIP or OSPF also use multicast frames.
A Multicast MAC address is identified by the low order bit (0x01) in the first octet which indicates that this
packet is a Layer 2 multicast packet. There are several well-known and standard formats of a multicast
frames. The 01:00:5E prefix has been reserved by the IANA for use in mapping L3 IP Multicast addresses
into L2 MAC addresses (*).
When mapping L3 to L2 addresses, the low order 23 bits of the L3 IP multicast address is mapped into the
low order 23 bits of the MAC address.
Example:
IP 224.0.0.2 maps to MAC 01-00-5E-00-00-02
IP 224.10.8.5 maps to MAC 01-00-5E-0A-08-05
Spanning Tree protocol uses the multicast MAC 01-80-c2-00-00-00 for its standard BPDU.
VRRP and HSRP protocols use a multicast MAC that start with 01-00-5e-xx-xx-xx
RIP2 : 01-00-5E-00-00-09
Multicast IP addresses use the Class D address space. The 224.0.0.0 to 239.255.255.255 IP address
range is reserved for multicast groups. The multicast address range applies to multicast groups, not to the
originators of multicast packets.
In Transparent mode, a FortiGate does not forward, by default, frames with multicast destination MAC
addresses. Multicast traffic such as one used by routing protocols or streaming media may need to traverse the
FortiGate which should not interfere in this communication.
Fortinet recommends that the FortiGate is set up using Multicast policies. This allows a finer control.
Multicast traffic may have to be forwarded through a Transparent mode device using the multicast-skip-policy setting.
This is the configuration for this solution:
config vdom
edit <vdom_name>
The use of firewall multicast-policy allows a finer control over the multicast packets. Hereafter are some
commented examples. Note that the parameter multicast-skip-policy mentioned above must be left to
disabled.
1- Simple policy
3- To be more restrictive (example to allow RIP2 packets from port1 to port2 and sourced by
10.10.0.10) :
The following example shows how to configure a VIP and a sniffer trace with the result:
Note : if the mappedip is on a different subnet than the management IP, the Fortigate must have a valid
route to this destination
interfaces=[any]
filters=[icmp]
4.126138 vlan160_p2 in 192.168.182.93 -> 192.168.183.48: icmp: echo request
4.126190 vlan18_p3 out 192.168.182.93 -> 192.168.182.78: icmp: echo request
4.126196 port3 out 192.168.182.93 -> 192.168.182.78: icmp: echo request
4.126628 vlan18_p3 in 192.168.182.78 -> 192.168.182.93: icmp: echo reply
4.126661 vlan160_p2 out 192.168.183.48 -> 192.168.182.93: icmp: echo reply
4.126667 port2 out 192.168.183.48 -> 192.168.182.93: icmp: echo reply
Source NAT is an option available in Transparent mode and configurable in CLI only. The following
example shows how to configure it and a sniffer trace with the result:
interfaces=[any]
filters=[host 10.2.2.1]
4.891970 vlan160_p2 in 192.168.182.93 -> 10.2.2.1: icmp: echo request
4.892003 vlan18_p3 out 192.168.183.48 -> 10.2.2.1: icmp: echo request
4.892007 port3 out 192.168.183.48 -> 10.2.2.1: icmp: echo request
4.933216 vlan18_p3 in 10.2.2.1 -> 192.168.183.48: icmp: echo reply
4.933249 vlan160_p2 out 10.2.2.1 -> 192.168.182.93: icmp: echo reply
4.933253 port2 out 10.2.2.1 -> 192.168.182.93: icmp: echo reply
In the situation where non IP frames (or non Ethernet II) frames need to be accepted on a port, the
parameter l2forward can be enabled (disabled by default).
This can be used to forward frames such as PPPoE PADI, Appletalk, on other ports belonging to the same
forwarding domain.
In order to pass CDP(*) or VTP(*) packets through a FortiGate in Transparent mode, the parameter
stpforward must be applied on the port configuration.
VTP and CDP packets are sent to the destination MAC address 01-00-0C-CC-CC-CC
(*) VTP : Cisco VLAN Trunk Protocol - CDP : Cisco Discovery Protocol
The example below will allow CDP and VTP packets to be sent from port3 up to the Remote unit, through
two VDOMs, via one physical port and three port aggregations.
Notes:
When using aggregation, the stpforward setting needs to be applied only on the port aggregation
level, not on the physical port
This will also forward regular Spanning Tree BPDUs
See above the CDP packet flow from port3, LACP_VD1 (port2), LACP_VD2_IN, LACP_VD2_OUT (port19)
Note: the following sniffer trace command will filter only CDP or VTP packets :
Note: Cisco NATIVE VLAN is carrying CDP/VTP frames. The frames of this VLAN must be received on the
Fortigate physical interfaces (not VLAN sub-interface). Physical interfaces are the only ones that can
send/accept non-tagged packets.
By default, the parameter vlanforward is enabled on each physical interface of a Fortigate or VDOM in
Transparent mode.
This allows to forward all VLANs traffic of a trunk that was connecting two network devices and where the
Fortigate has been introduced, without having to perform any further configuration.
It is recommended to configure forwarding domains for each VLAN and disable this parameter
in order to avoid packet from looping into the trunk from one VLAN to another.
Configuration example:
Spanning tree (spt, rstp, pvst, pvst+) BPDUs are not forwarded by default in Transparent Mode.
Introducing a FortiGate in the network must be done with case as L2 loops might be introduced or
Spanning Tree broken.
To forward spanning tree BPDUs, the following setting can be applied on each interface where this is
required:
1) Create forwarding domains when VLANs are used and set vlanforward to disable on all relevant
physical interface.
2) The forward-domain ID can be different to the VLAN ID, but it is recommended for troubleshooting
and readability to keep them the same.
3) Only interfaces from the same forwarding domains can have Firewall Policies between each others.
4) In order to allow IVL (independent VLAN learning), the VLANs must be placed in separate
forwarding domains
6) As Spanning Tree BPDUs are not forwarded by default, insert the Fortigate with caution to avoid L2
loops
7) Multicast packets are not forwarded by default; this might cause routing protocols (RIP2,OSPF)
disruption.
8) When using HSRP or VRRP configure static MAC entries for the Virtual MAC addresses.