IPSec VPN with multiple remote peers (Dynamic peers) not working

[sandeep_fgt]

Hi Friends,

I am setting up a new  Site to site VPNs from my Fortigate 1500D (kind of hub having static WAN IP) to Cisco routers at spoke sites (Dynamic WAN IP from PPPoE). The Fortigate is running latest FortiOS 5.2.4.

So basically the setup is as below

Remote protected subnet 10.10.10.0/24<---Cisco Router A  (Dynamic WAN IP ) <---INTERNET---> Static Fortigate WAN IP ( 20.0.0.5) --->protected subnet 10.1.1.8/30

Remote protected subnet 10.10.20.0/24<---Cisco Router B  (Dynamic WAN IP ) <---INTERNET---> Static Fortigate WAN IP ( 20.0.0.5) --->protected subnet 10.1.1.8/30

Remote protected subnet 10.10.30.0/24<---Cisco Router C  (Dynamic WAN IP ) <---INTERNET---> Static Fortigate WAN IP ( 20.0.0.5) --->protected subnet 10.1.1.8/30

Since this is a migration, we are creating parallel tunnels on Cisco Router to new fortigate 1500D. The Cisco routers already have tunnels to another hub cisco router at other site with another WAN peer GW.

Phase-1 is using dial up at FG with aggressive mode

Now, the problem is when I initiate the interesting traffic from first site, the tunnel gets established just fine. But when I try to initiate the traffic from another site(s) the Fortigate again tries to match the parameter for the first tunnel which is already established. Since the phase-1 is defined to accept connection from any peer ID (since the remote cisco end is dynamic) it appears that its again trying to negotiate the connection from the first tunnel. I tried setting up Cisco router with the Identity using phase-1 CLI

crypto isakmp identity (address|hostname)  (actually tried both the available option and defined the  phase1 in Fortigate for the hostname of remote end but it still dont brings resolution)

The Fortigate configuration for the mentioned tunnels are -

config vpn ipsec phase1-interface     edit VPN-A         set type dynamic         set interface "port17"         set mode aggressive         set proposal 3des-sha1         set dhgrp 2         set psksecret abcd1234     next     edit VPN-B         set type dynamic         set interface "port17"         set mode aggressive         set proposal 3des-sha1         set dhgrp 2         set psksecret abcd1234     next     edit VPN-C         set type dynamic         set interface "port17"         set mode aggressive         set proposal 3des-sha1         set dhgrp 2         set psksecret defg1234     next     edit VPN-D         set type dynamic         set interface "port17"         set mode aggressive         set proposal 3des-sha1         set dhgrp 2         set psksecret cdefr254     next config vpn ipsec phase2-interface     edit VPN-A         set phase1name VPN-A         set pfs disable         set keylifeseconds 3600         set src-subnet 10.1.1.8 255.255.255.252         set dst-subnet 10.10.10.0 255.255.255.0     next     edit VPN-B         set phase1name VPN-B         set proposal 3des-sha1         set pfs disable         set keylifeseconds 3600         set src-subnet 10.1.1.8 255.255.255.252         set dst-subnet 10.10.20.0 255.255.255.0     next     edit VPN-C         set phase1name VPN-C         set proposal 3des-sha1         set pfs disable         set keylifeseconds 3600         set src-subnet 10.1.1.8 255.255.255.252         set dst-subnet 10.10.30.0 255.255.255.0     next     edit VPN-D         set phase1name VPN-D         set proposal 3des-sha1         set pfs disable         set keylifeseconds 3600         set src-subnet 10.1.1.8 255.255.255.252         set dst-subnet 10.10.40.0 255.255.255.0     next

I have policies for each of these tunnels.

Please provide your suggestions if you experienced this and was able to figure out the solution in the scenario. I had engaged the Fortinet TAC but they are putting this on Cisco to setup unique identity and distinguish the connections.

Thanks in advance!

Regards,

Sandeep Jha

[ede_pfau]

TAC is right. You need to have unique identifiers to allow multiple tunnels. As the remote sites have dynamic WAN IPs you cannot use their WAN addresses. So you chose a dial-up VPN which is correct. In order for the central FGT to discriminate the remote peers you need to supply unique peer identifiers (peer IDs) for each remote gateway. This can be any string, like a hostname or a geographic location.

On the central FGT, do NOT allow "accept any peer"! If you do, there can only be one tunnel active. You need the peer ID here to let the FGT choose the right phase 1 configuration to be able to create multiple tunnels.

There are several ways to configure the peer ID management on the central site:

- you can create multiple phase1's

- you create one phase1 which uses peer IDs from a peer group

I recommend the latter (peer group) because it's easy to maintain. For each remote site, create a local user. User's name is the peer ID, user's password is the remote site's PSK.

You can find detailed examples of this either in the Handbook or the Cookbook.

IF "tl;dr":

[ul]

central FGT needs to identify remote peers

use unique peer IDs for this

maintain peer ID on central FGT using local user group[/ul]