FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
edyrmishi
Staff
Staff
Article Id 416750
Description This article describes an issue where FortiClient does not forward traffic to the FortiGate over an IKEv2 IPsec tunnel when both Phase 1 and Phase 2 are configured with the AES256-SHA512 proposal. The behavior has been observed following an upgrade to FortiClient version 7.4.4.
Scope FortiClient v7.4.4.
Solution

After upgrading to FortiClient v7.4.4, a dial-up IKEv2 IPsec tunnel configured to use the AES256-SHA512 proposal for both Phase 1 and Phase 2 is established successfully, but no return traffic is received from the FortiClient.

 

Traffic flows only in the outbound direction (from FortiGate to FortiClient). Packet capture on FortiGate shows outgoing packets, but no incoming replies.

 

FG181F-4 # diagnose sniffer packet any 'host 172.10.10.100' 4 0 l
interfaces=[any]
filters=[host 172.10.10.100]
2025-10-27 07:44:33.596218 IKEv2-PSK out 10.5.137.251 -> 172.10.10.100: icmp: echo request
2025-10-27 07:44:34.596242 IKEv2-PSK out 10.5.137.251 -> 172.10.10.100: icmp: echo request
2025-10-27 07:44:35.596264 IKEv2-PSK out 10.5.137.251 -> 172.10.10.100: icmp: echo request
2025-10-27 07:44:36.596282 IKEv2-PSK out 10.5.137.251 -> 172.10.10.100: icmp: echo request
2025-10-27 07:44:37.596300 IKEv2-PSK out 10.5.137.251 -> 172.10.10.100: icmp: echo request

 

7.4.4.png

 

IPsec tunnel configuration:

 

config vpn ipsec phase1-interface
    edit "IKEv2-PSK"
        set type dynamic
        set interface "port3"
        set ike-version 2
        set peertype any
        set net-device disable
        set mode-cfg enable
        set ipv4-dns-server1 8.8.8.8
        set proposal aes256-sha512 aes128-sha1
        set dpd on-idle
        set dhgrp 14
        set eap enable
        set eap-identity send-request
        set authusrgrp "Test-Group"
        set transport tcp
        set ipv4-start-ip 172.10.10.100
        set ipv4-end-ip 172.10.10.200
        set ipv4-netmask 255.255.255.0
        set psksecret ENC M+xOJ/E2xz7z1TK26XpaVZEsxdmwx+CX2klLXT99Ly2fHfzcNKruYvUBFMfvCRuvyZmlOqcU3/pdO

AVGOKUqTbPgt8xZ+1mjHnn6GIwVhoH30vDcw7zioDC+/J0ePeWgUBuzNOY7mmPugZPfJp6G/m8dVmZZkxpYVa

+1lB5cZ5PG3khY8hq2NVqJK2KjvpJyhZtDM1lmMjY3dkVA
        set dpd-retryinterval 60
    next
end

 

config vpn ipsec phase2-interface
    edit "IKEv2-PSK"
        set phase1name "IKEv2-PSK"
        set proposal aes256-sha512 aes128-sha1
        set dhgrp 14
    next
end

 

In previous versions (v7.4.3 and older), the same configuration worked as expected.

 

7.4.3.png

 

Workaround:

Phase 1 and Phase 2 proposals need to be configured with a different integrity algorithm (for example, sha256 or sha1). Once changed, traffic begins to flow normally in both directions.

 

config vpn ipsec phase1-interface
    edit "IKEv2-PSK"
        set proposal aes256-sha256 aes128-sha1
    next
end

 

config vpn ipsec phase2-interface
    edit "IKEv2-PSK"
        set proposal aes256-sha256 aes128-sha1
    next
end

 

FG181F-4 # diagnose sniffer packet any 'host 172.10.10.100' 4 0 l
interfaces=[any]
filters=[host 172.10.10.100]
2025-10-27 07:42:41.599001 IKEv2-PSK out 10.5.137.251 -> 172.10.10.100: icmp: echo request
2025-10-27 07:42:41.600243 IKEv2-PSK in 172.10.10.100 -> 10.5.137.251: icmp: echo reply
2025-10-27 07:42:42.599027 IKEv2-PSK out 10.5.137.251 -> 172.10.10.100: icmp: echo request
2025-10-27 07:42:42.599807 IKEv2-PSK in 172.10.10.100 -> 10.5.137.251: icmp: echo reply
2025-10-27 07:42:43.599047 IKEv2-PSK out 10.5.137.251 -> 172.10.10.100: icmp: echo request
2025-10-27 07:42:43.599941 IKEv2-PSK in 172.10.10.100 -> 10.5.137.251: icmp: echo reply
2025-10-27 07:42:44.599065 IKEv2-PSK out 10.5.137.251 -> 172.10.10.100: icmp: echo request
2025-10-27 07:42:44.599945 IKEv2-PSK in 172.10.10.100 -> 10.5.137.251: icmp: echo reply
2025-10-27 07:42:45.599082 IKEv2-PSK out 10.5.137.251 -> 172.10.10.100: icmp: echo request
2025-10-27 07:42:45.599943 IKEv2-PSK in 172.10.10.100 -> 10.5.137.251: icmp: echo reply

 

Note: This issue is reproducible when using IPsec over both TCP and UDP.

 

This issue has been resolved in:
FortiClient v7.4.5 (scheduled to be released in December 2025).
FortiClient v8.0.0 (scheduled to be released in February 2026).
These timelines for firmware release are estimated and may be subject to change.

 

Related articles:
Technical Tip: IPsec dial-up full tunnel with FortiClient 
Technical Tip: FortiClient Dialup IPsec VPN (Split Tunneling)