Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
MBR
New Contributor III

Policy Based VPN' s not workinf in FortiOS 5.2

Hi all, Anyone else having problems with policy based VPN firewall policies not working after upgrading to FortiOS 5.2? My firewall policies using the new ' IPSEC" action are completely ignored. When i change the action to Accept or Deny the firewall policy is enumerated and working correctly Changing back to IPSEC and it' s completely ignored again and a firewall policy lower in the chain is hit. Best Regards, MBR

- MBR -

NSE1, NSE2, NSE3

FGT60D/E, FWF60D/E, FGT200D

- MBR - NSE1, NSE2, NSE3 FGT60D/E, FWF60D/E, FGT200D
11 REPLIES 11
rwpatterson
Valued Contributor III

Welcome to the forums. Now would be a good time to convert all those older ' legacy' style tunnels. I know, not your answer, but a decent one time solution...

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com

Bob - self proclaimed posting junkie!See my Fortigate related scripts at: http://fortigate.camerabob.com
Dipen
New Contributor III

Agree with rwpatterson, as recommended by fortinet it is time to say goodbye to policy based IPSEC VPNs and go for default interface based IPSEC VPN. Also apart from switching from action from " Accept" to " IPSEC" are you changing the Interfaces in the Policies. In Interface-based VPNs you have to choose logical VPN Interfaces but in Policy-based VPNs you have to choose Physical interfaces Only. One more question Is this a fresh install or an Upgrade ?

Ahead of the Threat. FCNSA v5 / FCNSP v5

Fortigate 1000C / 1000D / 1500D

 

Ahead of the Threat. FCNSA v5 / FCNSP v5 Fortigate 1000C / 1000D / 1500D
MBR
New Contributor III

I know route based vpn' s are preferred but i some cases i need a policy based vpn. I' m using the correct physical interface (wan1) for the firewall policy. Odd thing is the policy is completely ignored when using action=ipsec. When i change action of the policy to Accept or Deny the policy is being applied on the traffic. When changing back to ipsec it' s completely ignored again :(

- MBR -

NSE1, NSE2, NSE3

FGT60D/E, FWF60D/E, FGT200D

- MBR - NSE1, NSE2, NSE3 FGT60D/E, FWF60D/E, FGT200D
emnoc
Esteemed Contributor III

I know route based vpn' s are preferred but i some cases i need a policy based vpn.
Why do you think you need policy based? Route-based is so much better and easier to diagnosed and I never had a instance where route-based would not work. I mean vpns to openswan, asa,fortigates,checkpoints , halon or juniper. I don' t think I ever had a route-based NOT work. Just something to think about. Back to your dilemma, what does the diagnostic output show when it fails; e.g diag debug flow for starters That might give you some clues as to what happening. Also ensure your fwpolicies ordering is correct. I wasted 2 hours of my time trying to gain access to a vendor remote fortigate, just to find out a policy was trumping his ipsec-policy. We still billed him out for 4 hours. fwiw: policy based vpn are way more harder to t-shoot imho

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
ede_pfau
SuperUser
SuperUser

You' d need policy based VPN if terminating on a FGT in Transparent mode. But agreed, route-based is the way to go. If you reconfigure using the config file you would even not need to know the PSKs. Shouldn' t be too hard to do.
Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
emnoc
Esteemed Contributor III

And l2tp over ipsec So unless he not doing one of those 2 requirements, he would be better off with routed-based, & once again imho

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
MBR
New Contributor III

if you have some customers with hosted VM' s which need IP connectivity to own offices using overlapping subnets you dont need to do NAT or renumbering when using policy based VPN' s.

- MBR -

NSE1, NSE2, NSE3

FGT60D/E, FWF60D/E, FGT200D

- MBR - NSE1, NSE2, NSE3 FGT60D/E, FWF60D/E, FGT200D
emnoc
Esteemed Contributor III

Okay fair, keep in mind tho that fortinet own recommendations are to shy away from PB-vpns and too use RT-vpn as much as possible.

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
MBR
New Contributor III

after a long troubleshooting session with fortinet support we found the issue. It' s an undocumented squirk in the firewall policy. When you create the ipsec firewall policy using the " insert policy above" or " insert policy below" function the firewall policy is created with an " outbound = disabled" setting. When you create a firewall policy with the " Create new" button the polcy is created with an " outbound = enabled" setting?!?! When you change the outbound setting to enabled the vpn policy works. This behaviour is very odd in my opinion cause the inbound and outbound settings are used to define if inbound and/or outbound may initiate a vpn tunnel. In my opinion the vpn traffic should also work when the remote side initiates the tunnel or when you manually bring up the vpn. For now i will define this issue as a flaw in the current FortiOS software. I wish i could get in contact of a developer of FortiOS to discuss this issue. Hope this information helps others having similar troubles. MBR.

- MBR -

NSE1, NSE2, NSE3

FGT60D/E, FWF60D/E, FGT200D

- MBR - NSE1, NSE2, NSE3 FGT60D/E, FWF60D/E, FGT200D
Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors