- Products
- Learn
- Local User Groups
- Partners
- More
Introduction to Lakera:
Securing the AI Frontier!
Quantum Spark Management Unleashed!
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!
Created the IPsec site to site tunnel. however it was showing as down.
Checked traffic with peer ip address traffic however IKE traffic was dropped. Allowed the same now showing accepted. Still 4500 traffic was dropped.
logs below
AK 0: Get before set operation succeeded of simple_debug_filter_off
[Expert@bu2-fw-01:0]# fw ctl zdebug + drop | grep 154.52.35.150
@;2332418538;[cpu_11];[fw4_0];fw_log_drop_ex: Packet proto=17 154.52.35.150:4500 -> 193.53.133.17:4500 dropped by vpn_drop_and_log Reason: Clear text packet should be encrypted;
@;2332434814;[cpu_11];[fw4_0];fw_log_drop_ex: Packet proto=17 154.52.35.150:4500 -> 193.53.133.17:4500 dropped by vpn_drop_and_log Reason: Clear text packet should be encrypted;
@;2332469207;[cpu_11];[fw4_0];fw_log_drop_ex: Packet proto=17 154.52.35.150:4500 -> 193.53.133.17:4500 dropped by vpn_drop_and_log Reason: Clear text packet should be encrypted;
Please help for this
Check Your encryption domains. Looks like the subnets are not added in encryption domains or some thing wrong with those. But worth a check at encryption domains.
I agree with @Blason_R . That error means enc domain issue 9 times out of 10, so phase 2 problem. But, to be 100% sure, just do basic vpn debug:
vpn debug trunc
vpn debug ikeon
-generate some traffic
vpn debug ikeoff
Get ike.elg and vpnd* files from $FWDIR/log dir and examine ike.elg to confirm the failure point (use ikeview tool to open it, but notepad++ will do as well).
Andy
There could be two possibility for that.
1 4500 port is not in the exclude services in the vpn community
2 Either of one or both IP is part of the encryption domain, and these IP looks like the IP used to make the tunnel up so this should not be part of encryption domain.
No Need to exclude 4500 and 4500 can never be a part of encryption settings as per RFC. UDP/4500 is a NAT-T port and will not be part of encrypted traffic.
In past I faced the same issue when i excluded the 4500 it started working i am not sure why checkpoint is not considering this as exclude only
@Nishant12 , how you excluded the 4500 port?
Hi @Pradeep_Salunke,
Can you share more info about the gw's that are doing vpn? Is the peer is behind NAT? Is the topology of the peer configured correctly aka, external and internal configured correctly?
The exclusions is needed only in case you disabled implied rules, otherwise no need an exclusion.
Thanks,
Ilya
This is correct - There is no need to exclude the port and @Ilya_Yusupov is 100% correct. 4500 port will never be encrypted since its carrying the NAT data
It was working without exclusion but after the upgrade of HFA 156 in R80.40 stopped working not sure why but CP support also agree to exclude when we ask them as i am also agree it should not exclude
@Pradeep_Salunke from which jhf the upgrade was done?
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
15 | |
12 | |
8 | |
6 | |
6 | |
6 | |
5 | |
5 | |
4 | |
3 |
Tue 30 Sep 2025 @ 08:00 AM (EDT)
Tips and Tricks 2025 #13: Strategic Cyber Assessments: How to Strengthen Your Security PostureTue 07 Oct 2025 @ 10:00 AM (CEST)
Cloud Architect Series: AI-Powered API Security with CloudGuard WAFTue 30 Sep 2025 @ 08:00 AM (EDT)
Tips and Tricks 2025 #13: Strategic Cyber Assessments: How to Strengthen Your Security PostureThu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Wed 22 Oct 2025 @ 11:00 AM (EDT)
Firewall Uptime, Reimagined: How AIOps Simplifies Operations and Prevents OutagesAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY