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
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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
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
emnoc wrote: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.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
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
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
PCNSE
NSE
StrongSwan
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
PCNSE
NSE
StrongSwan
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
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
emnoc wrote: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.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
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
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
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
PCNSE
NSE
StrongSwan
You should seriously upgrade that unit ;)
Ken
PCNSE
NSE
StrongSwan
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
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
PCNSE
NSE
StrongSwan
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1645 | |
1070 | |
751 | |
443 | |
210 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.