| Description |
This article explains an issue that occurs with internet connection for FortiGate VMs deployed behind an Azure external load balancer. |
| Scope | FortiGate VMs with Azure. |
| Solution |
As part of the deployment template of a FortiGate Active/Passive High Availability cluster in Azure using Internet/External load balancer, the public external load balancer is created with two load balancing rules by default.
The first rule is for TCP/80 and the second rule is for UDP/10551. These rules are not mandatory, but the Azure load balancer will use them to permit the TCP/UDP outbound traffic originating from the FortiGate and from other VMs behind it.
When using this setup, an internet issue may be encountered with backend pool VMs, including FortiGate instances and other protected resources behind the FortiGate. One possible reason is that the external load balancer is not forwarding the traffic to the internet.
As part of the troubleshooting process, a 'ping' command is typically used to test if the internet is responding. However, due to a limitation on the Azure external load balancer, the ICMP isn't supported and is expected to fail. As a result, it is necessary to troubleshoot the issue with TCP connection tests and UDP-specific application layer tests. Examples such as PSPing, Nmap, or telnet may be used.
To allow Fortigate instances and all VMs behind it to access the internet, outbound connectivity must be configured.
If the default Load balancing rules TCP/80 and UDP/10551 created during the deployment of the template were not deleted, the outbound traffic will work without any issue. If the rules were removed, implement one of the following three solutions:
1) Create an Outbound rule which will explicitly define SNAT for the public load balancer. This setup will permit use of the public IP or IPs of the load balancer for outbound connectivity of the backend VMs.
2) Associate a NAT gateway to the subnet of Fortigate VM port1. This is fully managed, highly resilient and does not have the potential problem of SNAT port exhaustion.
3) Create a secondary IP for the public NIC of the firewall and associate a public IP to that NIC. After, create an IP POOL with the secondary IP as the External IP Range, then use that object in the firewall policy to perform the SNAT in the Instance Level. This setup supports the following protocols: TCP, UDP, ICMP and ESP.
Related Articles |
