topic Re: Network 198.51.101.0 in Hyperscale Firewall (Maestro)

Network 198.51.101.0

dj0Nz — Wed, 05 Jul 2023 09:41:57 GMT

Mates,

while troubleshooting a new deployment we found a network 198.51.101.0 which is used internally by Maestro. This network is a public routed one (https://wq.apnic.net/apnic-bin/whois.pl?searchtext=198.51.101.0&object_type=inetnum).

Does Check Point have some kind of agreement with the owner which allows them to use these addresses? Or is this some kind of "has anyone seen my glasses"-incident?

Cheers,
Michael

Re: Network 198.51.101.0

Chris_Atkinson — Wed, 05 Jul 2023 09:59:50 GMT

Suggest reviewing the following SK and following up further with your CP SE as needed.

sk179028: Connectivity issues with hosts in the network of 198.51.101+X.0/25 on Security Group X

Re: Network 198.51.101.0

_Val_ — Wed, 05 Jul 2023 10:04:03 GMT

This range is used for internal communications and should not affect your production traffic in normal situations. However, if you need to change it, there is an SK provided by @Chris_Atkinson here already.

Re: Network 198.51.101.0

dj0Nz — Wed, 05 Jul 2023 10:44:47 GMT

Thanks a lot. This will help!

Re: Network 198.51.101.0

dj0Nz — Wed, 05 Jul 2023 10:54:24 GMT

If I'm not misinterpreting the routing table below, the customer won't be able to communicate with the "Bandung Institute of Technology" because the gateway has a local route.

But anyway, the SK provided by Chris will help.

Maybe someone at R&D can have a look at this issue, perhaps shifting internal communications to a separate network namespace could do the trick.

Thanks a lot for your help!

---

Routing table from customer SMO:

[Expert@firewall-ch01-01:0]# ip route show
default via x.x.x.x dev magg0 proto 7
x.x.x.x/24 dev bond1.x proto kernel scope link src x.x.x.x
x.x.x.x/24 dev magg0 proto kernel scope link src x.x.x.x
192.0.2.0/24 dev Sync proto kernel scope link src 192.0.2.1
198.51.101.0/25 dev eth1-CIN proto kernel scope link src 198.51.101.1
198.51.101.128/25 dev eth2-CIN proto kernel scope link src 198.51.101.201

Re: Network 198.51.101.0

_Val_ — Wed, 05 Jul 2023 12:15:17 GMT

Very unlikely, most probably your German customers have no need to connect to a business school in Indonesia.

Also, I quickly took a look at what they have in the range 🙂

You do not want to connect to any of those resources, but in case you do, there is always a way to change the internal communication IP range, as already mentioned.

Re: Network 198.51.101.0

dj0Nz — Wed, 05 Jul 2023 12:52:56 GMT

You are completely right. But this customer sees that as a design flaw, and he has a point.
The changes mentioned in sk179028 don't seem too complicated, we will go that way.

Thanks, again.

Re: Network 198.51.101.0

Yair_Shahar — Wed, 05 Jul 2023 15:17:07 GMT

Hi,

This IP range was first used back in 2011 while SP Chassis solution was first introduced.

This range was for documentation purposes only as mentioned here:

https://en.wikipedia.org/wiki/Reserved_IP_addresses#cite_note-rfc5737-6

Currently there is option to replace those IPs as mentioned in sk179028, we will look into it for future releases.

Yair

Re: Network 198.51.101.0

dj0Nz — Wed, 05 Jul 2023 17:30:25 GMT

Sorry, I have to disagree. AFAIK the TEST-NET-2 range has always been 198.51.100.0/24.
But good to hear that you are working on this matter. 😉

Re: Network 198.51.101.0

Nicholas_Cuba — Tue, 11 Jul 2023 17:32:21 GMT

Indeed it is.
https://tools.ietf.org/html/rfc5737
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml

Re: Network 198.51.101.0

dj0Nz — Tue, 25 Jul 2023 12:42:02 GMT

Okay this is weird. Checked sk179028 and found this:

[Expert@smo:0]# ifconfig -a | grep -B 1 198.51 eth1-CIN Link encap:Ethernet HWaddr 00:1C:7F:xx:xx:xx inet addr:198.51.101.1 Bcast:198.51.101.127 Mask:255.255.255.128 -- eth2-CIN Link encap:Ethernet HWaddr 00:1C:7F:xx:xx:xx inet addr:198.51.101.201 Bcast:198.51.101.255 Mask:255.255.255.128 [Expert@smo:0]# jq -r .cin /etc/smodb.json { "base-ip": "198.51.100.1", "base-mask-length": 25, "base-vlan": 3900

On mho I found this:

[Expert@mho:0]# grep 198.51.101 /etc/maestro_internal_communication_ips 198.51.101.0/25

Now i am very curious about the explanation from TAC...

Re: Network 198.51.101.0

dj0Nz — Tue, 25 Jul 2023 14:07:36 GMT

Found it. https://support.checkpoint.com/results/sk/sk174966

-> Filter: smodb.json

I wonder why "The Maestro Orchestrator will read the IP address range for CIN interfaces from the smodb.json database." is called an "Enhancement" but anyway... 😶

Re: Network 198.51.101.0

dj0Nz — Tue, 05 Sep 2023 14:16:47 GMT

Finally, we got an "explanation":

"3rd octet is variable + Security Group ID. This is as per design"

Asked to add this (and the procedure from sk174966) to the Maestro documentation.
At least this "design" and how to cope with it should be documented somewhere...

Re: Network 198.51.101.0

David_Evans — Thu, 13 Feb 2025 18:35:33 GMT

I just found this thread and the solution, however, this is is something that should be addressed. I have subnets 198.51.101 - 108 on my maestro.

Putting these subnets into BGP looking glass sites, most of them have valid BGP routes on the public Internet, not just the one that I had issues with. Using public IP space that isn't yours, for anything is bad form all around, but hiding it in a public application is even a bigger deal.

More annoyingly they are /25's on each of our maestro's so sometimes this communication would work and sometimes it wouldn't, depending on which MHO it hit.

I know there is no "safe" set of subnets to use when you are deploying every large enterprise in the world. But randomly picking someone else's public IP space, and burring it in the layers of abstraction that is the Maestro MHO is probably not the best solution.

The only reason I found this in just a few hours is my corporation owns and leases a couple /24's in the 198.x.x.x IP space and I have stumbled into an issue with 198.51.100.0/24(IANA reserved for testing / documentation) before. (a poorly written BOGON deployment) but 198.51.101+ are publicly routed and should not be used.

I can tell you that at this large corporation, we use one of OUR owned and publicly routable subnets inside our application back end, deployed publicly. We simply will not ever deploy that particular subnet to the Internet. At that point, there really is a subnet that no other corporation should ever need to route to that is NOT RFC 1918 space or the like. So there is a solution to this problem....