Skip to main content
AmorFati7734
AmorFati7734
New Member
April 28, 2011
Question

I give up...IPSEC VPN

  • April 28, 2011
  • 9 replies
  • 7617 views
Hello, I' ve tried my hardest to get this up and running but I' m not sure what I' m doing wrong so now I' ve come for help. Recently upgraded from Juniper NS5GT in our main office to a FortiGate 80C. Have a really small remote office with 2 users that were able to connect to the NS5GT device using a DLINK DIR-330 but now after moving to the fortigate i can' t get the DIR-330 to connect to a vpn tunnel. Info: Remote Office WAN IP: Dynamic Internal LAN: 192.168.8.0/24 Router: DLINK DIR-330 Main Office WAN IP: Static (1.1.1.1) Internal LAN: 192.168.1.0/24 Router: Fortigate 80C On the Fortigate i' m running 4.0 MR3 and have created Auto Key (IKE) P1/2 proposals. If you' d like, please check my settings you can see this link for screenshots: http://www.mediafire.com/?j9sz9mkgf0x7j IPSEC_P1 and P2 are from the FortiGate and the DIR files are from the DIR-330. In the Firewall I' ve setup a policy to have source interface/zone by " internal" (192.168.1.0) and source address of Internal.LAN (192.168.1.x address entry) with destination interface/zone of WAN2 and destination address of " REMOTE.SITE" (192.168.8.x) address book entry with a schedule of " always" - service " any" - action " IPSEC" and the VPN Tunnel has been selected as my P1 for this tunnel. Allowing inbound and outbound. And this policy is on top in group view. Here' s a portion of the ipsec debug I have going on that I don' t understand: ike 0:BOStoRIp1:2574:31191: peer proposal is: peer:0:192.168.8.0-192.168.8.255:0, me:0:192.168.1.0-192.168.1.255:0 ike 0:BOStoRIp1:2574:BOStoRIp2:31191: trying ike 0:BOStoRIp1:2574:31191: specified selectors mismatch ike 0:BOStoRIp1:2574:31191: peer: type=7/7, local=0:192.168.1.0-192.168.1.255:0, remote=0:192.168.8.0-192.168.8.255:0 ike 0:BOStoRIp1:2574:31191: mine: type=7/7, local=0:0.0.0.0-255.255.255.255:0, remote=0:0.0.0.0-255.255.255.255:0 ike 0:BOStoRIp1:2574:31191: no matching phase2 found ike 0:BOStoRIp1:2574:31191: failed to get responder proposal ike 0:BOStoRIp1:2574: error processing quick-mode message from 108.34.154.31 as responder ike 0:BOStoRIp1:BOStoRIp2: IPsec SA connect 3 1.1.1.1->x.x.x.x(DHCP):500 **this line shows actual IP addresses correctly** ike 0:BOStoRIp1: using existing connection, dpd_fail=0 ike 0:BOStoRIp1:BOStoRIp2: config found ike 0:BOStoRIp1:2573:BOStoRIp2:31188: quick-mode negotiation failed due to retry timeout Thank you in advance for any help you may provide. -Amor

    9 replies

    billp
    billp
    New Member
    April 28, 2011
    Many sysadmins on this forum recommend staying away from MR3 for now. There are many new features in MR3 that aren' t completely stable yet. It' s not recommended for production use until the next 1 or 2 patches. 4.0 MR2 P6 is the latest stable firmware. Might be worth a try to see if it affects your problem.
    Kenundrum
    Kenundrum
    New Member
    April 28, 2011
    I had similar problems with connecting to a linksys or netgear soho routers. It seemed in my case, specifying the source and destination addresses in the P2 on the FortiGate to the correct values- in your case i believe the source would be your local subnet of 192.168.1.0/24 and the destination would be 192.168.8.0/24 as the remote subnet. You may want to try that and see what happens.
    AmorFati7734
    AmorFati7734Author
    New Member
    April 28, 2011
    Thank you both for the replies. In regards to 4.0 MR3, besides downloading and putting on the MR2 firmware I' m guessing that would entail taking the entire system down and doing reconfigurations? I won' t be able to import a current MR3 config into the MR2 firmware, would I? Kenundrum: I did try that previously but I' m willing to give it a shot again. I' m pretty sure I did it backwards though. Thanks for the tip! It strikes me as odd that the tech support for FortiNet had me install the MR3 firmware as soon as I received my device when I was having other issues with the default image installed.
    romanr
    romanr
    New Member
    April 28, 2011
    ike 0:BOStoRIp1:2574:31191: peer: type=7/7, local=0:192.168.1.0-192.168.1.255:0, remote=0:192.168.8.0-192.168.8.255:0 ike 0:BOStoRIp1:2574:31191: mine: type=7/7, local=0:0.0.0.0-255.255.255.255:0, remote=0:0.0.0.0-255.255.255.255:0
    Hi, your problems are not related to MR2 or MR3... There are just wrong Phase 2 settings! These IP adresses have to match on both sides to establish a tunnel... I don' t know the D-Ling devices, but it seems you will have to use 192.168.x.0 as your Phase 2 selectors! best regards, roman
    billp
    billp
    New Member
    April 28, 2011
    Re: backreving to MR2, you' d need to restore the config from a previous backup or start from scratch. You might be able to use a text editor to cut and paste the various settings from one config file to another, but it require some judgement about what would work between firmware revs. Some might recommend a reformat of the firmware before going backwards. Officially, Fortinet probably considers MR3 to be a working, operational firmware. They are certainly promoting it as such. As I' ve posted earlier, I wonder if they are running it across all their own internal devices, though :) The practical experience of many of the sysadmins here doesn' t bear out that MR3 is ready for broad deployment. Some have reported reasonable success, though. I think it just depends on the features you need. My setup is not complex, but my users still want a completely stable system rather than new features. So, I' ll hold off until the next 1-2 patch cycles. . .and perhaps a long weekend. I realize this might not address your original problem, but hoped it would shed light on what appears to be conflicting advice from the forums and Fortinet.
    ede_pfau
    SuperUser
    ede_pfau
    SuperUser
    April 29, 2011
    As said before this is NOT a version issue. You have got the quick mode selectors mixed up - exchange source and destination. Check the router if you have the correct subnet specified behind the tunnel (if that is possible). IPSec VPN is not black magic / voodoo but you have to get some knowledge about the relevant parameters. I see that you even use the debug feature. Then I assume you have worked through the IPSec VPN chapter in the FortiOS Handbook as well. The role of the QM selectors is explained quite clearly and a lot of examples given which do work. Of course, the D-Link side might bear some undocumented restrictions (as experienced with Draytek routers myself). One of the reasons why I changed all SOHO locations to 1. a dumb modem in bridge mode plus 2. a small Fortigate. No more hassles and total control. One more caveat: while experimenting bear in mind that both devices must be ' clean' after you change anything in the parameters. That is, any SA must either time out or be torn down before trying to establish the tunnel. On a FGT the command ' diag vpn tun flush' will do that. No idea about the D-Link side.
    TopJimmy
    TopJimmy
    New Member
    May 2, 2011
    ORIGINAL: ede_pfau As said before this is NOT a version issue. You have got the quick mode selectors mixed up - exchange source and destination. Check the router if you have the correct subnet specified behind the tunnel (if that is possible). IPSec VPN is not black magic / voodoo but you have to get some knowledge about the relevant parameters. I see that you even use the debug feature. Then I assume you have worked through the IPSec VPN chapter in the FortiOS Handbook as well. The role of the QM selectors is explained quite clearly and a lot of examples given which do work. Of course, the D-Link side might bear some undocumented restrictions (as experienced with Draytek routers myself). One of the reasons why I changed all SOHO locations to 1. a dumb modem in bridge mode plus 2. a small Fortigate. No more hassles and total control. One more caveat: while experimenting bear in mind that both devices must be ' clean' after you change anything in the parameters. That is, any SA must either time out or be torn down before trying to establish the tunnel. On a FGT the command ' diag vpn tun flush' will do that. No idea about the D-Link side.
    +1 with what ede_pfau said. I beat my head against the wall trying to get our FGT' s to VPN with a Checkpoint unit. I was getting the same errors you are and it was because of the quick-mode selector. Checkpoint called them " encryption domains" and the admin on the other side had them set whereas my QM' s weren' t. Once we had them in tune with each other, and the previous tunnels were torn down, all was good.
    A
    Anonymous_User
    Contributor
    May 2, 2011
    You have to make sure you have exactly the same parameters in both devices. For example, I see at FG screenshots: - Phase 1: NAT-T enable, DPD enable - Phase 2: PFS disable (no DH) At the other device I see: - Phase1: NAT-T disable. Keep Alive/DPD: none - Phase2: PFS enable (DH=2) Try to start again and make all the parameters have the same value. Regards,
    AmorFati7734
    AmorFati7734Author
    New Member
    May 2, 2011
    Thanks everyone for the info. I will go ahead and give this a shot this weekend and let you know how it goes. Again, thanks for the load of info..very very helpful! -Amor
    AmorFati7734
    AmorFati7734Author
    New Member
    May 5, 2011
    Alright, I had some time today to set at this for a minute and actually got it to work. First, I removed the VPN entirely from the DLINK DIR-330 and let it reboot. I then removed the connection from the fortigate and run the command suggested by ede_pfau " diag vpn tun flush" . After, I went ahead and setup the connection again on the VPN and then went to the DLINK next. It' s now up and running. I guess I just needed to step away for a moment to take a look at it better. Thanks again everyone for your help! -Amor
    Terms & ConditionsAccessibility statement