Hi everyone,
I'm trying to establish a site-to-site IPsec VPN between OPNsense 26.1.9 and a FortiGate.
The IKE Phase 1 comes up successfully, but Phase 2 is always rejected by the FortiGate.
FortiGate configuration
Phase 1
IKE Version: IKEv1
Mode: Main
Authentication: PSK
Proposal: AES128-SHA256
DH Group: 5 (MODP1536)
Lifetime: 86400
NAT-T: enabled
Phase 2
PFS: enabled
DH Groups: 14,5
Proposals:
- AES128-SHA1
- AES256-SHA1
- AES128-SHA256
- AES256-SHA256
- AES128-GCM
- AES256-GCM
Lifetime: 43200
Traffic selectors:
Local: 10.202.159.192/26
Remote: 10.200.0.0/14
There is also a second Phase2 on the FortiGate:
Local: 10.202.159.192/26
Remote: 10.224.0.0/11
OPNsense configuration
Phase 1
IKEv1
Main Mode
PSK
AES128-SHA256
DH Group 5
Phase 2
ESP: AES128-SHA256
PFS Group: 5 (also tested with 14)
Local TS: 10.202.159.192/26
Remote TS: 10.200.0.0/14
Generated swanctl.conf:
children {
fae426f8-xxxx {
esp_proposals = aes128-sha256-modp1536
local_ts = 10.202.159.192/26
remote_ts = 10.200.0.0/14
}
}
What works
IKE Phase 1 is established successfully.
StrongSwan log:
selected proposal:
IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536
IKE_SA established
Problem
Immediately after IKE_SA establishment, OPNsense sends:
generating QUICK_MODE request [ HASH SA No KE ID ID ]
The FortiGate immediately responds with:
received (24576) notify
and rejects Phase 2.
Full log excerpt:
IKE_SA established
generating QUICK_MODE request [ HASH SA No KE ID ID ]
received (24576) notify
Packet capture
The Quick Mode exchange is visible:
phase 2/others I oakley-quick[E]
followed immediately by an encrypted Informational packet from the FortiGate.
Question
Even though OPNsense generates:
esp_proposals = aes128-sha256-modp1536
the Quick Mode log still shows:
[ HASH SA No KE ID ID ]
which appears to indicate that no PFS/DH exchange is being included in Phase 2.
Is this expected behavior in StrongSwan/OPNsense for IKEv1?
Could this indicate that the Phase2 PFS group is not actually being applied, despite the generated proposal containing
modp1536?
Has anyone seen FortiGate reject Quick Mode with Fortinet vendor notify
(24576) under similar circumstances?
Any suggestions on additional debugging steps would be appreciated.
Thanks!
Why not IKEv2?
Cheers,
Franco
Ciao Franco,
the client on his fortinet has these parameters and I have to respect them
(about:invalid)
Been a long time since I had a Fortinet, but your settings look ok when I compare to some ancient configuration I still have in my backups. It has to be some other mismatch with the traffic selector or behaviour setting.
Cheers,
Franco
The FortiGate has two Phase2 definitions under the same Phase1:
10.202.159.192/26 <-> 10.200.0.0/14
10.202.159.192/26 <-> 10.224.0.0/11
OPNsense currently has only the first Child SA configured.
Could FortiGate reject Quick Mode if it expects both selectors to be configured on the peer?
Also, OPNsense generates start_action=start while FortiGate has auto-negotiate disable.
Strongswan logs if the traffic selectors are unacceptable.
For IPsec in general its a good idea if both peers are configured exactly the same, especially for IKEv1 which is pain.
Create both children.
But as far as I remember you need separate phase 1 for the Fortigate so it should accept the first one already.
Cheers,
Franco