Qs: What method are you using determine IPSEC is not working on the fortianalzyer.
You mention netstat output
Yes exactly, first I did a sniffer trace, and there I saw the that the IKE packets are not answered, then I tried to find the reason for this, and the netstat confirmed it:
filters=[port 500 or port 4500]
8.975055 port1 in 220.127.116.11.500 -> 10.10.10.10.500: udp 512
14.979074 port1 in 18.104.22.168.500 -> 10.10.10.10.500: udp 512
26.975922 port1 in 22.214.171.124.500 -> 10.10.10.10.500: udp 512
Output of the netstat:
udp 0 0 0.0.0.0:162 0.0.0.0:*
udp 0 0 127.0.0.1:500 0.0.0.0:*
udp 0 0 0.0.0.0:59581 0.0.0.0:*
udp 0 0 127.0.0.1:4500 0.0.0.0:*
udp 0 0 127.0.0.1:6001 0.0.0.0:*
So as you can see, no private IP (it's just a snippet but usually the local ip socket should be right under or above the loopack socket)
I believe if your coming thru a NAT device at the FAZ end and ike NAT-T is required due to this nat, you nat-t device might be a cause. I do't recall any means for enabling a NAT-T keep alive function on the FAZ directly. Do you have a topology map of ALL of the devices in the path from FGT ----------------> FAZ @ AWS
You are right about that, when the tunnel worked for a short period of time, the first packets were done via port 500, and then it switched to port 4500, like it should, because NAT is detected. I'm not sure about the topology, the FGT is directly connected to the internet - the FAZ only has a private IP and is NATed to a public IP via Azure settings, but it's a 1:1 NAT.
Does the firewall that send packets to the FAZ, does it have a up lifetime setting that you can modify? if yes, can you set the session lifetime to a extreme lifetime
I can't find anything regarding a life time for the IPsec tunnel, neither in the FAZ CLI reference nor in the FGT CLI reference.
When the ipse-tunnel drop, did you run any dig sniffer packet "port 500 or 4500" and see if anything is being sent between FGT<>FAZ?
Yes like the one I posted above, I only see the packets from the FGT, there are no packets in the other direction.
My apices tunnels which are direct with no nat works fine. I don't believe the DHCP is the issue btw. You could set a static reservation for the FAZ if your concern on address lease/renewals
I don't think the issue in general is with DHCP too, but it's just the problem that the service is not correctly binding the address to the port if DHCP is set. That's why it's not listening after the reboot of the appliance