r/checkpoint

we ran a trial for the SASE service and the trial expired without contract applying. we bought contract and applied it, but the gateway is still down. we’ve:

• opened a tech ticket in portal - no response
• told to open a non tech ticket for it’s a billing issue - no reasonable response
• called in 3x and told they’d call me back within an hour, nothing
• were on 3 threads with 5+ people, no actionable responses
• 2 threads attempted to open with my direct account mgmt team - nothing in response

this client has been down for 4 days and checkpoint has absolutely zero urgency in helping with this. We don’t even have information for a timeline of resolution. we’re baking in hard coded IPs in an azure tenant to get around this. easily the most frustrating experience I’ve had with a vendor in a decade.

I have an interview with Check Point Software Technologies and was wondering if anyone has been through the process and knows what they’ll ask for behavioral, system design, and leetcode?

We have a Check Point 1600 appliance running R82.00.10 in front of a Symantec Messaging Gateway. SMTP traffic flow should be: Internet sender → Check Point public IP 88.88.88.88:25 → DNAT → SMG 10.100.100.100:25. The Check Point internal/LAN IP is: 10.100.100.10, the expected behavior is DNAT only, preserving the original public sender IP.

Expected fw monitor result:
DMZ:i <real_sender_IP> -> 88.88.88.88:25
DMZ:I <real_sender_IP> -> 10.100.100.100:25
LAN1:o <real_sender_IP> -> 10.100.100.100:25

However, when Check Point Anti-Spam / Mail Server / generated Server rule is enabled, Check Point acts as an SMTP proxy. It terminates the external SMTP session and opens a new internal SMTP session to SMG.

Bad fw monitor result:

DMZ:i <real_sender_IP> -> 88.88.88.88:25
LAN1:o 10.100.100.10 -> 10.100.100.100:25

This causes SMG to see the Check Point as the SMTP client instead of the real sender.

SMG headers then show: Received: from sender.domain (Unknown_Domain [10.100.100.10]) by mail.local

instead of: Received: from sender.domain ([real_public_sender_IP]) by mail.local

Impact: Because SMG sees 10.100.100.10 instead of the real sender IP, the following checks are affected:

- IP reputation
- RBL/DNSBL checks
- SPF validation
- reverse DNS / PTR checks
- GeoIP / ASN filtering
- IP allow/block rules
- rate limiting / greylisting
- mail forensics and logging

This also causes authentication failures such as:

spf=fail dmarc=fail
because SPF is evaluated against 10.100.100.10 instead of the real public sending IP.

Root cause:

Check Point is not operating as a simple NAT firewall for SMTP when Anti-Spam / Mail Server / generated Server rule is enabled.

It behaves as: Internet sender → Check Point SMTP proxy → SMG

instead of: Internet sender → DNAT only → SMG

Working configuration

After disabling Check Point Anti-Spam and removing the auto generated Mail/Server rule, SMTP traffic works correctly as DNAT-only:

LAN1:o <real_sender_IP> -> 10.100.100.100:25

SMG then receives the real sender IP and mail authentication/reputation checks work correctly.

Desired state:

For inbound SMTP - Check Point fw should only perform:

Firewall allow + DNAT TCP/25, Anti-Spam inspection and NO SMTP proxy

Before the firmware upgrade to R82.00.10, this NAT configuration worked as expected from the beginning. Inbound SMTP traffic was handled as DNAT-only, and the original public sender IP was preserved toward the Symantec Messaging Gateway.