Disable "Local interface address spoofing"

[Tomas_S_]

Hello,

we have a setup, where all the traffic is mirrored to the Checkpoint 5800 (via SPAN port).

Management and mirrored traffic interfaces both have "Anti Spoofing: Disabled",

however, since CP receives mirror of all the traffic (including one from its management interface), logs are filled with

message_info:"Local interface address spoofing" messages

(the MAC address of the mirrored packet is that of the router, not CP device).

How can we disable check for "Local interface address spoofing"?

Running R80.20.

[Danny]

In SmartLog, just enter. not spoofing

[Tomas_S_]

Wouldn't that only filter output in the view?

We are using cp_log_export, to export logs via syslog, and these are flooded with 

---

2018-11-07T11:49:58+02:00 local0.info 11.11.11.11 1: 2018-11-07T09:49:54Z ids-n2 CheckPoint 29740 - [action:"Drop"; alert:"alert"; flags:"401408"; ifdir:"inbound"; ifname:"eth1-01"; loguid:"{0x0,0x0,0x0,0x0}"; origin:"11.11.11.11"; originsicname:"cn=cp_mgmt,o=ids-n2.xx.xx.fpp84p"; sequencenum:"530"; time:"1541584194"; version:"5"; __policy_id_tag:"product=VPN-1 & FireWall-1[db_tag={637D2E66-C60F-4646-BD66-FDB8148F5F42};mgmt=ids-n2;date=1541582377;policy_name=Standard\]"; dst:"23.60.24.21"; message_info:"Local interface address spoofing"; product:"VPN-1 & FireWall-1"; proto:"6"; s_port:"38149"; service:"80"; src:"11.11.11.11"; ] 

...

---

messages

[Timothy_Hall · Accepted solution]

fw ctl set int fw_local_interface_anti_spoofing 0

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Tomas_S_]

Operation succeded, but messages "Local interface address spoofing" still pour to the fw.log.

# fw ctl set int fw_local_interface_anti_spoofing 0
Set operation succeeded

# fw ctl get int fw_local_interface_anti_spoofing
fw_local_interface_anti_spoofing = 0

# sim feature anti_spoofing off; fwaccel off; fwaccel on

Command 'sim feature' has been replaced. Use 'fwaccel feature' instead.

SecureXL device disabled.

# fwaccel feature anti_spoofing off
Invalid feature 'anti_spoofing'
Usage: fwaccel feature <name> {on|off|get}

Available features: sctp

I've also set:

# fw ctl set int fw_antispoofing_enabled = 0

[Tomas_S_]

After checkpoint reboot the issue is solved: there is no longer spoofing messages in the logs.

Thank You

[Ilya_Semen]

Hello Timothy !

Thanks for the answer! I 'm wondering if there will be a negative impact after entering this command on the gateway ?

[Timothy_Hall]

It won't affect production, it will just keep traffic that the gateway thinks is spoofing its own address from getting dropped.  Generally though if you are getting these messages it indicates a network misconfiguration of some kind such as another system in conflict with the firewall's interface IP address, or traffic that was NATted to the firewall's interface address getting incorrectly bounced back to the same firewall  interface due to an upstream routing problem.

[Ilya_Semen]

Thanks !
in our scheme, anti-spoofing is in the  Net_10.0.0.0(Internal) mode  on the Inside interface (anti-spoofing is detect  mode) . However, there is a need to connect the office of a partner who uses 10.109.0.0 networks area.  With successful initialization IPsec tunnel, we have drop log "Local interface address spoofing".  I'm assuming to change the topology for the Inside interface Net_10.0.0.0(Internal) ----> Specific, and to make a set of networks more granular than  Net_10.0.0.0(Internal).   I hope this helps to win )

[Timothy_Hall]

 A cleaner way to handle this is adding 10.109.0.0 as a "don't check packets from" exception on the External interface here:

[Ilya_Semen]

yes, of course, this was done first, the network 10.109.0.0 is excluded on the External interface. But it didn't help.  

[Ilya_Semen]

yes, of course, this was done first, the network 10.109.118.0/24 is excluded on the External interface. But it didn't help.

[Ilya_Semen]

[Timothy_Hall]

It is the source IP address 10.3.241.1 that is violating anti-spoofing in that log card, not the destination 10.109.118.51.  You have one of two situations occurring:

1) Most likely a routing problem.  Traffic was initiated from somewhere bound for 10.109.118.51, it arrived at the firewall who then source NATted it to 10.3.241.1 and sent it out egress interface bond0.801.  Some router on the path towards 10.109.118.51 improperly bounced the packet back to the firewall inbound on interface bond0.801 where it was dropped by spoofing.

2) IP address 10.3.241.1 is being used by some other host (either on the other side of the VPN or locally) and it conflicts with the firewall's interface IP.

Either way, turning off local interface spoofing enforcement will not help as the routing for either of these situations is incorrect.  If this is VPN traffic, checking "Disable NAT in VPN Community" for the relevant VPN Community might fix the problem, if it is caused by the firewall inappropriately NATting the traffic thus causing situation #1.

[Ilya_Semen]

Does the fact that 10.109.118.0/24 is behind the SmartLSM gateway matter? and I check VPNcomm settings,  yes NAT is disabled for those VPN communities 

[Timothy_Hall]

Need a network diagram please.

[Ilya_Semen]

In general, the diagram illustrates the current VPN connection. We have a cluster 10.3.24.1 (in HQ) behind it the area 10.0.0.0. SmartLSM SG in the branch, is successfully connected to this cluster, there is a network 10.109.118.0 behind the SmartLSM internal interface. ICMP or another service does not pass from the network 10.3.34.0/24 to the network 10.109.118.0/24. "Local interface address spoofing error"  Have one VPN community Star mode, members of this community  с26000 and SmartLSM SG. 

[Timothy_Hall]

You almost certainly have a supernetted route for 10.0.0.0 (probably /16 but could be /8) on your HQ firewall pointing to your internal core router.  You need a firewall static route for 10.109.118.0/24 with the next hop your Internet perimeter router.  Because you don't have this, the traffic to 10.109.118.0 is being NATed by the firewall then hairpinned right back to your internal core router, who promptly bounces it right back to the firewall which then drops it for spoofing.  Like I said, a routing issue.

You also need to ensure that the 10.109.118.0 network is not part of the VPN domain definition for the HQ firewall, a "group with exclusion" object is typically used for this purpose.  Obviously 10.109.118.0 must appear in the VPN domain for the remote firewall.

[Ilya_Semen]

You are absolutely right! Our routing was implemented poorly. Our network engineers fixed the situation and the problem with Local Spoofing  was solved. Thanks again for the help!