Skip to main content
mswan
Explorer
February 13, 2026
Question

StrongSwan: Connecting to FortiGate IKEv2 IPSec VPN using PSK + EAP

  • February 13, 2026
  • 2 replies
  • 2358 views

Hello traveler, I'm assuming you've stumbled upon this post after using very specific search terms and are perhaps now at the end of your rope. I hope I can maybe be your last stop.

 

There's a lot that's going to depend on your own setup, such as which cipher suites you're using, your local and remote subnets, etc. I'm not posting this as a definitive guide to get your swanctl.conf perfect - I'm assuming you've already got it to a place where it "should be working".

 

My goal is instead to draw attention to the changes that took my tunnel creation getting totally dropped and ignored by the FortiGate after first contact, to it actually trying to authenticate. It was of course, very simple, but took me hours upon hours to finally get right.

 

The lynchpin was this: Set Remote auth to PSK. Set Local auth to EAP. Make sure Local is set to round 2, otherwise it sends your EAP credentials before it's asked and the Fortigate shrugs it off.

 

Note that on my FortiGate side, I'm not requesting a specific peer ID, which is why I have Local "id" set to blank below. If you, for instance, have FortiGate set to accept specific peer IDs (Configured in the Authentication section of the IPSec Tunnel configuration, under Peer Types) you can enter your peer ID here. I've confirmed this works.

 

Lastly, when connecting, make sure you're using the command:

sudo swanctl --initiate --child hq

If you initiate without specifying the child, it gets stuck at the end and will never fully complete.

 

Here's my exact StrongSwan config with all the identities changed -

swanctl.conf:

 

connections {   hq {     remote_addrs = hq.example.com     version = 2     vips = 0.0.0.0     proposals = aes128-aes256-sha256-modp2048-none     rekey_time = 86400     mobike = no      remote {       id = %any       auth = psk       }      local {       round = 2       auth = eap       id =        eap_id = remoteusername     }      children {       hq {         remote_ts = 0.0.0.0/0         local_ts = 0.0.0.0/0         esp_proposals = aes128-aes256-sha256-modp2048-none         rekey_time = 43200       }     }   } }  secrets {   ike-psk {     secret = 24Q8E61G632D2B1B   }   eap-remoteuser {     id = remoteusername     secret = P4ssw0rd   } }

 

 

2 replies

Stephen_G
Moderator
Moderator
February 16, 2026

Thank you for sharing this, mswan. You rock! It's greatly appreciated.

Stephen_G - Fortinet Community Team
luis_abreu
Explorer
February 27, 2026

Hello.

Great post.

Btw, any info on how to get it working when the user has MFA?  I'm assuming that swanctl won't be able to solve my issue, but any tips on how to solve this?

 

Thanks again.

mswan
mswanAuthor
Explorer
February 27, 2026

My experience is very limited to our implementation alone, but on ours, MFA is no problem at all.

 

The EAP portion of ours is connected to a local RADIUS server leverages EntraID to use SAML. AKA - After submitting user/password, It sends a notification to the associated user's cell phone for them to click "approve". Because the FortiGate handles that part, the login flow is no different than connecting via FortiClient. I initiate the StrongSwan connection which submits my credentials, get the notification on my phone while my VPN connection waits, then as soon as it's approved, it finishes setting up the tunnel.

 

If that doesn't sound similar to what you're doing, StrongSwan is very robust and I wouldn't doubt it's able to accommodate. I just have no idea how to help at that point unfortunately.

luis_abreu
Explorer
February 28, 2026

Hello again.

 

Our users are local users (ie, created on the Fortigate itself) and the token is being sent by email. Maybe there's a way for swanctl to prompt me for that token, but I couldn't managed to get it working. It seems to crash after username/password validation, when it receives some sort of result package from fortigate that it can't handle...interestingly, that crash (which I'm assuming is the gate soliciting the token) is enough for breaking the connection and the email with the token never gets sent. If I go to that user and remove the MFA validation, it works perfectly though...