- Products
- Learn
- Local User Groups
- Partners
- More
MVP 2026: Submissions
Are Now Open!
What's New in R82.10?
Watch NowOverlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
The predefined service-tcp and service-udp objects on the Security Management do not use only plain integer numbers for the port property. They use also:
Unfortunately the documentation is incomplete and it describes only plain numbers and ranges:
Where is the greater than operator documented? What is the complete syntax of the port number property? Are all the INSPECT language operators supported? (<, <=, >, >=, !=)
Here is an example of service-tcp with the greater-than operator:
> show service-tcp name tcp-high-ports
uid: "97aeb3dd-9aea-11d5-bd16-0090272ccb30"
name: "tcp-high-ports"
type: "service-tcp"
domain:
uid: "a0bbbc99-adef-4ef8-bb6d-defdefdefdef"
name: "Check Point Data"
domain-type: "data domain"
port: ">1023"
match-by-protocol-signature: false
override-default-settings: false
session-timeout: 3600
use-default-session-timeout: true
match-for-any: false
sync-connections-on-cluster: true
aggressive-aging:
enable: true
timeout: 600
use-default-timeout: true
default-timeout: 0
keep-connections-open-after-policy-installation: false
groups: []
comments: "TCP Ports 1024-65535"
color: "yellow"
icon: "Services/TCPService"
tags: []
meta-info:
lock: "unlocked"
validation-state: "ok"
last-modify-time:
posix: 1598366251916
iso-8601: "2020-08-25T16:37+0200"
last-modifier: "System"
creation-time:
posix: 1598366251916
iso-8601: "2020-08-25T16:37+0200"
creator: "System"
read-only: false
Not sure where it's documented, but it's really quick to test:
[Expert@LabSC]# mgmt_cli -s session.txt --format json set service-tcp uid "72b65d82-c1d7-4c9f-add2-906dee45d8a6" port "<1023" | wc -l
45
[Expert@LabSC]# mgmt_cli -s session.txt --format json set service-tcp uid "72b65d82-c1d7-4c9f-add2-906dee45d8a6" port "<=1023" | wc -l
7
[Expert@LabSC]# mgmt_cli -s session.txt --format json set service-tcp uid "72b65d82-c1d7-4c9f-add2-906dee45d8a6" port ">1023" | wc -l
45
[Expert@LabSC]# mgmt_cli -s session.txt --format json set service-tcp uid "72b65d82-c1d7-4c9f-add2-906dee45d8a6" port ">=1023" | wc -l
7
[Expert@LabSC]# mgmt_cli -s session.txt --format json set service-tcp uid "72b65d82-c1d7-4c9f-add2-906dee45d8a6" port "!=1023" | wc -l
7
[Expert@LabSC]# mgmt_cli -s session.txt --format json set service-tcp uid "72b65d82-c1d7-4c9f-add2-906dee45d8a6" port "!=1023"
{
"code" : "err_validation_failed",
"message" : "Validation failed with 1 blocking-error",
"blocking-errors" : [ {
"message" : "'Port' value is not 'any' or a valid port or port range"
} ]
}
[Expert@LabSC]# mgmt_cli -s session.txt --format json set service-tcp uid "72b65d82-c1d7-4c9f-add2-906dee45d8a6" port "1023,1025" | wc -l
7
Looks like it only allows < or > as prefixes. No <=, >=, or !=. I think < and > are technically considered single-ended ranges (where the 0 or 65535 is implied). Not sure why <= and >= wouldn't work, but it's not hard to just change the port number by one.
!= would create a discontiguous range, which I also tested with the comma case at the end. Evidently ranges must be contiguous.
Not sure where it's documented, but it's really quick to test:
[Expert@LabSC]# mgmt_cli -s session.txt --format json set service-tcp uid "72b65d82-c1d7-4c9f-add2-906dee45d8a6" port "<1023" | wc -l
45
[Expert@LabSC]# mgmt_cli -s session.txt --format json set service-tcp uid "72b65d82-c1d7-4c9f-add2-906dee45d8a6" port "<=1023" | wc -l
7
[Expert@LabSC]# mgmt_cli -s session.txt --format json set service-tcp uid "72b65d82-c1d7-4c9f-add2-906dee45d8a6" port ">1023" | wc -l
45
[Expert@LabSC]# mgmt_cli -s session.txt --format json set service-tcp uid "72b65d82-c1d7-4c9f-add2-906dee45d8a6" port ">=1023" | wc -l
7
[Expert@LabSC]# mgmt_cli -s session.txt --format json set service-tcp uid "72b65d82-c1d7-4c9f-add2-906dee45d8a6" port "!=1023" | wc -l
7
[Expert@LabSC]# mgmt_cli -s session.txt --format json set service-tcp uid "72b65d82-c1d7-4c9f-add2-906dee45d8a6" port "!=1023"
{
"code" : "err_validation_failed",
"message" : "Validation failed with 1 blocking-error",
"blocking-errors" : [ {
"message" : "'Port' value is not 'any' or a valid port or port range"
} ]
}
[Expert@LabSC]# mgmt_cli -s session.txt --format json set service-tcp uid "72b65d82-c1d7-4c9f-add2-906dee45d8a6" port "1023,1025" | wc -l
7
Looks like it only allows < or > as prefixes. No <=, >=, or !=. I think < and > are technically considered single-ended ranges (where the 0 or 65535 is implied). Not sure why <= and >= wouldn't work, but it's not hard to just change the port number by one.
!= would create a discontiguous range, which I also tested with the comma case at the end. Evidently ranges must be contiguous.
It’s true that the values for port number have their basis in INSPECT.
However, I’ve never seen formal documentation for what can be in the port number.
Have to admit, I didn’t know about the ports separated by commas one.
I had never actually seen ports separated by commas, it just made sense as another thing worth trying. Numbers separated by a dash makes a contiguous range, so could you do "21,1024-2048" to include multiple blocks of ports with gaps between them? Turns out no.
I believe that works in SMB appliances (the ports separated by commas), just never thought to try it in regular gateways 🙂
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 4 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
Tue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Thu 18 Dec 2025 @ 10:00 AM (CET)
Cloud Architect Series - Building a Hybrid Mesh Security Strategy across cloudsTue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Thu 18 Dec 2025 @ 10:00 AM (CET)
Cloud Architect Series - Building a Hybrid Mesh Security Strategy across cloudsAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY