- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-31-2023 08:34 AM
thanks @buffkata.
We have a quite few rules for the existing zone, so better get started then!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 ).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-31-2023 08:34 AM
thanks @buffkata.
We have a quite few rules for the existing zone, so better get started then!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-31-2023 08:43 AM
Hold on here
- if you have two internet links it is CORRECT to have them both in a single ZONE (OUTSIDE)
- FTD/FMC can use ZONEs for NAT rules but can also use INTERFACE GROUPS
- an INTERFACE GROUP breaks a tie in certain aspects of FMC/FTD configurations, like what you are experiencing
- You don't need to create an additional ZONE you just need to keep the same single ZONE for BOTH interfaces and instead create an Interface group for the interface you deem as "primary" and one for the "secondary"
- these INTERFACE GROUPS can be reused on ALL FTDs if you are using an FMC, rather than creating new groups for each new Firewall
- In your case you would apply specific interface NAT using the INTERFACE GROUP (primary or secondary) rather than referring the ZONE (that instead is ambiguous since it contains TWO interfaces)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-31-2023 10:49 AM
Thanks for clarifying my confusion, much appreciated!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-25-2023 08:19 AM
Forgot to say that this really helped and working as I hoped, thanks very much!
