- Products
- Learn
- Local User Groups
- Partners
- More
Welcome to Maestro Masters!
Talk to Masters, Engage with Masters, Be a Maestro Master!
Join our TechTalk: Malware 2021 to Present Day
Building a Preventative Cyber Program
Be a CloudMate!
Check out our cloud security exclusive space!
Check Point's Cyber Park is Now Open
Let the Games Begin!
As YOU DESERVE THE BEST SECURITY
Upgrade to our latest GA Jumbo
CheckFlix!
All Videos In One Space
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!
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?
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.
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY