I give up...IPSEC VPN

[AmorFati7734]

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

[billp]

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]

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]

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]

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]

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]

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]

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.

[#9]

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]

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