Aggregate Interfaces and IPV4 Policy

Guizado · ‎05-08-2017

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 · ‎05-08-2017

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...

CISSP, NSE4

View solution in original post

emnoc · ‎05-08-2017

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

PCNSE

NSE

StrongSwan

View solution in original post

rwpatterson · ‎05-08-2017

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

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

View solution in original post

emnoc · ‎05-08-2017

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"

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

PCNSE

NSE

StrongSwan

View solution in original post

emnoc · ‎05-08-2017

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"

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 "

FGTWXNOLA (root) #

config system zone

edit "ZONA1"

unset interface port1"

end

FGTWXNOLA (root) # show system zone ZONA1

config system zone

edit "ZONA1"

That would be how I would approach it.

Ken

PCNSE

NSE

StrongSwan

View solution in original post

Guizado · ‎05-09-2017

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.