SecureXL and Local Address Spoofing on R77.30

[SantiagoPlatero]

Hi all, last week I stumbled upon a weird issue with SXL on an Open Server running R77.30.

The issue only appears to happen when local wireless users (going through other gateway than the Check Point) tried to access to the Outlook Web Access server, which is located on the DMZ and is statically nated to a public IP address, bound to the external interface of the Check Point.

With SecureXL enabled, the Check Point gateway drops all traffic from this wireless users when they tried to access to the OWA portal, or when their phones tried to sync mails via ActiveSync to this OWA server. In all the cases the drop reason was "Local Address Spoofing".

Although I specifically added the natted (hide) internet address for these wireless users to the "Don't check packets from" dropdown on the external interface of the conflicting gateway, the issue remains and the drop reason was always "Local Address Spoofing".

I could only solve the issue disabling SecureXL. It didn't mind to me have SXL disabled in this gateway, as its licensed to only one core and have a marginal usage. But as I found some SK's regarding issues with SXL and spoofing in clusters, gateways with bridged interfaces, virtual systems and so on... But-but this is an standalone gateway, it doesn't have any bridged interfaces and it's not a VSX.

Also I didn't find any clue regarding this issue in the Known Limitations' SK for R77.30.

Maybe a bug?

Note aside, although the two internet services are deployed on the same physical site, the Check Point gateway was never connected to the internet service provided for the wireless users. 

Also, this gateway is managed by a R80.20 management.

Hope the picture were pretty clearly described.

Thanks!

[PhoneBoy]

I assume the SK you are referring to is this one: How to troubleshoot "Local interface address spoofing" issues 

Generally it means that the gateway is receiving a packet for something that it thinks it should have sent itself.

Have you done any fw monitor/tcpdump to see if the traffic is indeed coming back to you somehow?

[SantiagoPlatero]

Hi Dameon, the SK's I was referring to were the related solutions ones to the SK you linked.

I forgot try to capture the traffic when the issue was in place, but I had a 100% certainty the traffic wasn't originated by the gateway, cause I were onsite checking the problem, and the traffic was originated by a Cisco ASA on the same site of the gateway, go through internet and arrives to the gateway from the external interface (and then blocked for supposedly spoofing).

Will try to do the capture (enabling SXL first, obviously) the next weeks as the users behind this gateway won't work between holidays.