Skip to main content
Juan_Garza
New Member
December 30, 2013
Question

pre-shared key

  • December 30, 2013
  • 3 replies
  • 24703 views
The pre shared key for vpn client was defined by other person, how can I find the pre shared key? I managed the Fortigate

    3 replies

    emnoc
    New Member
    December 31, 2013
    Create another one. I don' t think their' s any true methods for reversing the PSK. Also it' s probably due for a PSK change out if you other have came and gone imho
    hrbsupport
    New Member
    January 22, 2014
    Is there a simple way to update the pre shared key for multiple end users (that are using the free forticlient) ? alternatively is it possible migrate users in a more phased basis ---- eg set up a new IPsec vpn with a new preshared key and have that running in parallel with the existing IPsec vpn ? thanks for any advice.
    nothingel
    New Member
    September 17, 2015

    hrbsupport wrote:
    alternatively is it possible migrate users in a more phased basis ---- eg set up a new IPsec vpn with a new preshared key and have that running in parallel with the existing IPsec vpn ?

    I know this is a reply to an old thread.  However, I thought I'd make a suggestion.

     

    Basically, it is possible to use more than one pre-shared key on the same phase1 configuration.  Here is the relevant (but incomplete) config bits:

     

    config vpn ipsec phase1-interface
        edit "tunnelname"
            set type dynamic
            set peertype dialup
            set usrgrp "IPsec-PSKs"
        next
    end

     

    The pre-shared key is not specified in the phase1 configuration.  Instead, each key is represented by a local user.  The client indicates which name/password (key) to use by entering the username as the localID or leaving the localID blank and instead only define a pre-shared key in the form of [username]+[key/password] as one long string.  (This technique can be found in the FortiOS Handbook under the section "Enabling VPN access with user accounts and pre-shared keys".)  Note that aggressive mode is required when using localIDs and there's more than one dynamic/dialup phase1 configuration (see "Choosing main mode or aggressive mode" in the FortiOS handbook).

     

    You can (and perhaps should) still use Xauth with a unique account for each user.

     

    You can then manually distribute the new pre-shared key while keeping the old one alive.  If you're managing Forticlient from a Fortigate, you can "push" the changes although this wouldn't be fool-proof if some clients are not receiving updates in a timely manner.

     

    emnoc
    New Member
    January 23, 2014
    Never done that, typically I ' ve used the cisco vpnclient and craft the cfg file and deliver it to all depts , & with a statement of; by next monday pleas use new profile. You can do the same with the forticlient also. Also you could craft a 2nd dialup vpn, but you probably have to clone the new one and assign new ranges and give them access to the same resources. That would be more work, but would give you a way to walk and migrated from one profile to another and then sat a date for termination. FWIW: Ideally you want to be using xauth for remote-authentication. So the PSK is just one of the many things required. Than you we set expirations and password-life-cycles for the users. Nobody in a big enterprise env uses a remote-vpn with just a share PSK alone for authentication imho. Think about it and you see why; e.g a large ItT dept supporting mobile-devices, wireless clients, remote-office-workers, remote-vendors, etc..... Changing a PSK and distributing this could be a very large challenge. And if you had only a PSK, any compromised would be hard to defeat and without xauth, you have no ideal of who is logged in Next best thing would be, Cert+xauth and you manage the cert expiration for control. A lot gov depts that I work for as remote engineer does just that. It simple and the dept head your working with, controls the issuance of the certification requests. They manage their on signer and sign certifications off their org-signing-certification or delegated signers, base on the role and requirement. They still have xauth btw.