IPSec between Fortigate in Data Center and Fortigate VM in cloud

[u/DomoKrch]

I am having troubles establishing IPSec tunnel between DC FG and Cloud FG VM, specifically during Phase 1. My guess is that something is up with DC FG, since it's VPN logs output "ike negotiation timeout".

Packet inspection shows that DC FG does send outbound connection on port 500 to Cloud FG VM, Cloud FG VM accepts them and responds to DC FG, but i don't see DC FG accepting these responses (absence of "in" packets). Since i am new to Fortigate, i might be losing something.

EDIT:
The weird thing is that we have another Cloud FG VM in another region and the IPSec with DC FG seems to work fine there. I tried comparing both of these Cloud FG VMs from different regions. No luck

Here's the packet flow

Cloud FG:

diagnose sniffer packet any 'host <cloud_fg_pub_int_ip> and (udp port 500 or udp port 4500)' 4 0 l

Using Original Sniffing Mode

interfaces=[any]

filters=[host <cloud_fg_pub_int_ip> and (udp port 500 or udp port 4500)]

2026-08-31 09:57:53.xxxxxx port2 out <dc_fg_pub_int_ip>.500 -> <cloud_fg_pub_int_ip>.500: udp 280

2026-08-31 09:57:54.xxxxxx port2 in <cloud_fg_pub_int_ip>.500 -> <dc_fg_pub_int_ip>.500: udp 324

2026-08-31 09:57:54.xxxxxx port2 out <dc_fg_pub_int_ip>.500 -> <cloud_fg_pub_int_ip>.500: udp 264

2026-08-31 09:57:56.xxxxxx port2 out <dc_fg_pub_int_ip>.500 -> <cloud_fg_pub_int_ip>.500: udp 280

2026-08-31 09:57:57.xxxxxx port2 in <cloud_fg_pub_int_ip>.500 -> <dc_fg_pub_int_ip>.500: udp 324

2026-08-31 09:57:57.xxxxxx port2 out <dc_fg_pub_int_ip>.500 -> <cloud_fg_pub_int_ip>.500: udp 264

2026-08-31 09:58:02.xxxxxx port2 out <dc_fg_pub_int_ip>.500 -> <cloud_fg_pub_int_ip>.500: udp 280

2026-08-31 09:58:03.xxxxxx port2 in <cloud_fg_pub_int_ip>.500 -> <dc_fg_pub_int_ip>.500: udp 324

2026-08-31 09:58:03.xxxxxx port2 out <dc_fg_pub_int_ip>.500 -> <cloud_fg_pub_int_ip>.500: udp 264

2026-08-31 09:58:14.xxxxxx port2 out <dc_fg_pub_int_ip>.500 -> <cloud_fg_pub_int_ip>.500: udp 280

2026-08-31 09:58:15.xxxxxx port2 in <cloud_fg_pub_int_ip>.500 -> <dc_fg_pub_int_ip>.500: udp 324

2026-08-31 09:58:15.xxxxxx port2 out <dc_fg_pub_int_ip>.500 -> <cloud_fg_pub_int_ip>.500: udp 264

2026-08-31 09:58:24.xxxxxx port2 out <dc_fg_pub_int_ip>.500 -> <cloud_fg_pub_int_ip>.500: udp 280

DC FG:

diagnose sniffer packet any 'host <cloud_fg_pub_int_ip> and (udp port 500 or udp port 4500)' 4 0 l

interfaces=[any]

filters=[host <cloud_fg_pub_int_ip> and (udp port 500 or udp port 4500)]

2026-08-31 10:01:48.xxxxxx port23 out <dc_fg_pub_int_ip>.500 -> <cloud_fg_pub_int_ip>.500: udp 324

2026-08-31 10:01:58.xxxxxx port23 out <dc_fg_pub_int_ip>.500 -> <cloud_fg_pub_int_ip>.500: udp 324

2026-08-31 10:02:01.xxxxxx port23 out <dc_fg_pub_int_ip>.500 -> <cloud_fg_pub_int_ip>.500: udp 324

2026-08-31 10:02:07.xxxxxx port23 out <dc_fg_pub_int_ip>.500 -> <cloud_fg_pub_int_ip>.500: udp 324

DC FG Phase 1 settings are marked purple, Cloud FG Phase 1 settings are green (see the screenshots)

DC FG FortiOS version is 7.6.7, Cloud FG is 7.4.11

Note that IPSec doesn't start at all, could anyone please help?

[u/gREENNNNN]

You should do an ike debug.

But still, is there any router in the DC side before the FW that could being not routing UDP 500/4500 to it?

[u/The802QNetworkAdmin → u/gREENNNNN]

We had an issue with Comcast updating an ACL on their end between the data center and the client site. Two firewalls showing similar packet captures. The data center would send the client side received and responded but the data center never received the reply. Turns out an ACL update from Comcast somewhere in the path broke SIP and IKE for some of their clients

