VPN Tunnel going down

[qspec]

We have a VPN tunnel set up with another company. They have cisco we have a fortigate 80c. If nobody is actively using the tunnel, all the subnets will go down and I cannot activate them from my side. We have to email their tech and he pings our machine from each subnet and that brings the individual subnets back up. Since I cannot bring the tunnel up from my side, I feel like this is a problem with their config, am I wrong on this? Any suggestions on what the problem could be?

[ede_pfau]

hello, and welcome to the forums. No, this is intended behavior: site-to-site VPN tunnels to a different vendor' s gateway will only function with manually opening the tunnels from their side. This is to ensure a close contact and more communication. Just kidding. Please have a look at your phase2 configuration. The Quick Mode selectors (a.k.a. proxy settings) must match the remote subnets behind the Cisco. You can use the wildcard ' 0.0.0.0/0' for site-2-site VPNs to another Fortigate but not with other vendors. The QM selectors filter traffic to only trigger the tunnel setup when intended traffic arrives. Secondly, they are a part of the phase2 negotiations and thus relevant. Could you give us some more infos on the type of VPN (aggressive, main mode) and if it is a ' dial-in' type or a plain ' site-to-site' setup? The latter requires static gateway public IP addresses on both sides.

[qspec]

main mode VPN and it' s site to site. correct me if I am wrong, but I would assume the subnets are correct in phase2 because the tunnel will go up, it just goes down when not being used.

[ede_pfau]

The tunnel might go up with traffic from the Cisco side. This doesn' t say anything about the FGT configuration being correct. Tunnel going down after an idle period can be prevented by the ' auto-key' option. There are 2 places, one for phase1 and one for phase2. And there is another one IIRC in ' conf sys global' .

[qspec]

I have the auto key turned on, but it is kind of pointless as my side cannot bring the tunnel up. Do you know what that option is called in a cisco router?

[ede_pfau]

Ask emnoc, he' s Cisco savvy.

[nitesh_saxena]

Hi 

Did anyone got a solution for this issue?

I am having the same issue also.

[siliconkid]

Ask them to check the order of their crypto MAP entries. Ask them to make sure their Dynamic MAP (Remote accesss VPN map) if they have one is at the end or at least get them to move yours at the top of the list. Like here the number 51 is a MAP which will be processed before MAP 60 :

crypto map EXAMPLE 51 match address vpn_ACLcrypto map EXAMPLE 51 set connection-type bi-directionalcrypto map EXAMPLE 51 set peer xxx.xxx.xxx.xxx crypto map EXAMPLE 51 set ikev1 phase1-mode maincrypto map EXAMPLE 51 set ikev1 transform-set aesshano crypto map EXAMPLE 51 set tfc-packetscrypto map EXAMPLE 60 match address vpn_ACL-IIcrypto map EXAMPLE 60 set connection-type bi-directionalcrypto map EXAMPLE 60 set peer yyy.yyy.yyy.yyy crypto map EXAMPLE 60 set ikev1 phase1-mode maincrypto map EXAMPLE 60 set ikev1 transform-set shastrongno crypto map EXAMPLE 60 set tfc-packets  Also ask them to make sure the connection-type is bi-directional. They might have to use "show run all" command. 

[rwpatterson]

In a nutshell, the user with the more concise phase2 subnets will be able to open the tunnel. If the FGT has all zeros for phase2 and the Cisco has 192.168.x.x, then 192.168.x.x is contained within 0.0.0.0 and thus will be able to open the tunnel. This is why both sides should match exactly. Now I have seen examples (I am working on one between a FGT60B and my FWF80CM) where the phase2s match and one side cannot bring the tunnel up, but that isn't the normal behavior.

In addition, the setting that keeps the tunnel up is 'set auto-negotiate [enable | DISABLE]'. (Disable is the default) I'm not sure that would work if the FGT is unable to bring the tunnel up from a down state.