I have Fortigates in Azure deployed as per below scenario:
Active-passive with external and internal Azure load balancer (LB)
Can session synchronization happen between Fortigates? If YES how? If NO Why?
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Hi SJ,
Yes
Session sync is enabled by default when an HA A/P FortiGate pair is deployed using the Azure Markeplace or Fortinet Github Azure templates, https://github.com/fortinet/azure-templates/blob/main/FortiGate/Active-Passive-ELB-ILB/doc/config-provisioning.md
In the link above you'll see config sections for FortiGate A and FortiGate B, each FortiGate has a section for config system ha, similar to this
config system ha
set group-name AzureHA
set mode a-p
set hbdev port3 100
set session-pickup enable
set session-pickup-connectionless enable
set ha-mgmt-status enable
config ha-mgmt-interfaces
edit 1
set interface port4
set gateway 172.16.136.193
next
end
set override disable
set priority 255
set unicast-hb enable
set unicas
Hope this helps.
This is correct. As you stated, Azure Load Balancer is not capable of failing over after a failed probe, as documented here:
https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-custom-probe-overview#probe-down...
as seen in this link for TCP sessions the Azure LB will continue to forward to the "unresponsive" endpoint, thus only new sessions will work.
For UDP session however existing sessions will be moved to the new node.
From the FortiOS point of view, the behaviour is the standard, where sessions are synchronized between the A/P nodes - if the load balancer (whatever load balancer) sends the traffic to the passive firewall it will be ready to process the session.
/franz
This is a known issue for the Azure load balancer. Even though a health probe failed, it will not re-route the existing sessions.
This is by design, intended to offer the administrator the opportunity to gracefully shutdown from the application to avoid any unexpected and sudden termination of ongoing application workflow.
Hi RJ1,
Session sync is usually used in auto-scaling deployments or in active-active. You can check more details here https://docs.fortinet.com/document/fortigate-public-cloud/7.6.0/azure-administration-guide/917631/co...
Hi SJ,
Yes
Session sync is enabled by default when an HA A/P FortiGate pair is deployed using the Azure Markeplace or Fortinet Github Azure templates, https://github.com/fortinet/azure-templates/blob/main/FortiGate/Active-Passive-ELB-ILB/doc/config-provisioning.md
In the link above you'll see config sections for FortiGate A and FortiGate B, each FortiGate has a section for config system ha, similar to this
config system ha
set group-name AzureHA
set mode a-p
set hbdev port3 100
set session-pickup enable
set session-pickup-connectionless enable
set ha-mgmt-status enable
config ha-mgmt-interfaces
edit 1
set interface port4
set gateway 172.16.136.193
next
end
set override disable
set priority 255
set unicast-hb enable
set unicas
Hope this helps.
Thanks for your answer ,when I initiated RDP connection from my machine to one of the server behind Firewall then I can see session on both Firewalls (A/P). When I check session table for both virtual appliances (FW) , I can see how RDP session can be found on both, which means that sessions are being properly sync between both nodes.
Hi RJ1,
As you are using the Azure Load Balancer (external and internal), make sure to review the behavior when a back-end server (FGT in this case) fails.
https://learn.microsoft.com/en-us/azure/load-balancer/components#health-probes
Joeri
I tested with an SFTP server to verify session synchronization. It appears that even though sessions are synchronized, the transfer is halted during failover. However, it automatically resumes after a few seconds and continues with the file transfer.Need to understand why even sessions are being synced (at least it looks like it), when fail-over is happening, the same session is not preserved and the client does need to generate a new one?
Answer is in the link that JoerVan provided "When a probe fails to respond, the load balancer stops sending new connections to the unhealthy instances. A probe failure doesn't affect existing connections." Load balancer is not capable of failing over the existing session only new sessions are sent to the new Active cluster member.
Created on 10-03-2024 06:50 AM Edited on 10-03-2024 06:51 AM
So, if I understood correctly, even if the Fortigate Firewalls in Azure deployed in HA (A/P) will share sessions (as seen in the session table of both firewalls), and there is fail-over between them, then the session which was established with the Active Firewall will not be moved to the Passive Firewall. The session will be stopped or torn down, and a new session will be generated by the client end. This is because the Load balancer is not capable of failing over the existing session; only new sessions are sent to the new Active cluster member.If that's the case, then why are sessions seen in the passive firewall? Does that make any sense?
You understand correctly, the Azure Load Balancer is the why TCP sessions need to be reestablished.
The A/P FortiGate deployment architecture that uses the FortiGate Azure SDN Connector for failover, moves IP addresses from the failed FortiGate to the newly active FortiGate and updates Route Table UDRs to point to the newly active FortiGate.
In this deployment type session sync makes sense. Using an alternate Load Balancer that supports session continuity would be a solution as well.
This is correct. As you stated, Azure Load Balancer is not capable of failing over after a failed probe, as documented here:
https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-custom-probe-overview#probe-down...
as seen in this link for TCP sessions the Azure LB will continue to forward to the "unresponsive" endpoint, thus only new sessions will work.
For UDP session however existing sessions will be moved to the new node.
From the FortiOS point of view, the behaviour is the standard, where sessions are synchronized between the A/P nodes - if the load balancer (whatever load balancer) sends the traffic to the passive firewall it will be ready to process the session.
/franz
Welcome to your new Fortinet Community!
You'll find your previous forum posts under "Forums"
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.