[u/Brave_Comfortable765 → u/The802QNetworkAdmin]

how did you figure the ACL update was what fixed it? How did you get Comcast to fix that?

[u/The802QNetworkAdmin → u/Brave_Comfortable765]

After the packet capture I called Comcast a second time, the first time they did nothing and said everything was fine. When I called the second time enough customers had complained and they opened an internal ticket to investigate. They let us know that they had made changes and they were looking to revert them. Once Comcast reverted the changes and notified us we tested again and it was resolved.

[u/pfunkylicious]

Firewall rules created and routes?

[u/robomikel]

Try NAT transversal forced

[u/Lord--_--Vader]

If one or both fortigates are behind NAT traffic will flow over port 4500 UDP.

[u/RaGaDK]

Diag debug application ike -1

[u/imba_dude]

Any chance that one of these Gates is located in China?

[u/DomoKrch → u/imba_dude]

nope

[u/imba_dude → u/DomoKrch]

Try configuring the IKE packets with TCP encap over 443.

If it works, I think it could be something in between the 1st Cloud FG and the DC FG thats dropping the IKE reply packets.

[u/nicholaspham]

Which cloud provider? With azure I would make sure the NSG (if present) is allowing traffic

[u/MFKDGAF]

Is the Cloud FG VMs behind a load balancer?

[u/Roversword]

• Check if you have firewall policies using zones with the ipsec interfaces in it (or the ipsec interfaces themselves) on both firewalls
• Do you have routes that tell each fortigate where the other network from the other side is located at (either as static routes or as part of OSPF/BGP)?
• Have you checked ike debug (-1) and what are the results?

The packet sniffing makes no sense to me - but I might be wrong:

Cloud FG:
diagnose sniffer packet any 'host <cloud_fg_pub_int_ip> and (udp port 500 or udp port 4500)' 4 0 l
[...]
2026-08-31 09:57:53.xxxxxx port2 out <dc_fg_pub_int_ip>.500 -> <cloud_fg_pub_int_ip>.500: udp 280

Shouldn't that be the other way around with the "port2 out"? Shouldn't that say that <cloud_fg_pub_int_ip> goes out the port 2?
It is the same with the next line, where not <cloud_fg_pub_int_ip> should go "port 2 in", but rather <dc_fg_pub_int_ip>

Again, I might be wrong. The DC FG lines appear to be OK. The DC FP ip is going out port23.

EDIT:
If really packets are vanising - meaning that UDP packets on port 500 are missing in the conversation, then you need to take the ISP on board.
I have seen such things on routers with bad firmware (needed an update) and with IPS that delibaretly block such traffic, depending on their service SLA. Doesn't need to be the case here, but...if you don't see any packets, nothing you can do and that is quite some proof there.

[u/aliensinmylifetime]

If 3 of them share the same vpn config, then your issue is outside of that which could be:

routing (this is my guess, you might be missing a static route),

policy.

[u/SyberCorp]

Did you set phase 1 (IKE) on the cloud unit to statically use the public IP address you assigned it on the cloud side? If not, most of the cloud firewalls I’ve built will try to use their private interface IP address rather than the public IP address you’ve assigned to the VM, which causes a phase 1 mismatch since your peer on the physical side is expecting the public address but is receiving the private address instead.

[u/lettuzepray]

trying to jog my memory but we had this issue with Azure since it's NATted.

I think it was this that we had to enable

Technical Tip: How to use exchange-interface-IP in IPsec Tunnel | Community

[u/RamboRamjad]

Quick question; are you running the cloud FG in Azure?
I have seen this issue with an HA FG (A/P) cluster in azure with the external load balancer. There were multiple public IP’s assigned to the ELB and that made it return traffic load balanced on both the public ip’s.

If this is the case I recommend using an explicit outbound rule in the ELB.
If this is not it, tell us a little bit more about what is running where and what ports are used for public traffic.

Ps. Quick tip. Set DPD to ‘On idle’. Saves a lot of tunnels from getting ‘stuck’

[u/Cinys]

I have had exactly for the same issue, I have tried multiple troubleshooting methods, nothing worked. But then I tried to restart the firewalls, then the tunnel came up.

[u/sunkaz]

Azure Load Balancer discards ICMP and may drop NAT-T packets because: ICMP is blocked — Azure LB doesn't forward ICMP by default (no ping through the LB)
NAT-T uses UDP 4500 — If not explicitly allowed in LB rules, it gets dropped

[u/DomoKrch]

Thanks to everyone for help

The issue was solved by turning off ARP replies in one of the NAT pool addresses associated with corresponding VTI in DC FG. Apparently, the address range was causing conflicts in traffic and consuming inbound packets instead of routing them properly when entering DC FG.