Anti-Spoofing Issue

[biskit]

I'm having a weird anti-spoofing issue that I can't figure out.  Does anyone have any ideas?

As per the diagram, I have a SmartCenter in a DMZ which manages several other gateways routed behind the LAN interface.  These all work fine.

I've just added another routed network 172.16.0.0/19 behind the LAN router.  It's in the spoof group for eth1, and there's a single static route for 172.16.0.0/19 via 10.202.1.1.

I have no other objects or routes for any 172.16.x IP's besides the network object for 172.16.0.0/19.

When I go from the SmartCenter to 172.16.8.x it routes and works fine.

When I go from the SmartCenter to 172.16.6.x I see the SmartCenter IP dropping on the LAN interface (eth1) with anti-spoofing.

fw monitor looks the same for both 172.16.8.x and 172.16.6.x.  It shows my traffic entering eth2 and leaving eth1, which is correct.  

Why does traffic to 172.16.6.x cause an anti-spoofing drop for 192.168.37.20 on eth1???

[Danny]

I recommend to run my One-liner for Address Spoofing Troubleshooting to check the calculated topology on the gateway. This should show you to which interfaces 172.16.6. is calculated.

[the_rock]

Hey Matt,

Personally, what I always do and never had any issue is below. Never had a problem with it, as long as routing is right.

You can also find the reference in the link:

Interface - Topology Settings (checkpoint.com)

[Timothy_Hall · Accepted solution]

If antispoofing is dropping the packet on the egress interface eth1, it does not think that the packet's destination IP address is reachable via that interface.  Your routing on the firewall is wrong or the next hop 10.202.1.1 is not reachable; even if you set "network defined by routes" or set antispoofing to Detect mode on eth1 to let the traffic through, I'd bet that that connectivity will still not work.

[the_rock]

Well, that was sort of my point. As long as routing is correct, in my experience, that setting ALWAYS works.

[Bob_Zimmerman]

Sounds more likely to be a routing loop rather than a problem reaching the next hop to me. I bet the logs have a pattern of accepted packet, dropped packet. The accept is when the traffic hits the rules and is passed. The drop is when the same packet gets routed back to the firewall and it says that source isn't allowed in that interface.

[Timothy_Hall]

Yep if it is a routing loop and the packet is getting inappropriately bounced back to the firewall by the core router, in the antispoofing drop log card the arrow next to eth1 will be pointing down (inbound).  If the arrow is pointing up (outbound) in an antispoofing drop log, the routing on the firewall itself is wrong/incomplete or the next routing hop is not reachable.  This little arrow is subtle and easy to miss but very helpful for these types of issues.

[Bob_Zimmerman]

Huh. I've never seen that. I wonder why traffic with no reachable next hop gets dropped for antispoofing, of all things.

[biskit]

So it was exactly as you described...  The core router had routes for some 172.16.x subnets but not others, so the missing routes were being bounced back to the firewall.  All sorted now.  Thanks guys!