FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
kcheng
Staff
Staff
Description

This article describes that the Microsoft Azure Linux Agent (waagent) manages Linux and FreeBSD provisioning and VM interaction with the Azure Fabric Controller.

 

(For more information, refer to https://docs.microsoft.com/en-us/azure/virtual-machines/extensions/agent-linux).

 

FortiGate deployed in Azure is equipped with Microsoft Azure Linux Agent during installation.

It is possible to find out that the Microsoft Azure portal complains that the virtual machine agent is not ready and requests to troubleshoot the issue:

 

kcheng_0-1654838558263.png
Scope FortiGate Azure.
Solution

When this issue happens, it usually indicates a problem with connecting to the Azure Fabric Controller (168.63.129.16).

It is possible to confirm that with the following steps:

 

1) To check the connectivity between FortiGate virtual machine agent and Azure Fabric Controller, run the following command:

 

# diag deb app waagent -1

# diag deb en

# diag test app waagent 1

 

kcheng_1-1654838716236.png

 

It is noticed that the virtual agent is trying to connect to Azure Fabric Controller IP 168.63.129.16 and the connection did not manage to go through.

 

2) Run the debug flow to check on the traffic flow:

 

# diag deb flow filter addr 168.63.129.16

# diag deb flow sh function-name en

# diag deb flow sh iprope en

# diag deb flow trace start 20

# diag deb en

 

kcheng_2-1654838774007.png

 

From the above debug flow, it is possible to see that the traffic towards Azure Fabric Controller is being forwarded to port2 which is supposed to be meant for the internal network traffic.

 

3) Check the routing table for 168.63.129.16 with the following command:

get router info routing-table details 168.63.129.16.

 

kcheng_3-1654838881574.png

 

It was noticed that there is a static route configured to route traffic destined to 168.63.129.16/32 to port2.

 

4) Azure Fabric Controller IP is considered as an external IP from FortiGate point of view.

Hence, the traffic should be exiting using port1 instead of port2.

 

In the above scenario, removing the static route and reinitiating waagent connection would resolve the issue.

 

kcheng_4-1654838968921.png

 

Recheck the connection with the following command, and it will be possible to see that waagent is now communicating with Azure Fabric Controller successfully:

 

# diag deb reset

# diag deb app waagent -1

# diag deb en

# diag test app waagent 1

 

kcheng_5-1654839041491.png

 

5) Once the waagent is able to send the traffic towards the correct interface, the agent status and host details will be appearing in Azure console respective:

 

kcheng_6-1654839086055.png

 

The connection between Microsoft Azure Agent and Azure Fabric controller would not impact FortiGate performance.

There is no downtime required to perform the above remediation steps.

 

If External Load Balance or Internal Load Balance is used, the connection of the virtual machine agent will be transmitting on both port1 and port2.

Hence, 2 static routes would be required:

 

# config router static
    edit <static_route_index>
        set dst 168.63.129.16 255.255.255.255
        set gateway <gateway_IP>
        set device "port2"
    next
        edit <static_route_index>
            set dst 168.63.129.16 255.255.255.255
            set gateway <gateway_IP>
            set device "port1"
    next
end

 

For more information on deploying the FortiGate with ELB/ILB scenario, please refer to the following document:

https://docs.fortinet.com/document/fortigate-public-cloud/7.2.0/azure-administration-guide/917631/co...

Contributors