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

[Guizado]

Yeah I thought about that copying all the rules deleting them and creating zones and pasting the rules back in the cli, I already automated around 100 services, addresses etc from another Fortigate.

I am a cli guy myself when it comes to everything Cisco, but I doubt that the zones would help me alot here, because I would still need Firewall rules between interfaces on the same zone, I guess at the end of the day it doesnt really matter, I could say from zone dmz to zone dmz, because the important stuff is the source and destination addresses, intra and inter traffic would not be allowed, my example is abit like each Interface is its own zone.

I have a Outside(Internet), Transit(Inside) and then around 10 or more DMZs that cannot have access between each other, but then I have a mirror on a different Datacentre and each DMZ has access to its own mirror DMZ on the other Datacentre as they are both Active/Active DCs.

Well thanks for all your help, appreciated.