Friday, April 3, 2020

Fortigate play nice with StrongSwan

Hey

I'd like to get StrongSwan working with a Fortigate unit. The VPN tunnel uses ikev1 with certs and then xauth. So that's an easy leftauth=pubkey, leftauth2=xauth. Well, no.. That just doesn't work. It gets stuck, the firewall cannot find the sent cert it messes up. It's because the official Forticlient vpn client sends request as if it was ONLY authenticating by cert and then some magic happens and some time later sends xauth too.

This is from a working Forticlient (debug on the vpn fw):

ike 0:4d609233317bcfb8/0000000000000000:13984: negotiation result ike 0:4d609233317bcfb8/0000000000000000:13984: proposal id = 1: ike 0:4d609233317bcfb8/0000000000000000:13984: protocol id = ISAKMP: ike 0:4d609233317bcfb8/0000000000000000:13984: trans_id = KEY_IKE. ike 0:4d609233317bcfb8/0000000000000000:13984: encapsulation = IKE/none ike 0:4d609233317bcfb8/0000000000000000:13984: type=OAKLEY_ENCRYPT_ALG, val=AES_CBC, key-len=256 ike 0:4d609233317bcfb8/0000000000000000:13984: type=OAKLEY_HASH_ALG, val=SHA2_256. ike 0:4d609233317bcfb8/0000000000000000:13984: type=AUTH_METHOD, val=RSA_SIG. ike 0:4d609233317bcfb8/0000000000000000:13984: type=OAKLEY_GROUP, val=MODP2048. ike 0:4d609233317bcfb8/0000000000000000:13984: ISAKMP SA lifetime=86400 

And this from my leftauth=pubkey, leftauth2=xauth

ike 0:fc67cd9d55028ab8/0000000000000000:13986: negotiation result ike 0:fc67cd9d55028ab8/0000000000000000:13986: proposal id = 1: ike 0:fc67cd9d55028ab8/0000000000000000:13986: protocol id = ISAKMP: ike 0:fc67cd9d55028ab8/0000000000000000:13986: trans_id = KEY_IKE. ike 0:fc67cd9d55028ab8/0000000000000000:13986: encapsulation = IKE/none ike 0:fc67cd9d55028ab8/0000000000000000:13986: type=OAKLEY_ENCRYPT_ALG, val=AES_CBC, key-len=256 ike 0:fc67cd9d55028ab8/0000000000000000:13986: type=OAKLEY_HASH_ALG, val=SHA2_256. ike 0:fc67cd9d55028ab8/0000000000000000:13986: type=AUTH_METHOD, val=RSA_SIG_XAUTH_I. ike 0:fc67cd9d55028ab8/0000000000000000:13986: type=OAKLEY_GROUP, val=MODP2048. ike 0:fc67cd9d55028ab8/0000000000000000:13986: ISAKMP SA lifetime=86400 

which eventually lands

ike 0:XXXXNAMEHEREXXXX:13986: peer CERT not found 

As can be seen, auth_method should only be rsa_sig and not rsa_sig_xauth_i. Which is only leftauth=pubkey. But that also doesn't work as then StrongSwan neither responds to xauth requests nor does it send on its own.

Now back to the working Forticlient debug log (on fw):

ike 0:VPNNAME:13984: initiating XAUTH. ike 0:VPNNAME:13984: sending XAUTH request ike 0:VPNNAME:13984: enc ... ike 0:VPNNAME:13984: sent IKE msg (cfg_send): ip and stuff here ike 0:VPNNAME:13984: peer has not completed XAUTH exchange ike 0: comes ips here ike 0: IKEv1 exchange=Mode config id=blabla ike 0: in blabla ike 0:XXXNAMEHEREXXX:13984: blabla ike 0:VPNNAME:13984: received XAUTH_USER_NAME 'my.user' length 10 ike 0:VPNNAME:13984: received XAUTH_USER_PASSWORD length 16 ike 0:VPNNAME: XAUTH user "my.user" 

Which again is quite f#*&n odd... It seems like Fortigate FW sends XAUTH request, Forticlient doesn't respond and then yet it just sends XAUTH on its own? Despite its initial type=AUTH_METHOD, val=RSA_SIG ???

Seems absolutely out of spec for me.. Is there any way I can get StrongSwan behave that way? Or any other open source client for that matter. So again. FW is configured to use cert for auth and then xauth (via ldap integration)

Thanks



No comments:

Post a Comment