IPSec VPN between FortiGate100 and WRV54G

Discussion in 'Cisco Small Business Routers and VPN Solutions' started by generaltab, Feb 7, 2008.

  1. generaltab

    generaltab LI Guru Member


    I have a FortiGate100 at a main location. I have placed three Linksys WRV54G units and one WRVS4400N at remote locations. I would like to configure IPSec VPNs between the main and remote locations. So far, I have failed with "probable pre-shared secret mismatch" errors being the most common. The failing tunnel's name is usually incorrectly identified as one of the other tunnels in these errors, which might explain the mismatch, but not the source of the confusion between tunnels.

    The main location is known as "WalnutCreek".
    The remote locations are known as "Oakland", "Amy", "Steven", and "Vince".

    I would appreciate it greatly if anyone would have a look at the following screenshots of the devices at both ends. I've followed the guides closely, but so far have been unable to establish more than one tunnel that lasted more than a day. I'm stumped!








  2. generaltab

    generaltab LI Guru Member

    Here are screenshots of the Linksys configurations.

    Thanks again!




  3. generaltab

    generaltab LI Guru Member

    Ok. I switched them all to aggressive mode and now the "steven" tunnel is up, but the others all give a "Waiting for Connection" VPN status on the Linksys. What does "Waiting for Connection" indicate?
  4. DocLarge

    DocLarge Super Moderator Staff Member Member

    At first glance, enable the "keepalive" option on your tunnels so you're tunnels will stay enabled once you get them going. Next, you need to be consistent with your "DH" settings. In your very first slide, you check the boxes for 1, 2, and 5 for phase I, yet in phase II, you checked "2" only. So, just check the box for DH group "2" in phase I and leave phase II as it is. The encryption and hash 3DES/SHA1 that you're using is fine from what I can see.

    Additionally, try and be consistent with the "lifetime" seconds. Set both sides (phaseI and phaseII) for 28800 for both sites (8 hours) to give yourself the maximum amount of time to keep the tunnels going. Also, have a look at this tutorial:


    Lastly, try a simple password like abcd1234 for your tunnels. Post back with what you find and we'll try and go from there...
  5. generaltab

    generaltab LI Guru Member

    Thanks, Jay. I also received the following from a Fortinet engineer:

    It's useless to bind more than one Main-Mode PSK *dialup* phase1 to the same FGT IP.
    If you configure more than one *dialup* phase1 in MM PSK on the same FGT IP then the same phase1 will always be matched by all dialers. The error will show up in the third MM round (authentication).

    That's not a FortiOS limitation, it's inherent to the way MM PSK handles the phase1 root key (SKEYID).
    SKEYID calculation includes the PSK of the phase1. The derived keys (SKEYID_e, SKEYID_a) used for the phase1 encryption and authentication are therefore dependent on the PSK.
    When multiple *dialup* MM PSK phase1 exists, IKE has no way to know which one must be matched. The first one (in its internal list) is therefore always matched.

    When the phase1 initiator sends the MI3 message (fifth MM message) this message is protected with its locally calculated SKEYID_e/SKEYID_a. If the phase1 which was chosen by the responder is not the correct one, then SKEYID_e and SKEYID_a on the responder are different from those on the initiator therefore leading to a 'probable PSK mismatch' in the "debug ike'.

    To work around this MM PSK limitation for multiple dialup connections :
    - use aggressive mode with ID (ID is sent in clear text in the first AM message and can therefore be used by the responder to select the correct phase1)
    - use Main Mode with RSASIG

    MM RSASIG doesn't suffer this limitation and still offers ID protection.
    Upon receipt of the first MM message, the IKE responder picks up the first dialup MM RSASIG phase1in its list. If it's not the correct phase1, it's not an issue. When MI3 message will reach the IKE responder, it will be able to authenticate it and to decipher it because SKEYID_a/e doesn't depend on the phase1 specification (it's mainly based on the KE and Nonce of the DH exchange of the current IKE negotiation). Once the MI3 message is decrypted, the IKE responder finally knows the ID of the initiator (which is the DN of the initiator certificate) and can therefore "fallback" to the correct phase1 if needed.
    To allow such MM RSASIG "fallback", all MM RSASIG dialup phase1 must be configured with the same proposals.

    Hope it's clear and it helps.

    Fortinet EMEA TAC L2 engineer.

    I'm ill so I was just wandering around and I thought I could help to clarify this IKE behavior.
    Since that's my daily job and that I don't expect to be ill too often, I'll probably won't be back for a while ;-)​

    So now my question is, how can I determine the Linksys' peer ID in order to provide it to the FortiGate in aggresive mode?

    Thanks again,

  6. pablito

    pablito Network Guru Member

    I don't know the equivalent setting on the WRV is but on my rv016 I had to set "AH Hash Algorithm" to SHA1 from the default MD5, this solved a similar error for me. I also could not set compression for some reason (if one side can't they should simply agree not to compress). And for some reason the fortigate was very fussy about the password so start with something simple and short until you get a tunnel working.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice