Out of Spec IPSEC ikev1 + xauth + otp (forticlient) deployments and Strongswan

[jpauling]

it appears that a commonly documented and recommended deployment model from fortinet is actually out of spec.

This is a ikev1 + psk + xauth + otp style setup.

The Phase1 Pre-Shared Key, in combination with Xauth is a known (if legacy) deployment method and widely supported. However it appears that the Xauth round includes a Fortinet specific extension to supply the OTP OAUTH token - making the deployed config un-usable by any ikev1 client outside of the Fortinet One. Effectively making the VPN entirely out of IPSEC compliance. The only acceptable method to provide it would be to override the the user id password combination in the xauth transaction (effectively making the users password the OTP token). However the Token is provided as some sort of either hash with the password (which is undocumented) or enters into a 3rd round of XAUTH (which is out of spec). Two factor auth MUST be supplied via an IKEv2 gateway, using a radius style XAUTH+EAP round. This is widely deployed and supported by all other providers of IPSEC solutions.

Attached is a Strongswan ipsec.conf which get's up to the point of failing due to the xauth round not being able to be completed.

[size="2"]

# ipsec.conf - strongSwan IPsec configuration file
conn rw-base
    dpdaction=restart
    dpddelay=30
    dpdtimeout=90
   # fragmentation=yes

conn vip-base
    also=rw-base
    leftsourceip=%config

#with ikev1
conn spt-ikev1-psk-xauth
    ike=aes128-sha1-modp1536,aes256-sha256-modp1536
    esp=aes128-sha1,aes256-sha1
    also=vip-base
    keyexchange=ikev1
    leftauth=psk
    rightauth=psk
    leftauth2=xauth

#note this normally is rightauth2 but needs to be leftauth2 to get past phase1?
    ikelifetime=86400s
    #leftsubnet=0.0.0.0/0
    lifetime=43200s
    right=<hiddentoprotecttheinnocent>
    #rightsourceip=%any
    #rightsourceip=172.16.254.0/24
    #rightauth2=pin
    left=%any
    leftid=<someuser>
    rightsubnet=0.0.0.0/0
    auto=add
# aggressive mode is incredibly insecure.
conn spt-ikev1-psk-xauth-aggressive
    aggressive=yes
    also=spt-ikev1-psk-xauth
    auto=add[/size]

Event log looks something like this:

[size="2"]

root@kiorewha:/home/aenertia/Documents# ipsec up spt-ikev1-psk-xauth-aggressive
initiating Aggressive Mode IKE_SA spt-ikev1-psk-xauth-aggressive[1] to <hiddentoprotecttheinnocent>
generating AGGRESSIVE request 0 [ SA KE No ID V V V V V V ]
sending packet: from 172.16.254.160[500] to <hiddentoprotecttheinnocent>[500] (559 bytes)
received packet: from <hiddentoprotecttheinnocent>[500] to 172.16.254.160[500] (560 bytes)
parsed AGGRESSIVE response 0 [ SA KE No ID HASH V NAT-D NAT-D V V V V V V ]
received NAT-T (RFC 3947) vendor ID
received DPD vendor ID
received XAuth vendor ID
received Cisco Unity vendor ID
received unknown vendor ID: 82:99:03:17:57:a3:60:82:c6:a6:21:de:00:00:00:00
received FRAGMENTATION vendor ID
received FRAGMENTATION vendor ID
local host is behind NAT, sending keep alives
generating AGGRESSIVE request 0 [ HASH NAT-D NAT-D ]
sending packet: from 172.16.254.160[4500] to <hiddentoprotecttheinnocent>[4500] (140 bytes)
received packet: from <hiddentoprotecttheinnocent>[4500] to 172.16.254.160[4500] (92 bytes)
parsed TRANSACTION request 2656669876 [ HASH CPRQ(X_TYPE X_USER X_PWD) ]
generating TRANSACTION response 2656669876 [ HASH CPRP(X_USER X_PWD) ]
sending packet: from 172.16.254.160[4500] to <hiddentoprotecttheinnocent>[4500] (108 bytes)
received packet: from <hiddentoprotecttheinnocent>[4500] to 172.16.254.160[4500] (92 bytes)
parsed TRANSACTION request 2373497499 [ HASH CPRQ(X_TYPE X_USER X_PWD) ]
generating TRANSACTION response 2373497499 [ HASH CPRP(X_USER X_PWD) ]
sending packet: from 172.16.254.160[4500] to <hiddentoprotecttheinnocent>[4500] (108 bytes)
received packet: from <hiddentoprotecttheinnocent>[4500] to 172.16.254.160[4500] (92 bytes)
parsed TRANSACTION request 3425191250 [ HASH CPRQ(X_TYPE X_USER X_PWD) ]
generating TRANSACTION response 3425191250 [ HASH CPRP(X_USER X_PWD) ]
sending packet: from 172.16.254.160[4500] to <hiddentoprotecttheinnocent>[4500] (108 bytes)
received packet: from <hiddentoprotecttheinnocent>[4500] to 172.16.254.160[4500] (108 bytes)
queueing INFORMATIONAL_V1 request as tasks still active
sending keep alive to <hiddentoprotecttheinnocent>[4500]
peer did not initiate expected exchange, reestablishing IKE_SA
reinitiating IKE_SA spt-ikev1-psk-xauth-aggressive[1]
initiating Aggressive Mode IKE_SA spt-ikev1-psk-xauth-aggressive[1] to <hiddentoprotecttheinnocent>
generating AGGRESSIVE request 0 [ SA KE No ID V V V V V V ]
sending packet: from 172.16.254.160[4500] to <hiddentoprotecttheinnocent>[4500] (559 bytes)
establishing connection 'spt-ikev1-psk-xauth-aggressive' faile

