Azure vnet-vnet traffic via FGT A/P Firewall

[Hassan-wahab]

Hi, 

I have deployed a Fortigate Active/Passive HA firewall in Azure, and it is functioning as expected. However, I am encountering an issue where I am unable to route VNet-to-VNet traffic through the Fortigate. I have configured the routing tables and peered the VNet with the Fortigate VNet. Could someone please assist me in setting up the connectivity to allow and block traffic between VNets using Fortigate policies?

Thanks

[atakannatak]

Hi @Hassan-wahab ,

To route VNet-to-VNet traffic through your FortiGate Active/Passive HA firewall in Azure and control it using FortiGate policies, you need to ensure that your VNets are properly peered and that the necessary routing configurations are in place. Here’s a step-by-step guide to might help you:

Step 1: VNet Peering
Peer the VNets:

Ensure that each VNet is peered with the VNet containing the FortiGate firewall. This includes both the VNet where traffic originates and the VNet where traffic is destined.

https://github.com/40net-cloud/fortinet-azure-solutions/tree/main/FortiGate/VNET-Peering

Step 2: Routing Configuration
Configure User-Defined Routes (UDRs):

In each VNet’s subnet where traffic originates or terminates, create a UDR that directs traffic to the FortiGate’s internal IP address. For example, if you have VNet1 and VNet2:

• In VNet1’s route table, add a route for VNet2’s address space with the next hop as the FortiGate internal IP.
• In VNet2’s route table, add a route for VNet1’s address space with the next hop as the FortiGate internal IP.

Step 3: FortiGate Configuration
Configure Interfaces and Policies on FortiGate:
Ensure that the FortiGate has interfaces or sub-interfaces (if using multiple VNets) corresponding to each VNet.
Create security policies on the FortiGate to allow or block traffic between these interfaces.

Define any necessary address objects and address groups for the subnets within your VNets.
For example:

• Allow traffic from VNet1 interface to VNet2 interface.
• Allow traffic from VNet2 interface to VNet1 interface.
  
  

Troubleshooting Tips:

1. Ensure that the VNet peering connections are configured to allow forwarded traffic.
2. Check the UDRs for any conflicts or incorrect next hop addresses.
3. Verify that the FortiGate firewall policies are correctly defined and placed in the correct order.
   Review FortiGate logs for any blocked traffic or misconfigured settings.
4. Following these steps should help you route and control VNet-to-VNet traffic through your FortiGate firewall in Azure. You can run the following commands to verify that traffic initiated over any VNet is forwarded all the way to the firewall.

You must be ensure the what's the source and the destination before the run below commands. 

--First CLI Screen--

diag sniff packet any "host x.y.z.t and host a.b.c.d" 4 0 a

--Second CLI Screen--

diagnose debug disable
diagnose debug flow trace stop
diagnose debug flow filter clear
diagnose debug reset
diag debug console timestamp enable
diagnose debug flow filter saddr a.b.c.d

diagnose debug flow filter daddr x.y.z.t
diagnose debug flow show function-name enable
diagnose debug flow trace start 9999
diagnose debug enable

BR.

If my answer provided a solution for you, please mark the reply as solved it so that others can get it easily while searching for similar scenarios.

[Hassan-wahab]

Thanks @atakannatak
All my settings are correct but i am still having issues. I can ping both test devices from firewall and vice versa. But i don't see any logs on firewall when i ping east-west devices. 
Do i need to create any specific interface on FGT based on eah vnet? 

I already have internal port2. 

Thanks

[atakannatak]

Hi @Hassan-wahab ,

Did you configure VNet peering? It allows bidirectional traffic between two VNets. If not, the traffic flow won't be allowed by the VNet itself. That's why you can't see anything on your firewall when trying to generate traffic between your east-west devices.

BR.

[Hassan-wahab]

I have fixed the issue. The Fortigate probe response administrative access wasn’t enabled on internal port2 and external port1 thats why the internal load balancer was dropping the traffic.

[Jean-Philippe_P]

Hello Hassan-wahab,

Thanks for sharing this, it will be very useful for users!