Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
biskit
Advisor
Jump to solution

Anti-Spoofing Issue

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???

 

Drawing1.jpg

1 Solution

Accepted Solutions
Timothy_Hall
Legend Legend
Legend

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.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com

View solution in original post

0 Kudos
(1)
8 Replies
Danny
Champion Champion
Champion

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
Legend
Legend

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.

anti-spoofing.png

You can also find the reference in the link:

Interface - Topology Settings (checkpoint.com)

0 Kudos
Timothy_Hall
Legend Legend
Legend

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.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
(1)
the_rock
Legend
Legend

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

0 Kudos
Bob_Zimmerman
Authority
Authority

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
Legend Legend
Legend

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.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
(1)
Bob_Zimmerman
Authority
Authority

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

0 Kudos
biskit
Advisor

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!

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events