Anti-Spoofing on Internet (External) Interface?

[Cypress]

I am seeing something weird on an R81.20 Gateway.  Our Internet-facing interface is set up in the Topology Spoofing settings with the Internet (External) box checked.  The anti-spoofing action is set to Detect.  We were trying to accomplish the goal of changing the action to Prevent across the board.  However, we still have some 'messy" Address Spoofing Detect hits, that needs to be cleaned up first.  

In this example, I see traffic hits in Logs & Monitoring when I search for "Address Spoofing" as my search filter, that shows Public IP Source, with the Public IP of our Gateway (Internet Interface) showing up as Detect.

It's my understanding with checking the box "Internet (External)" on the interface, then public IP traffic should no longer be detected as Address Spoofing.

The odd part of this traffic is, it seems to be return traffic, for example if a user had went outbound to a  website 1.2.3.4 they get source port 10108 and destination port 443.  Now when just searching for "Address Spoofing" I would see a session with source IP 1.2.3.4 destination port 10108 and source port 443.. so it looks like the return packets from that website.. showing up a separate Detect session.

What could cause this behavior?  I had one of my co-workers open a TAC case, but I don't think he worked out the details with TAC the case ended up closed with a false answer of "you need to create an allow list for anti-spoofing" but... we have "Internet (External)" checked, so I feel this answer does not properly apply to this specific case.

[emmap]

---

@Cypress wrote:

It's my understanding with checking the box "Internet (External)" on the interface, then public IP traffic should no longer be detected as Address Spoofing.

---

Not quite. An interface marked as 'External' for anti-spoofing means 'anything that is not configured in the topology of the internal interfaces'. So you need to make sure the IPs being dropped on the external interface are not somehow included in another interface's anti-spoofing.

[Cypress]

OK, That is very interesting information.  But it also introduces additional confusion.  I am going to have my coworker re-open the TAC Case and make sure he is showing them the correct logs and interface to address this issue, as I'm not certain I understand.  Or basically it seems like neither the source, nor the destination in the logs matches the anti-spoofing settings of any other interface but maybe I need to comb through them one by one to see how they are all set up.  I inherited these from a different team and they've come a long way since the R77.30 days so who knows what kind of config is buried in them.

[the_rock]

Can you send a screenshot of how that interface is set in topology? I see what @emmap is saying, makes total sense.

Andy

[Cypress]

I know the zone config looks wrong, but we are not doing anything with zones in our overall configuration, that is another thing on to-do list.

[the_rock]

Just do it like this (what I attached), I never have any problems that way in my labs.

Andy

[the_rock]

FWIW, I only recall having to do those exceptions few years back when my colleague and I were building route based tunnels to Azure from customer's on prem cluster.

Andy

[the_rock]

Would you happen to have specific log you can attach when issue is there?

Andy

[Martijn]

Hi,

When a packet arrives on a interface, one of the first thing that is checked, is spoofing. That is also the case for return traffic of a allowed connection. So if Anti-Spoofing is not configured correctly you will see return traffic being dropped.

Like @emmap says, Internet (External) means. All IP-addresses that are not configured for Anti-Spoofing on the internal interfaces. Have you checked the Anti-Spoofing configuration on the internal interfaces?

Martijn