- Products
- Learn
- Local User Groups
- Partners
- More
Quantum Spark Management Unleashed!
Introducing Check Point Quantum Spark 2500:
Smarter Security, Faster Connectivity, and Simpler MSP Management!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
Hi Checkmates,
I've got a scenario whereby I've got a star community with all traffic routed through the center.
I've got a requirement now to break out SMTP traffic to a specific destination locally at one of the spokes (and at that spoke only - all other spokes should still encrypt and send through the center).
In the event that I exclude a specific source / destination / service via crypt.def, would traffic then obey a policy route on the gateway or would it still be sent to the center, but in cleartext? The spoke in question is a Quantum spark running 80.20.50 in case it's relevant.
Is there perhaps a better way of doing this than fiddling with crypt.def and INSPECT syntax? FWIW this is the syntax I'm looking to implement:
#ifndef NON_VPN_TRAFFIC_RULES
#ifndef IPV6_FLAVOR
#define NON_VPN_TRAFFIC_RULES (src=192.168.1.10,dst=1.2.3.4,dport=25)
#else
#define NON_VPN_TRAFFIC_RULES 0
#endif
#endif
Thanks,
Ruan
This "hack" to crypt.def ensures the specified traffic is NOT encrypted (i.e. sent through VPN) and it should be sent according to the normal routing table.
Unfortunately, there isn't a cleaner way to do this currently.
And, because you're talking SMB gateways, make sure the change is made to the appropriate "Backward Compatibility" directory version of crypt.def.
I could be mistaken, but I believe if you modify crypt.def, it would be sent in clear, maybe someone else can confirm 100%. Actually, I dont believe TAC would ever recommend you to do something like this, but I saw customer once create VPN rule to block traffic they did NOT want going through the tunnel (they just placed it above accept vpn rule). Personally, I only saw that one time and never again. Most people just do it by modifying the file you mentioned.
This "hack" to crypt.def ensures the specified traffic is NOT encrypted (i.e. sent through VPN) and it should be sent according to the normal routing table.
Unfortunately, there isn't a cleaner way to do this currently.
And, because you're talking SMB gateways, make sure the change is made to the appropriate "Backward Compatibility" directory version of crypt.def.
Hello,
I have a similar issue which is on location A I have a SMB Quantum spark running 80.20.50 which has established IPsec tunnel to location B which is a Cluster of 3600 appliances. All traffic is routed through center which is cluster. On location A I have a device with local IP 192.168.15.245 which traffic should not be going through tunnel but directly to internet from location A.
How should I write my crypt.def ?
#ifndef NON_VPN_TRAFFIC_RULES
#ifndef IPV6_FLAVOR
#define NON_VPN_TRAFFIC_RULES (src=192.168.15.245)
#else
#define NON_VPN_TRAFFIC_RULES 0
#endif
#endif
Looking forward to your reply,
Klemen
Hi Klemen, as per above we did this successfully for one of our clients, I'll see if I can get a sanitized copy and post it here.
Hello,
should I open new ticket or are you still trying to get sanitized copy ?
Hi Klemen,
This is what we used (need was to exclude SMTP traffic from a specific host from the tunnel):
#ifndef NON_VPN_TRAFFIC_RULES
#ifndef IPV6_FLAVOR
#define NON_VPN_TRAFFIC_RULES (src=192.168.10.10,dport=25)
#else
#define NON_VPN_TRAFFIC_RULES 0
#endif
#endif
Also refer to the below to SK's (depending on the gateway platform you need to modify different files on the SMS etc.)
Thanks,
Ruan
Hello,
does anyone know the possible syntax? I need to exlude several networks and working just with "src=" and "dst=" and many many "or" in between leads to a very big crypt.def file! Usage of networks would be great.....
Thanks
The language used here is INSPECT, so it should be possible.
fw monitor uses the same syntax, and it’s described here: https://support.checkpoint.com/results/sk/sk30583
Checked so far - wildcard would have been the best option but seems not to work (like exclude all MPLS routers to check connectivity....10.190.*.1).
Also as I see no option to install specific rules only on specific gateways.
You're changing an INSPECT macro.
I'm not aware of a way to make it different for different gateways short of manually maintaining it for each gateway.
A route-based VPN would probably be a better approach here since it can be affected through routing changes on the local gateway.
it works perfectly with gaia gateways - just the added 1500 devices on R81.10 completely ignore the VPN exclustions in crypt.def.
File should be the same for all R81.10 gateways, right? $FWDIR/lib/crypt.def
Or is there a different syntax for the quantum spark series?
Different locations for Spark as far as I recall - I linked the SK's in a previous post.
thought from R81.20 Mgmt admin guide it should be $FWDIR/CPSFWR81CMP-R81.10/lib/crypt.def but changes here are not influencing quantum sparc behavior.....so I creates an SR.
That is only for SMB gateways running R81.10.
For other firmware versions, you'll need a different path.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
9 | |
7 | |
6 | |
5 | |
5 | |
5 | |
5 | |
4 | |
4 | |
4 |
Fri 12 Sep 2025 @ 10:00 AM (CEST)
CheckMates Live Netherlands - Sessie 38: Harmony Email & CollaborationTue 16 Sep 2025 @ 02:00 PM (EDT)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - AmericasWed 17 Sep 2025 @ 04:00 PM (AEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - APACWed 17 Sep 2025 @ 03:00 PM (CEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - EMEAThu 18 Sep 2025 @ 03:00 PM (CEST)
Bridge the Unmanaged Device Gap with Enterprise Browser - EMEAFri 12 Sep 2025 @ 10:00 AM (CEST)
CheckMates Live Netherlands - Sessie 38: Harmony Email & CollaborationTue 16 Sep 2025 @ 02:00 PM (EDT)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - AmericasWed 17 Sep 2025 @ 04:00 PM (AEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - APACWed 17 Sep 2025 @ 03:00 PM (CEST)
Securing Applications with Check Point and AWS: A Unified WAF-as-a-Service Approach - EMEAThu 18 Sep 2025 @ 03:00 PM (CEST)
Bridge the Unmanaged Device Gap with Enterprise Browser - EMEAAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY