R80.10 Gateway: SecureXL + DCE RPC

[Egenity]

One of my clients recently migrated to R80.10 on brand new 5800s running in high availability.  These units replaced some older 12200 units running R77.30.

After the migration, strange issues with DCE RPC communication began to crop up.  The most visible was Outlook fat client running across Endpoint VPN trying to communicate with the Exchange servers.   After careful examination, I determined that sometimes the endpoint mapper attempt on port 135 would be permitted (via the special ALL_DCE_RPC service), but the response would be corrupted or possibly dropped (no log evidence other than the 135 connection allowed).  About 30% of the attempts would work just fine, the remainder would mysteriously fail.

I immediately started chasing IPS as a possible culprit, but could not find any logging evidence to blame it and exceptions had absolutely no effect on things.

After many hours of troubleshooting, I finally started looking at the acceleration layer.  Sure enough, disabling SecureXL caused the this DCE RPC issue to disappear.  

NOW, I am fully aware that SecureXL combined with DCE RPC communication will defeat acceleration templating, that has been discussed elsewhere and documented.  HOWEVER, even with that caveat, it should not disrupt, drop or interfere with the DCE RPC communication.

Has anyone come across this?  Is it a known bug?  Are there configuration items I need to visit in the acceleration layer or elsewhere that need to be dealt with?

These gateways are operating on R80.10 Take 70.

Adam

[PhoneBoy]

Disabling SecureXL should never be the solution to a problem.

You should open a TAC case.

Contact Support | Check Point Software 

[Timothy_Hall]

When SecureXL is enabled some connection/inspection timers are handled a bit differently, not sure if that is related to your problem.

In the meantime, instead of disabling SecureXL completely I'd recommend disabling acceleration for just for the specific IP addresses that are having the DCE/RPC issues.  See the following SK for the instructions:

sk104468: How to disable SecureXL for specific IP addresses

While completely disabling SecureXL on a 4-core box like a 5800 won't have a dramatic effect, doing so can be downright disastrous on boxes with more than 8 cores due to the automatic interface affinity function getting disabled along with SecureXL.

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

[Egenity]

Very good points Tim, thank you!   I am not sure how feasible it will be to disable SecureXL for specific IP addresses/ranges, as it is unclear how widespread the problem is.  The specific instance of Outlook vs. Exchange was the most reported and visible.

Dameon Welch Abernathy:  I will be pursuing a SR on this once I can definitely confirm the issues are truly resolved by turning off SecureXL.   I was just soliciting any additional information and/or advice anyone had.  Nice to encounter you again, it has been many years!