Aggregate Interfaces and IPV4 Policy

[Guizado]

Hello everyone, just want to clear a small doubet that I could not find anywhere.

Lets say I create an aggregate interface and have 10 Vlan interfaces under that aggregate interface.

When on the IPV4 policy if I select the Source or Destination interface as the aggregate interface that is a shortcut to selecting all the VLAN interfaces under that aggregate, correct?

Many Thanks

[Kenundrum · Accepted solution]

No- that is a way to send traffic without VLAN tags out the aggregate interface. The switch would then decide what the default vlan for untagged traffic is on those ports and forward appropriately.

A zone containing all the VLAN interfaces would possibly do what you want. It would prevent you from having to create multiple repetitive rules for traffic from each VLAN to another interface such as VLAN2->WAN1, VLAN3->WAN1, etc...

[emnoc · Accepted solution]

It's not that easy. I don't even think you can even do that btw? What fortiOS version are you seeing a aggregate  as a destination interface ?

Now if you had a aggregate   called 

edit LAG1

    set vdom root

    set ip 1.1.1.1/30 

   edit

That would be just a ipv4 interface under the LAG bundle and  has noting todo with the sub-interfaces.

Also keep in mind, " if you had  aggregate with  10 sub-interface but all of them  NOT in the same vdom, what would happen with the logic ? "

If you want to simplify  fwpolicy to cover all 10 sub-interfaces, than you need to look at "zones" but once you go zones, you are zones and policies can NOT be applied directly to a member that's part of a zone

Ken

[rwpatterson · Accepted solution]

emnoc wrote:

If you want to simplify  fwpolicy to cover all 10 sub-interfaces, than you need to look at "zones" but once you go zones, you are zones and policies can NOT be applied directly to a member that's part of a zone

Ken

Not so sure about that. When you place interfaces (VLANs are considered interfaces, BTW) into zones, you can still administer them on a one by one basis. To be able to place them under one policy, put their members into an address group. The zone makes it easier to manage, and you can share traffic between members with the check box option as well as policies.

I have a 'vendor' zone and in there I place all the VPN tunnels for my vendors. I still create policies for them on a case by case basis, but it just makes it easier for me to find them in the large scheme of things. If I want all of the vendors in that zone to have the same access to a destination, I would put them into an address group and place that group into a policy.

My two cents

[emnoc · Accepted solution]

What vFortiOS ? And are you sure we are not talking about intrazone?

Here's what happens when you place interfaces ( physical vlan loopback tunnels  ) in a zone and then try to call that interface directly in a fwpolicy.

e.g 

port34 is a member of ZONE that's named TEST

config system zone

    edit "TEST"

        set interface "port34"

    next

end

fwpolicy with the zone as a destination works  as expected ;

config firewall policy

    edit 14

        set uuid 81e68de6-3406-51e7-dbf9-40ae906ccfff

        set srcintf "wan1"

        set dstintf "TEST"  

        set srcaddr "all"

        set dstaddr "all"

        set action accept

        set schedule "always"

        set service "ALL"

    next

end

Now if you tried to add a uniq fwpolicy with port34 as a src or dat interface  it will fail.

NYCFW01WET60HUD (root) # config firewall policy

NYCFW01WET60HUD (policy) # clone 14 to 999

NYCFW01WET60HUD (policy) # edit 999  

NYCFW01WET60HUD (999) # set dstintf port34

node_check_object fail! for name port34

value parse error before 'port34'

Command fail. Return code -6

Zones are good but typically they are deployed for the wrong reasons and the gotchas are not recognized by the fw-engineer   imho

Ken

[Kenundrum · Accepted solution]

No- that is a way to send traffic without VLAN tags out the aggregate interface. The switch would then decide what the default vlan for untagged traffic is on those ports and forward appropriately.

A zone containing all the VLAN interfaces would possibly do what you want. It would prevent you from having to create multiple repetitive rules for traffic from each VLAN to another interface such as VLAN2->WAN1, VLAN3->WAN1, etc...

[emnoc · Accepted solution]

It's not that easy. I don't even think you can even do that btw? What fortiOS version are you seeing a aggregate  as a destination interface ?

Now if you had a aggregate   called 

edit LAG1

    set vdom root

    set ip 1.1.1.1/30 

   edit

That would be just a ipv4 interface under the LAG bundle and  has noting todo with the sub-interfaces.

Also keep in mind, " if you had  aggregate with  10 sub-interface but all of them  NOT in the same vdom, what would happen with the logic ? "

If you want to simplify  fwpolicy to cover all 10 sub-interfaces, than you need to look at "zones" but once you go zones, you are zones and policies can NOT be applied directly to a member that's part of a zone

Ken

[rwpatterson · Accepted solution]

emnoc wrote:

If you want to simplify  fwpolicy to cover all 10 sub-interfaces, than you need to look at "zones" but once you go zones, you are zones and policies can NOT be applied directly to a member that's part of a zone

Ken

Not so sure about that. When you place interfaces (VLANs are considered interfaces, BTW) into zones, you can still administer them on a one by one basis. To be able to place them under one policy, put their members into an address group. The zone makes it easier to manage, and you can share traffic between members with the check box option as well as policies.

I have a 'vendor' zone and in there I place all the VPN tunnels for my vendors. I still create policies for them on a case by case basis, but it just makes it easier for me to find them in the large scheme of things. If I want all of the vendors in that zone to have the same access to a destination, I would put them into an address group and place that group into a policy.

My two cents

[Guizado]

That is weird, didnt expect this, as when I create a new policy rule I can select that Interface as source or destination, being a physical interface I expected it to include all its sub-interfaces (Vlans), either that or it should not be selectable, ohh well I think I will just select all 10 sub-interfaces instead of the physical lag.

Many Thanks 

[emnoc · Accepted solution]

What vFortiOS ? And are you sure we are not talking about intrazone?

Here's what happens when you place interfaces ( physical vlan loopback tunnels  ) in a zone and then try to call that interface directly in a fwpolicy.

e.g 

port34 is a member of ZONE that's named TEST

config system zone

    edit "TEST"

        set interface "port34"

    next

end

fwpolicy with the zone as a destination works  as expected ;

config firewall policy

    edit 14

        set uuid 81e68de6-3406-51e7-dbf9-40ae906ccfff

        set srcintf "wan1"

        set dstintf "TEST"  

        set srcaddr "all"

        set dstaddr "all"

        set action accept

        set schedule "always"

        set service "ALL"

    next

end

Now if you tried to add a uniq fwpolicy with port34 as a src or dat interface  it will fail.

NYCFW01WET60HUD (root) # config firewall policy

NYCFW01WET60HUD (policy) # clone 14 to 999

NYCFW01WET60HUD (policy) # edit 999  

NYCFW01WET60HUD (999) # set dstintf port34

node_check_object fail! for name port34

value parse error before 'port34'

Command fail. Return code -6

Zones are good but typically they are deployed for the wrong reasons and the gotchas are not recognized by the fw-engineer   imho

Ken

[Guizado]

Hello,

here is all the information on this screenshot:

[emnoc]

You should  seriously upgrade that unit ;)

Ken 

[Guizado]

Haha yes indeed, upgrade has been scheduled, I am a contractor at where I am at now, and my background is loads of Cisco, Checkpoint and Palo Alto, not much exposure to Fortigates units until now, I am migrating some old DMZ Firewalls into the Fortigate, and this VDOM I created will be hosting it, the aggregate port is a 4 port VPC into a Nexus 5k.

Going back on track, then I assume I cant use the aggregate port as I thought I would be able to?

I tried going into the zones but it seems I cant create any as I already have around 80 Policy rules created that I had to manually import from the old Firewalls that are using all ports, so the fortigate menu said no interfaces are eligible for zones, plus zones are not very applicable to what we want to do here, its just a bunch of DMZ Sub-ifs a Transit Sub-If going into our core switches and an outside connection.

No big deal I will just specify all the interfaces one by one for each rule I have.

Many Thanks

[emnoc · Accepted solution]

Yes that's another gotcha, any interface bound with policies CAN NOT be added to a system zone. When going zones,  it's petty straightforward but you have to have a design set in place b4 building.

My  strong experience is w/juniperSRX and ASA  and to a less degree PaloAlto and all 3  of these are ZB-FW to  some degree  with cisco calling a zone a interface name.

I found people that are  SRX or PaloAlto engineers , seems to implement ZB firewall concepts with great success.

e.g

ZONE_NAMEs   ==  LAN1 LAN2 LAN3  DMZ1 ENTRUST

They do much better at zone implementation on a  Fortigate Firewall.

Now back to the sub-interface and group, you can do what I've done  in the past if you you like the cli ( I'm a cli guru ;) )

1> have a fwpolicy that's de-activate that you clone for future, just clone from that fwpolicy and modify the  SRC/DST-addres  &  SERVICE/etc....

This keeps you from having to plug in  X amount of interfaces  everytime you add fwpolices for that group of interfaces. Always clone from that same fwpolicy-id overtime  you need to reference the same group of interfaces.

2> this is NOT a zone configuration concept, but just a simple means to  rapidly deploying repetitious policies that have the same  dst_interfaces.

3> keep in mind other gotchas, once you apply a "interface" into a zone it can not be part of another zone. That should be obvious but a lot of security_engineers try to  use interface across zones & that will not work.

4> if you need a zone for the 10+ sub-interface in your example, you could  easily script this and by copying all policies down and the craft the new zone with no interfaces & upload this thru the webgui script execution

Than you delete all old fwpolicies and recreate them  with the INTERFACE &  now the zone name and b4 you copy back in the policies you have to add  the interface to the ZONE

e.g

config system zone

         edit "ZONA1_LAG_MEMBERS"

        set interface "some dummy interface name"

    next

end

config firewall policy 

   ( paste in the  policies  referencing from the earlier)

end

Now unbind the fwpolicy per interface add apply the interface to the ZONE

NOTE: you can't apply fwpolicy with a empty zone interfaces, but you can craft a zone with no interfaces defined.

Also you can craft a fwpolicy with a dummy interface in the "ZONE" and then replace it with the sub.interfaces after you unbind the old fwpolicies 

This is strange behavior but  FortiOS allows a policy that references  a  system zone and later you  remove the interface  the fwpolicy will stay  in the cfg  

e.g

config firewall policy

    edit 18929

        set uuid 6fd5305c-3425-51e7-0187-9624f16cbd52

        set srcintf "port1"

        set dstintf "ZONA1"

        set srcaddr "all"

        set dstaddr "all"

        set action accept

        set schedule "always"

        set service "ALL"

        set comment " empty zone no members interfaces "

    next

end

FGTWXNOLA (root) #

config system zone

    edit "ZONA1"

             unset interface port1"

 end

FGTWXNOLA (root) # show system  zone ZONA1 

config system zone

    edit "ZONA1"

    next

end

That would be how I would approach it.

Ken