cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2069
Views
4
Helpful
7
Replies

Interface/Security Zone mapping and NAT question

atsukane
Level 1
Level 1

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:

atsukane_0-1693478227365.png

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,

 

2 Accepted Solutions

Accepted Solutions

thanks @buffkata

We have a quite few rules for the existing zone, so better get started then!

View solution in original post

 

 


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)

View solution in original post

7 Replies 7

buffkata
Level 1
Level 1

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

thanks @buffkata

We have a quite few rules for the existing zone, so better get started then!

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) 

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!

 

 

 


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)

Thanks for clarifying my confusion, much appreciated!

Forgot to say that this really helped and working as I hoped, thanks very much!

Review Cisco Networking for a $25 gift card