The Palo Alto is a VM-300 deployed in AWS running software version 8.1.23. It is behind a NAT, but is configured to present the AWS Elastic IP (public IP) as the identifier. The Fortigate is a 600D running 6.0.4, deployed on-prem.
Attempting IKEv2, I see these messages from the Palo Alto:
IKEv2 IKE SA negotiation is started as responder, non-rekey. Initiated SA: 10.20.30.37[500]-203.0.113.123[500] SPI:e4a92c5d6f68e7eb:2a5bbbbba383590d.
ignoring unauthenticated notify payload (16430)
My initial thought was an IKEv2 ID or NAT-T mismatch, so just for giggles, I set both sides for IKEv1 with NAT-T disabled and also "dumbed down" the proposals to only include AES128/SHA-1/Group2 on both ends. The error from the Palo Alto then switches to this:
IKE phase-1 negotiation is started as responder, main mode. Initiated SA: 10.20.30.37[500]-203.0.113.123[500] cookie:ac6fbea33f3808f1:42baa6f64bd23c89.
IKE phase-1 negotiation is failed as responder, main mode. Failed SA: 10.20.30.37[500]-203.0.113.123[500] cookie:2f7f5ae811aac034:a602a3f6b1f49f9f. Due to timeout.
IKE phase-1 SA is deleted SA: 10.20.30.37[500]-203.0.113.123[500] cookie:2f7f5ae811aac034:a602a3f6b1f49f9f.
On the Fortigate side, it just indicates a successful Phase 1 negotiation and that's it. I don't see anything related to Phase 2.
I do have a successful VPN between the same Palo Alto and a Fortigate 60-E running 7.0.12 no problem. I've been able to switch this connection between IKEv1 and v2, different encryption, etc with no issue.
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.
Hello,
I suspect that there is connectivity issue. You may consider to sniff IKE traffic on both sides in order to verify whether both IPsec peers send/receive traffic.
10.20.30.37[500]-203.0.113.123[500] cookie:2f7f5ae811aac034:a602a3f6b1f49f9f. Due to timeout.
Is there particular reason why NAT-T is disabled?
Created on 07-18-2023 10:31 AM Edited on 07-18-2023 02:12 PM
I doubt it's connectivity. Ping works fine between the public IPs, and if I deliberately mismatch encryption settings, the Palo Alto reports error messages like this:
IKE phase-1 negotiation is failed. no suitable proposal found in peer's SA payload.
ignoring unauthenticated notify payload (NO_PROPOSAL_CHOSEN)
packet lacks expected payload
I did run all the debug commands, and looks like the "timeout" message is more a symptom of a "stuck in Phase 1" problem. Phase 1 and 2 are up on the Fortigate side, but the Palo Alto only reports a partial Phase 1 SA.
fortigate (my-vdom) # diagnose vpn ike gateway list name TEST_VPN_1
vd: my-vdom/3
name: TEST_VPN_1
version: 1
interface: vlan123 39
addr: 203.0.113.123:500 -> 198.51.100.140:500
created: 3s ago
IKE SA: created 1/1
IPsec SA: created 0/0
id/spi: 19247241 8f6c06152926e560/0000000000000000
direction: responder
status: connecting, state 3, started 3s ago
fortigate (my-vdom) # diagnose vpn tunnel list name TEST_VPN_1
list ipsec tunnel by names in vd 3
------------------------------------------------------
name=TEST_VPN_1 ver=1 serial=1d 203.0.113.123.1:0->198.51.100.140:0 dst_mtu=0
bound_if=39 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/520 options[0208]=npu frag-rfc run_state=0 accept_traffic=1 overlay_id=0
proxyid_num=1 child_num=0 refcnt=10 ilast=11 olast=11 ad=/0
stat: rxp=0 txp=0 rxb=0 txb=0
dpd: mode=on-demand on=0 idle=20000ms retry=3 count=0 seqno=0
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=TEST_VPN_1 proto=0 sa=0 ref=1 serial=2
src: 0:0.0.0.0/0.0.0.0:0
dst: 0:0.0.0.0/0.0.0.0:0
run_tally=1
The sa=0 implies traffic selector mismatch, but both sides are set for the route-based VPN (0.0.0.0/0.0.0.0)
Re: NAT-T, the connection should work with or without it. It's only disabled as a troubleshooting step. I've previously seen scenarios with Cisco and CheckPoint where one side negotiates NAT-T (udp/4500) with IKEv2 but old-school ESP (protocol 50) for IKEv1 but the other side disagrees.
Hello,
Phase1 is not coming up on FortiGate side either:
status: connecting, state 3, started 3s ago
Connecting means Phase 1 is down.
https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-IPsec-VPNs-tunnels/ta-p/195955
You may consider to consider ike debug (diag deb app ike -1) on FortiGate side while trying to bring the tunnel up.
Thank you for providing more detailed information about the IKE negotiation issue.
I spotted version 1 under "diagnose vpn ike gateway list name TEST_VPN_1"
name: TEST_VPN_1
version: 1
isnt it a IKE v2 VPN?
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1529 | |
1027 | |
749 | |
443 | |
209 |
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.