[/size]

[emnoc]

I've used the  Duo MFA  radius-proxy with  SSLVPN and IPSEC  vpn with no problems  FWIW

Ken

[jpauling]

That's a completely different style gateway config than the one described.

Relevance?

Fortinet engineers set this up. It's not a legacy deployment, and I found plenty of fortinet 'cookbooks' which also recommend this style setup.

As it stands this is effectively a lock-in to fortinet end to end and nothing else.

Added insult that they are heavily advertising the availability of their Linux Forticlient; which doesn't even contain ipsec support and so won't work with their own supplied config/gateway.

[Asmadeus]

I got something pretty close to work - it's not psk but certificate auth + xauth otp.

From the strongswan logs it really looked like the fortigate did xauth in a totally separate phase from phase1+phase2 because I would actually go further in the connection if I didn't configure a phase2 at all (and had similar experience with the fortinet client and a strongswan server), but I think it's just a side effect of the logic in strongswan : basically, the fortigate expects the certificate to be sent in full, but strongswan only does that if there is no phase2 when the server doesn't request it explicitly... I'm not sure why, but I could fix it with rightsendcert=always (and make your leftauth2 back to rightauth2 as you write in the comment it should be)

Now I'm reading what I wrote, since you're using psk this cannot be your problem, but it might be something similar or some of the other problems I've had later:

after resolving this I also had various issues with protocols not matching exactly or life times not being correctly set etc but nothing I couldn't resolve by comparing traces with a working client; in debug mode you can get the encryption keys from the logs in both strongswan and the fortinet windows clients so you can look at what both clients do in wireshark, the negotiated key can be added in settings so you can look at the decrypted values directly.

Here is my working config; I'm using the new swanctl syntax though so it doesn't necessarily compare 1-1 but it's pretty close:

connections {
        mynet {
                dpd_delay = 60
                dpd_delay = 300
                version = 1
                remote_addrs = <server-address>
                proposals = aes256-sha1-modp1536
                reauth_time = 8h
                send_cert = always
                vips = 0.0.0.0
                local {
                        auth = pubkey
                        certs = clientcert.pem
                }
                local-xauth {
                        auth = xauth
                        xauth_id = <login>
                }
                remote {
                        auth = pubkey
                }

                children {
                        mynet {
                                remote_ts = 0.0.0.0/0
                                esp_proposals = aes128-sha1-modp1536
                                rekey_time = 1637
                                life_time = 1800

                               # these are local things, you can do it differently
                                mark_in = %unique
                                set_mark_in = %same
                                mark_out = %unique
                                set_mark_out = %same
                                updown = /etc/strongswan/updown.sh
                        }
                }
        }
}
secrets {
        xauth-login {
                id = <login>
                secret = "your-otp-token"
        }
}

I don't have access to the server-side configuration to give you that, but basically comparing with the windows setting clients the reauth time and life time were there (rekey time wasn't, but doc says life time = rekey time + 10% by default so I back-adjusted accordingly); the client also lists two proposals so you might need to try both.

The main problem I have left now is that the strongswan client isn't very otp-oriented, I couldn't get it to prompt me for the secret everytime, it has to be written in the config, so it isn't very convenient to use... But ultimately, that worked.

Good luck!