Installing Policy Package - interface binding contradiction

So I narrowed it down a bit to find that from VPN to internal and from DMZ to internal is failing validation. Any thoughts? --Thomas P

Are you using the " Install On" column appropriately? Do all your firewalls have zones " DMZ" " VPN" and " Internal" zones mapped? I suspect you have multiple firewalls and perhaps not all of them have all zones mapped. If those policies don' t apply to all firewalls then narrow it down using the Install On column appropriately. If it does apply, go to Dev Mgr and look under Network -> zone mapping for each one. Check the box to see unmapped interfaces if you need and then ensure that those three zones are accounted for on all firewalls.

Hi Sean, thanks for replying. The the policy is only assigned to one firewall at the moment for testing purposes. So when I select " Install On" the one device shows up. I have a VPN zone that is mapped properly according to the Dev Mgr and the policy is from VPN to Internal. The policy entails an address group (with address objects that are set to " any" interface) as the source and a Dynamic Object (set to " internal" interface) as the destination but it could not validate. Is this policy sound and does it matter that the address objects in the group are set to " any" ? I am going to try and change the address objects to the " VPN" interface to see if that makes a difference. Please let me know your thoughts. --Thomas P

Thomas, I have never had any validation problems as a result of what interface an object is tagged on. In my experience that comes into play when you write the policy in the first place.. if an object is set to Any you can select it when you choose any of the interfaces but if you set an object to VPN interface only, it is selectable only when you choose the VPN interface when writing the policy, so it' s something else I' d wager. Now I never use dynamic objects, as personally I' ve never found a good reason to use them, but that could just be with my policy. I always setup IPsec tunnel as interface mode, and then name phase 1 as VPN_to_Whatever and then I setup a global zone as VPN_to_Whatever and go to device manager and map the VPN tunnel Phase 1 to the global zone. Then I go to policy and write rules Internal --> VPN_to_WhatEver and vice versa. Have never had a problem with validation unless I didn' t map a zone. Try not using dynamic object, just use an object you create under Policy tab. Make sure you have all zones mapped properly. If you are setting up your VPN differently than interface mode you' re on your own :) But if you are set in interface mode then it is fairly straightforward.

Hmmmm...Well the need for Dynamic Objects is there due to the fact that this policy will be installed on a large amount of units, when working of course :). Each unit has the same address object but with different IP' s, hence the need for the dynamic object. The issue is with the DO i believe because it does validate and install when using a standard object with a definitive IP address. For example....I have unit, let' s just call it UnitA, with an address object called FrontPC with IP address 10.128.254.2. I also have a unit, UnitB, with the same address object, FrontPC, with IP address 10.128.253.2. Both will have Identical policies hence using the FGFM. If I define FrontPC in the FortiManger as 10.128.254.2, it would only be correct and usable for UnitA and not UnitB which means I need to map FrontPC on the FGFM as a DO on both units correct? If the problem with the policy on FGFM is with the DO, how can I fix that or am I doing something wrong with the mapping? Sorry if this is a bit confusing. The DO works when the policy is Internal to Anything (VPN, WAN1, DMZ) but not when the destination is Internal. That' s when I get the " interface binding contradiction" . Maybe it is just a FGFM firmware issue? :) --Thomas P

Well I can' t really comment on the DO aspect as I don' t use them... are the DO' s bound to interfaces? Your examples gave me an idea though.. if your IP space is fairly contiguous - meaning that FrontPC is 10.128.100.2 at SiteA, 10.128.101.2 at SiteB, so on and so forth, you could write a single object with IP of 10.128.[100-254].2 and this would take care of the rule. You avoid DO entirely with this method..so long as that works. Or if you have maybe 100 sites or less and know the IP' s already, you can script the creation of the objects and just add them to a group and use that in the rulebase. That would probably take an hour or two but if you consider how much time you' ve spent trying to get DO to work - I' d personally rather just make it work and move on with life :) As far as FGFM issues, first try it on FGT itself. If it works great but then you try on FMGR and it craps itself, then you have a good case for either a bug or a FGFM incompatibility. I' m running bleeding edge FGT 4.3.7 FMGR 4.3.5 (which I don' t recommend for FMGR).