Can't establish IPSec VPN from Fortigate to Palo Alto
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-203.0.113.123 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-203.0.113.123 cookie:ac6fbea33f3808f1:42baa6f64bd23c89. IKE phase-1 negotiation is failed as responder, main mode. Failed SA: 10.20.30.37-203.0.113.123 cookie:2f7f5ae811aac034:a602a3f6b1f49f9f. Due to timeout. IKE phase-1 SA is deleted SA: 10.20.30.37-203.0.113.123 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.
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=npu frag-rfc run_state=0 accept_traffic=1 overlay_id=0
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.
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.