VSX, anti spoofing and dynamic routing

[Alex-]

I was checking sk32500 - Anti-spoofing on VSX (static and dynamic) in order to manage anti-spoofing on a VSX which has switched from static to dynamic routing and enforce anti-spoofing.

Steps so far:

• Dynamic routing enabled and working
• Disable "Calculate topology automatically based on routing information" at the VS level
• Edit the relevant interface and select "Internal - Defined by routes" for the topology
• Set the anti-spoofing to Detect for initial verification

But then, sources coming from the interface which match prefixes received by the dynamic routing protocol on that interface are flagged as anti-spoofing with the yellow shield as we are in detection mode.

So if a prefix on interface bond10.20 is learnt as 10.1.1.0/24, we see for instance 10.1.1.1 flagged as spoofed with direction incoming on that interface in the logs.

We are probably missing something, but what? Any tips are welcome.

CP appliances, R81.10 Take 150.

[PhoneBoy]

I suggest doing a kernel debug on the VS to see what the actual reason is for the drop.
TAC may be necessary to investigate this further.

# Step 1: Determine the VSID
vsx stat -v

# Step 2: Allocate Kernel Debug Buffer
fw ctl debug -buf 32768 -v <VSID>

# Step 3: Enable Debug Flags for Anti-Spoofing
fw ctl debug -m fw + drop -v <VSID>

# Step 4: Start Capturing the Debug Output
fw ctl kdebug -T -f -v <VSID> > /var/log/debug.txt

# Step 5: Replicate the Issue
# Perform the actions that trigger the anti-spoofing mechanism

# Step 6: Stop the Debugging
# Press Ctrl+C in the terminal where fw ctl kdebug is running

# Step 7: Analyze the Debug Output
# The debug output will be saved in /var/log/debug.txt

[Lesley]

Just to make sure, is there no 10.1.1.0/24 hidden in the anti-spoofing group behind a different interface then bond10.20?

Sometimes I see customers that for example define 10/8 behind interface X and smaller subnet 10.0.0.0/24 behind interface y.

Do you get my point? For now work around is do disable AS and put the network in the option: "Do not check packets from": and add there the group with network. Hope that helps

[Chris_Atkinson]

Maybe check your config to see how relevant sk181768 is...

[JozkoMrkvicka]

I faced similar issue on VSX, but anti-spoofing was dropping BGP communication within the same subnet, from same External interface. Lets say I have VLAN 10 with subnet 10.0.0.0/24. VS has 10.0.0.1 and BGP peer has 10.0.0.10. BGP traffic from VS to BGP peer was dropped by anti-spoofing...

Workaround used: "Don't check packets from: 10.0.0.0/24".

Here are some related articles:

Anti-Spoofing drops packets that arrive at a Security Gateway through interfaces with Topology "External"

Anti-Spoofing drops IPv6 traffic that arrives at an interface with an IPv6 address configured

[AlekzNet]

Related forum threads:

https://community.checkpoint.com/t5/Security-Gateways/What-is-the-difference-between-interface-topol...
https://community.checkpoint.com/t5/Security-Gateways/What-is-the-difference-between-interface-topol...

[Alex-]

Thanks all for the replies. We took more time to look at the implementations and it appears this is related to the same prefix being learnt on two or more peerings simultaneously and ECMP being off. After enabling ECMP, our observation IP doesn't report spoofing anymore.

We will continue working on the general architecture of this deployment to see if this is the solution.

[Alex-]

Since we live in those times, I had a chat with Copilot at the Support Center which was more explicit than the documentation. 😀

So without ECMP, the FW will hash the destination and assign it to an interface. If the same traffic comes also from another, it's considered as spoofed. With ECMP, it will allow up to 8 paths and will install the prefixes on any of those.

Since "Topology defined by network routes" checks these tables, ECMP must be on for multi path to work in conjunction with anti-spoofing, otherwise it must be manually set, turned off or set to detect.