| Description |
This article describes how to deploy a FortiGate-VM, in transparent mode without VDOM licensing in VMWare vSphere environment, as an Internal Segmentation Firewall and explores some caveats. |
| Scope |
FortiGate VM 7.2.4 and VMWare vSphere 8. |
| Solution |
Disclaimer
Read the entire document before implementation. A FortiGate VM in transparent mode, if implemented without caution, can cause loops to occur on the network.
Design
Tier2 Design vs Tier3 Design
An ISFW (Integrated Security Firewall) plays a critical role in microsegmentation by enforcing security policies between different network segments, or 'microsegments'.
The ISFW serves as the gatekeeper between these microsegments, controlling the flow of traffic between them and enforcing security policies to ensure that only authorized traffic is allowed through. By using an ISFW to enforce security policies, an organization can ensure that each microsegment is isolated and protected from potential threats originating from other microsegments. In addition to enforcing security policies, an ISFW may also provide features such as IPS, deep packet inspection, and advanced threat protection.
Contrarily, on the Tier2 design all traffic between VMs in the same broadcast domain will flow freely. Traffic between VMs in different broadcast domains will be routed by DCFW. To filter or inspect traffic between VMs, it is necessary to segregate the VMs into different broadcast domains. This will be done by the DCFW (usually hardware versions, which are not upgradable).
Lab 
Use Cases
1) All traffic between WindowsVM and LinuxVM must be allowed but RDP and SSH must be blocked. It is ideal to be able to inspect all traffic (with Antivirus, IPS and Deep SSL Inspection). 2) All traffic between KaliVM and WindowVM must be allowed but inspected (with Antivirus, IPS and Deep SSL/SSH Inspection). 3) All traffic between KaliVM and LinuxVM are blocked except for SSH and ICMP. Allowed traffic must be inspected (with Antivirus, IPS and Deep SSH Inspection). 4) All other traffic must be blocked except for traffic to the Internet that must be inspected.
Tier2 Setup
DCFW Interfaces:
DCFW Firewall Policy:
vSphere Setup:
Use Cases Tests:
1) With the Tier2 design, it is necessary to block RDP/SSH in the OS Firewall. All traffic will flow between WindowsVM and LinuxVM and will never reach the DCFW for inspection (no hits):
2) All Traffic that flows between KaliVM and WindowsVM will traverse the DCFW and will be filtered/inspected there, because both endpoints are in different broadcast domains:
3) All Traffic that flows between KaliVM and LinuxVM will traverse the DCFW and will be filtered/inspected there, because both endpoints are in different broadcast domains:
4) All other traffic will be dropped by DCFW except for traffic to the Internet, which will be inspected:
Tier3 Setup
DCFW Interfaces:
ISFW Interfaces:
DCFW Firewall Policy:
ISFW Firewall Policy:
Use Cases Tests:
 
1) All traffic will traverse ISFW (represented by a yellow line above) to be filtered or inspected. The VLAN will be translated between ID101<->ID102; 2) All traffic will traverse ISFW (represented by a blue line above) to be filtered or inspected. The VLAN will be translated between ID101<->ID103; 3) All traffic will traverse ISFW (represented by a green line above) to be filtered or inspected. The VLAN will be translated between ID102<->ID103; 4) All traffic to the Internet will traverse ISFW (represented by an orange line above) to be filtered or inspected. The traffic will flow from interface VLAN101-103, leave ISFW on Port2 (EXTERNAL) and it will be delivered at DCFR for further inspection. The return traffic will do the other way around. The VLAN will be translated between ID101-103<->Untagged traffic. All the other traffic will be dropped at ISFW.
VMWare vSphere Caveats
Before starting the vSphere configuration, it is necessary to understand what it means for a vSwitch to work in promiscuous mode and what the 'Forged transmits' option does. Read the relevant VMWare documentation for Promiscuous Mode and Forged Transmits for more information.
A vSwitch in promiscuous mode works in a similar way to a physical switch in promiscuous mode. When a vSwitch is in promiscuous mode, it forwards all network traffic to all virtual machines that are connected to it, regardless of whether the traffic is intended for a specific VM or not.
All traffic will flow through the ISFW, meaning both vSwitches must forward all VM traffic to the ISFW internal and external interfaces, and the traffic in the internal vSwitch will flow through different VMs. This means the ESXi will drop the traffic if 'forged transmits' are not allowed.
There are two viable configuration approaches. The first is to 'allow promiscuous traffic' and 'forged transmits' at the vSwitch level, meaning all VMs will receive all traffic on its vNIC. The second is to 'allow promiscuous traffic' and 'forged transmits' at the Port Group level, meaning only the ISFW vNICs will receive all traffic from all VMs. This article will use the second option to minimize the amount of unnecessary traffic that reaches VM vNICs.
Note that it is only necessary to allow forged transmits on the internal vSwitch Port Group because the same traffic will only flow through more than one VM on that switch.
A complete configuration of both vSwitches will look like this:
A complete configuration of the Port Groups will look like this:
A complete configuration of the VMs will look like this:
To avoid duplicate packets from occurring due to promiscuous mode configuration, create the following configuration on the ESXi host to block them:
Note that those duplicate packets may affect traffic between VMs/devices, such as ARP traffic.
To block Multicast/Broadcast traffic from returning from Physical Switches, create the following configuration on the ESXi host to block the packets:
ISFW Caveats
When deploying a Virtual Firewall operating in transparent mode[2], every interface will be in the same broadcast domain by default, which means network loops can easily be created. To avoid this, deploy the VM[3] with only one network interface to serve as the management interface.
To convert the Firewall from NAT Mode to Transparent Mode, enter the following configuration into the console:
# config system interface edit fortilink set fortilink disable end config system settings set opmode transparent set manageip <xxx.xxx.xxx.xxx/xx> set gateway <xxx.xxx.xxx.xxx> end
After, the FortiGate VM will operate in Transparent Mode. It is possible to create different forward domains to segregate traffic and avoid loops. Changing all default forward domains (0 is the default) is recommended as a best practice. In this case, segregate the management traffic from the more relevant traffic by applying this configuration on the CLI:
# config system interface edit port1 end
It is now safe to add a second network interface to the VM. Make sure to add the correct vNIC version (in this lab, VMXNET3 NICs is being used) depending on the VM template that deployed (check the vNIC type of the management port to be sure). The new 'physical' port will be available on the Firewall as soon as the concludes on vSphere.
Now, configure the Port2 (EXTERNAL) interface in the CLI:
# config system interface edit port2 set broadcast-forward enable set forward-domain 2 set alias "EXTERNAL" end
By default, ARP packets are flooded on all ports belonging to the same forwarding domain, without the need for firewall policies. To change this behavior at the interface settings level, use the parameter 'arpforward'. To forward different broadcast packets, use the 'set broadcast-forward enable' option.
After completing configuration up to this point, it will be safe to add a third network interface to the VM. The new 'physical' port will be available on the Firewall as soon as the process concludes on vSphere. Next, configure the Port3 (internal) and its VLAN interfaces in the CLI:
# config system interface edit "port3" set broadcast-forward enable set forward-domain 2 set alias "INTERNAL" next edit "VLAN101" set broadcast-forward enable set forward-domain 2 set interface "port3" set vlanid 101 next edit "VLAN102" set broadcast-forward enable set forward-domain 2 set interface "port3" set vlanid 102 next edit "VLAN103" set broadcast-forward enable set forward-domain 2 set interface "port3" set vlanid 103 next end
Note that if some physical switches are connected to the ISFW, it is advised to set the 'stpforward' parameter to 'enable' at the physical interfaces to start forwarding BPDU packets.
References
|
