Skip to main content
jpauling
jpauling
New Member
August 15, 2018
Question

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

  • August 15, 2018
  • 3 replies
  • 8370 views

 

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]

 

    3 replies

    emnoc
    emnoc
    New Member
    August 15, 2018

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

     

    Ken

    jpauling
    jpaulingAuthor
    New Member
    August 15, 2018

    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
    Asmadeus
    New Member
    December 9, 2018

    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!
     
    
        
                                                
    
        
    
    
    

            
    
                                        
    
            
                        
    
                                                                                                            
            
    

    

    

        
    
                    
    
    
    
    

    

    
    
    

                                        
    
                                                        
    
            
        
    
    

    

    

                                    
    Terms & ConditionsAccessibility statement
    
            
        

    

        
            
    
        
    
        


        
        
            


        
    

                                                        

                                                
    
    
                    

    
    


            

                                        
        

        
    
        
    
            
    
        
        
    
    



    
    
    
        
    
            
                Thought Leadership Security Summit. Outpace New Threats with AI - enhanced defense. Tuesday, Septmeber 15, 8:30 AM - 2:30 PM PT. The Golf Club at Newcastle, WA.
            
        
    
          
    
            
                Virtual event | September 2026. SASE summit. The age of autonomous trust. Register here!