Forticlient IPsec VPN - How to configure

hi,

if no traffic is observed on UDP/500 , UDP/4500 most likely somewhere along the way this is blocked and has nothing to do with the config of the IPsec on the FortiClient

has this setup worked before?

The zero packets on x1 is the answer, and it points you away from where you are looking. If the FortiGate sniffer sees nothing on UDP 500 and 4500 during connection attempts, the IKE never reaches the FortiGate at all. That means this is not a phase1 config problem and not a FortiClient to FortiOS interop bug. An interop or negotiation issue would show packets arriving and then failing, not zero packets. So you can stop checking phase1, mode-cfg, XAuth and 7.4.12 known issues, none of that matters until packets actually arrive. The job now is to find where in the path the IKE dies.

One thing the sniffer result already rules out: it is not a local-in policy or anything on the FortiGate dropping it, because the sniffer captures before local-in policy. The packets are simply not getting to x1.

The fastest way to split the problem is to capture on the client. Run Wireshark on the home PC, filter udp.port==500, and start a connection attempt. There are only two outcomes:

The client sends nothing, or sends to the wrong IP. Then it is client side. Check that vpn2.dhansol.com resolves to 184.180.43.35 from the home PC itself, not just from the FortiGate, since a stale or different client DNS answer sends the IKE to the wrong address. Confirm the FortiClient entry is an IPsec VPN and the remote gateway is correct, and that no local firewall, AV or Windows policy is blocking FortiClient's outbound IKE.

The client sends IKE to 184.180.43.35 but the FortiGate still sees zero. Then the path between them is dropping UDP 500 and 4500, and you localise it like this:

Test from a completely different external network, for example a phone hotspot. If it works from the hotspot, your home network or home ISP is blocking outbound IKE, which is common on some home and CGNAT connections. If it is still zero from the hotspot too, then the block is on the FortiGate side of the path, meaning your upstream ISP is filtering inbound UDP 500 and 4500 to 184.180.43.35, even though ICMP to that IP passes. ICMP passing does not prove UDP 500 passes, they are treated independently.

While testing, widen the FortiGate capture so you do not miss anything: diagnose sniffer packet any "host <client-public-IP>" 4 0 a during a connection attempt. That catches the traffic even if it lands on a different interface than you expect or on a non-standard port, and it confirms beyond doubt whether anything from that client reaches the box.

To answer your direct question plainly: there is no FortiClient 7.4.x to FortiOS 7.4.12 dialup interop issue that produces zero packets, because an interop issue requires packets to arrive first. This is pure reachability. The client capture plus the hotspot test will tell you within a few minutes whether the drop is on the client, the client ISP, or your own ISP, and that is where the fix is, not on the FortiGate.

since you are not receiving any packet on the FortiGate there could be issue with udp 500 packet on the user ISP side.

Take a pcap on user machine (wireshark) and on FGT and take the capture simultaneously on both sides. If you see udp 500 packet being sent from the user machine and not receiving on the fortigate, it could be issue on the pathway (ISP).