Anti-Spoofing on Interfaces which have not been updated / configured on SmartDashboard

[Linus_Espach]

Hey CP-Team

I have the case, that there is a Cluster which many (Virtual) Interfaces which was not updated in SmartDashboard for long time. So I was wondering about 2 things:

• If the Interfaces are created on CLI only, but not yet read in on SmartDashboard, is Anti-Spoofing performed on them based on any default values?
• What trouble could I ran into, updating all these Interfaces with <Get Interfaces with Topology> considering, the  static routes are configured correctly on the Gateway?

Thanks and best regards

[PhoneBoy]

I believe by default, anti-spoofing is NOT performed on interfaces not defined in the topology.
However, depending on what the existing definitions are for the other interfaces, you might start seeing anti-spoofing drops on other interfaces.
Assuming all the static routes are configured correctly, when you do "Get Interfaces with Topology" everything should get defined correctly.
However, in some cases, this MIGHT create a couple of hidden objects.
See this thread for more details: https://community.checkpoint.com/t5/General-Topics/Discovering-changes-in-topology-table/m-p/27770

[Maarten_Sjouw]

Also before you do a get interfaces with topology, make a screenshot of the current settings and compare them with the settings after you did that.
We tell everyone unless you have a new cluster do NOT do get interfaces with topology.
We recently had a case where the sync interface was set to private instead...
Well there is another question I have for you, this must be a VRRP cluster, otherwise how do you get the Cluster IP (VIP) on those interfaces?

[Danny]

Hi Linus,

to answer your questions:

• Anti-Spoofing is performaned based on each interfaces' calculated topology coming from the central configuration of the firewall management. To find out what the actual calculation is, just run this One-liner or use our ccc script.
• The trouble you may run into is loosing the current Anti-Spoofing configuration is it may be reset (sk136372). The automatic routine also creates network objects and internal references to the cluster object you may not be able to modify afterwards. That's why I always recommend to configure these settings with great care and by an experienced firewall administrator.

[Linus_Espach]

Hi Danny,
thanks for the answer and the information!
Only to clarify:
With <central configuration of the firewall management> I guess you don`t mean the local configuration of the specific FW which can be showed using <show configuration> on the specific FW-(Cluster-)Member but the Anti-Spoofing settings in the GW-Config of SmartConsole under Topology-Settings.
Connecting this infos, I assume, that one has to care for the Topology-Settings in SmartDashboard to adjust Anti-Spoofing-Settings (Because I thought Anti-Spoofing-Settings might be derived from GW-(Cluster-)Member config or routing-table automatically)
Have I understood you correct?

[Danny]

Hi Linus,

right, with "central configuration of the firewall management" I don`t mean the local configuration of the specific FW which can be showed using <show configuration>.

You wrote:"Because I thought Anti-Spoofing-Settings might be derived from GW-(Cluster-)Member config or routing-table automatically" <- this is not correct as you figured out by now.  You always have to keep your central (firewall management) and local (firewall) topology configuration consistent. And as you further noted by all the answers in this thread we recommend to do this manually, meaning don't use the buttons to load in the firewall's interface and topology information into the firewall management automatically.

[Timothy_Hall · Accepted solution]

Interfaces that are defined in the Gaia OS but not listed in the gateway/cluster object will not have antispoofing enforced as Dameon mentioned.  However traffic to and from those missing interfaces will be automatically classified as External (technically it is not explicitly defined as Internal) and blades such as APCL/URLF & possibly Threat Prevention will tend to pull traffic crossing this interface into at least the Medium Path for inspection due to the inclusion of this missing interface in dynamic object "Internet".  If this is a busy, high-speed interface it can have a dramatic impact on the CPU load of the firewall and cause noticeable delays for all traffic.  From my book:

Click to Expand

So at long last, we are ready to describe exactly what object “Internet” will match when used in our policies:

• Traffic whose routing destination is via an interface explicitly defined in the firewall’s topology as “External”
• Traffic whose routing destination is via an interface with checkbox “Interface leads to DMZ” set
• Traffic whose routing destination is via an interface that does not explicitly appear in the firewall object’s topology definition at all. (Yes that means that all individual subinterfaces assigned for 802.1q VLAN tagging must be listed in the firewall’s topology and have their topology set correctly)

[Linus_Espach]

Hi Timothy,

that answers my question exactly, thanks for this.

Best regards,