Who rated this post

This sort of thing comes up every few years as folks become users of Check Point products, or become more aware of the inner workings.

Communication with all of the Check Point products are secured by their TLS-wrapped connections with certificates issued from the management server's private PKI internal CA.  Various ports must be open to the management server because gateways (and other products) could be, and often are, deployed widely on various external networks.

While these ports are "listening", connections to them are controlled by the application services which will only allow known gateways (or other management products) to establish a connection.  Attempts to further establish a connection (beyond the SYN/SYN-ACK/ACK open port) will fail if the remote host is not a previously-registered host (including remote VPN peers, for gateway implied rules).

Once a port connection is made, the first packet is a TLS negotiation (for management services) and that's where the connection will fail if the host cannot present a valid cryptographically-signed certificate.  For remote VPN peers, IPsec Phase 1 requires the peer IP and shared secret (dynamic peers must use a certificate).

As Lesley noted, a port simply being open means little-to-nothing if a connection cannot be established.

As for seeing the list of implied management rules, this option has been visible in SmartConsole, SmartDashboard, and previous product iterations for over 25 years now.  This is nothing new.  Disabling the implied rules will lead to trouble one day when you forget allow some access, or use a different product feature and not have management access open, or (worse) when someone else has to come behind you to work on something that you've disabled but they don't know about it.  Leave the implied rules as they are (minus some rare exceptions).

For your border router ACLs, you absolutely DO NOT want to do this.  This is completely invisible to you and your security management. Even if you write this on a sticky note attached to your screen, or tattoo it on your arm, you will forget about this one day (or the person who comes in behind you will have no awareness, especially when you take a nice 4-day vacation overseas). 

For your SoC team alerts, this is a Teachable Moment.  They need more insight for the products they are monitoring.  Quantify vs. Qualify.  Hitting the Big Red Button(tm) at 3am for port scans and TLS cipher probes dilutes the value of their service and contributes to desensitization of security alerts.

Be sure you read the product documentation completely, search other posts here on these forums for prior discussions, and (if you have access) search SecureKnowledge for your topic.  You'll almost always find prior discussions in some form.

Your other issues (IKEv2, ARP, etc.) aren't relevant to the implied rules and should be discussed separately.  These likely stem from a lack of product configuration and understanding.  Each vendor has their own quirks and none of them are perfect.  Remember that networking technology is well over 50 years old now, and a lot of tricks and techniques were "made up as we went along".  These tricks tend to become sticky over time and eventually fossilize.

There are some things we wouldn't do today if we had to do them over again (hence some of the jarring changes in cloud networks).  We all know NAT is Evil and we hate it; but 8-bit IP subnets were handed out like Pez in the 1970s and 1980s.  Other vendor disinformation in the late-1990s didn't help matters, either.

For documentation corrections, you can submit feedback for product documentation as either a TAC case or feedback within the documentation's SK article.

Let us know if you still have questions.