Can't establish IPSec VPN from Fortigate to Palo Alto

[username12345]

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. 

[abarushka]

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?

[username12345]

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.

[abarushka]

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.

[CarmelaHolland]

Thank you for providing more detailed information about the IKE negotiation issue.

[Tcmh]

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?