08-31-2023 03:51 AM - edited 08-31-2023 03:52 AM
Hi All,
We've recently provisioned secondary Internet circuit which is connected to an interface on a FMC managed FTD2140 HA pair, running v7.2.4.
I was hoping to assign the existing ISP1_OUTSIDE Security Zone to the new interface so there's no need to update ACP.
However due to the object/Auto NAT rules, this seems to be impossible to do and FMC throws an error:
Previously I was under the impression that "Source Interface" in the NAT rule actually meant source "INTERFACE", but it looks more like source "ZONE", and the only option seems to me is to create a new zone, map it to the new ISP2 interface, and include the new zone in the relevant rules on ACP.
Is my understanding correct, and there's no other way?
Please advise.
Many thanks in advance,
Solved! Go to Solution.
08-31-2023 08:34 AM
thanks @buffkata.
We have a quite few rules for the existing zone, so better get started then!
08-31-2023 09:54 AM - edited 08-31-2023 09:56 AM
Can I just to clarify, as I could not get my head around the difference between IG and Zone in the past, you are suggesting that I'd create a new IG consisting of two interfaces, e.g. ISP1 and ISP2.
In your case you should have two interface groups, each containing one of the Internet interfaces.
And for the auto NAT rules, I'd updated the source interface from the existing "Zone" to the newly created IG.
Yes
My understanding for the IG is, now based on your description, make the source a bit ambiguous and doesn't matter which interfaces the traffic originates from, as long as it is in the IG used in the rule.
An Interface Group is used to remove ambiguity that Zones instead could bring
A ZBF by definition can aggregate more interfaces under the same ZONE (and in many cases you should) if they have the same function and security level but as you experienced you need an "object" to put in an FMC/FTD to describe how the NAT should work and a ZONE with two interfaces cannot do it (as it is ambiguous) so you need an INTERFACE GROUP where for that specific device contains one physical interface only, so your NAT rule can be not ambiguous
An Interface Group can contain more than one interface but it helps you only if you consider multiple firewalls, it has the same logic of network objects with the override option where you have a value for a network object for each specific firewall but the object itself has the same reference/name across all firewalls. This can help you avoid creating too many objects for the same function and template certain policies (if I am not mistaken also NAT policies can leverage inheritance so you could template this for the future, making sure that all your primary interfaces on each of your firewalls are on the primary interface group). So you could have for each single Firewall only ONE interface on each group but the group itself would contain interfaces for all firewalls (either primary or secondary, depending on which group you created)
The benefit from all of this is that you can create your ACP policies targeting your ZONES (as you CANNOT target Interface groups in ACPs!) and keep logical consistence on your security rules while instead use the INTERFACE GROUPS where picking the right physical interface is relevant (NAT for example)
08-31-2023 08:12 AM
You are correct - that is a Zone and not an interface. You will need to create a new zone. If you manage more then a few FTDs you can place their OUTSIDE Interfaces all in the OUTSIDE Zone ...but your new interface here serves a different purpose.
It was confusing to me too when I encountered it - but I did create a new Zone and used it on the new interface (in my case DMZ-2 ).
08-31-2023 08:34 AM
thanks @buffkata.
We have a quite few rules for the existing zone, so better get started then!
08-31-2023 08:43 AM
Hold on here
08-31-2023 09:32 AM
Thanks @giovanni.augusto
Can I just to clarify, as I could not get my head around the difference between IG and Zone in the past, you are suggesting that I'd create a new IG consisting of two interfaces, e.g. ISP1 and ISP2.
And for the auto NAT rules, I'd updated the source interface from the existing "Zone" to the newly created IG.
My understanding for the IG is, now based on your description, make the source a bit ambiguous and doesn't matter which interfaces the traffic originates from, as long as it is in the IG used in the rule.
Correct?
If that's the case the ACP can stay as is, which is the best part
Thanks!
08-31-2023 09:54 AM - edited 08-31-2023 09:56 AM
Can I just to clarify, as I could not get my head around the difference between IG and Zone in the past, you are suggesting that I'd create a new IG consisting of two interfaces, e.g. ISP1 and ISP2.
In your case you should have two interface groups, each containing one of the Internet interfaces.
And for the auto NAT rules, I'd updated the source interface from the existing "Zone" to the newly created IG.
Yes
My understanding for the IG is, now based on your description, make the source a bit ambiguous and doesn't matter which interfaces the traffic originates from, as long as it is in the IG used in the rule.
An Interface Group is used to remove ambiguity that Zones instead could bring
A ZBF by definition can aggregate more interfaces under the same ZONE (and in many cases you should) if they have the same function and security level but as you experienced you need an "object" to put in an FMC/FTD to describe how the NAT should work and a ZONE with two interfaces cannot do it (as it is ambiguous) so you need an INTERFACE GROUP where for that specific device contains one physical interface only, so your NAT rule can be not ambiguous
An Interface Group can contain more than one interface but it helps you only if you consider multiple firewalls, it has the same logic of network objects with the override option where you have a value for a network object for each specific firewall but the object itself has the same reference/name across all firewalls. This can help you avoid creating too many objects for the same function and template certain policies (if I am not mistaken also NAT policies can leverage inheritance so you could template this for the future, making sure that all your primary interfaces on each of your firewalls are on the primary interface group). So you could have for each single Firewall only ONE interface on each group but the group itself would contain interfaces for all firewalls (either primary or secondary, depending on which group you created)
The benefit from all of this is that you can create your ACP policies targeting your ZONES (as you CANNOT target Interface groups in ACPs!) and keep logical consistence on your security rules while instead use the INTERFACE GROUPS where picking the right physical interface is relevant (NAT for example)
08-31-2023 10:49 AM
Thanks for clarifying my confusion, much appreciated!
10-25-2023 08:19 AM
Forgot to say that this really helped and working as I hoped, thanks very much!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide