Network 198.51.101.0

[dj0Nz]

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

[Chris_Atkinson]

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

[dj0Nz]

Thanks a lot. This will help!

[_Val_]

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.

[dj0Nz]

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

[_Val_]

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. 

[dj0Nz]

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.

[Yair_Shahar]

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

[dj0Nz]

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. 😉

[Nicholas_Cuba]

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

[dj0Nz]

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...

[dj0Nz]

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... 😶

[dj0Nz]

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...