Stanby Gateway not Connected Internet

[ikafka]

Hi.

 I have a quick question. In the Ha Cluster, the active device has an internet cable plugged in. Active device has internet access. The stanby device has the LAN cable plugged in but not the internet cable. The ALN port ip address is 10.0.0.6. I cannot access the internet with this LAN  port with ip address. When I ping 8.8.8.8 on cli, it response "connect: Network is unreachable". 

Thanks...

[G_W_Albrecht]

Which documentation did you use for  configuration ? In ClusterXL R81.20 Administration Guide topology both nodes are connected to the internet, see here:

https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_ClusterXL_AdminGuide/Content...

[ikafka]

The documentation for R80.30. My current Gateways versions R80.30.  Everything works on the active device. Only on the stanby device the internet cable is not plugged in. I want to access internet via LAN port without internet cable.
Like any device in the local network (switch, laptop...). Can it follow the blue path in the picture below and access the internet? 

[the_rock]

Lets start with basic routing/networking...so, lets take for example very simple home setup (just as a comparison). You would always get private IP address (non routable). So, in order for you to get online to the Internet, that IP has to route some way egress and way to do it it is through your ISP router, or say 3rd party wi-fi router, which would do the natting, if your ISP router is in bridge mode.

Here, I dont see logically how that IP 10.0.0.6 would be able to connect to the Internet if it cant be natted or has no route anywhere.

Andy

[ikafka]

The gateway of 10.0.0.0.6 is 10.0.0.0.1. 10.0.0.1 is the switch. 10.0.0.0.1 routes all traffic to 10.0.0.0.2 that Firewall cluster ip address. In this case, 10.0.0.0.6 should also connect to the internet with this ip address in this way. Isn't this the expected behavior?

[the_rock]

I dont know your network, so I wont even make a logical assumption. As I can suggest you do is below and compare on both members, it will give you a good idea.

Andy

ip r l

netstat -nr

ip r g 8.8.8.8

Andy

[G_W_Albrecht]

My documentation shows otherwise:

Note the "identical CP security GWs" means HW, used ports and configuration. Please show me where you found the only-one-node-connected-to-ISP configuration ! How should that ever work ?

[the_rock]

I agree 100%, I dont see how this can ever work any other way.

Andy

[ikafka]

Yes, that is  true. I am just asking about a temporary situation. For example: I don not have the FW-2 wan cable right now. In this case, it is impossible to connect fw-2 to the internet. 

[the_rock]

Thats right...they way you have it, it would not be possible.

Andy

[G_W_Albrecht]

So disable ClusterXL and use a single GW during this temporary situation. 

[G_W_Albrecht]

No - the blue road is just not possible when using ClusterXL. You can disable ClusterXL and use fw-2 as a single GW as long as a second WAN cable is not available, but you can not use HA or LS clustering during that time.

[the_rock]

@ikafka I also dont see this working any way how you pasted the screenshot.

Andy

[G_W_Albrecht · Accepted solution]

It could work if he:

- disables ClusterXL for both nodes

- use FW-2 as single GW

- put FW-1 behind FW-2, adapt the config and ruleset accordingly and install the changed policy on both nodes

Now FW-1 could update over FW-2... But i would rather not do that as it is time consuming, prone to errors and will not make ClusterXL work again !

[the_rock]

Right, but then it defeats the purpose of clustering : - (

[G_W_Albrecht]

At the moment, ClusterXL is also not working, so that is not the difference - it just makes no sense at all ! The need: "I just want it to receive updates" does not explain anything, either...

[ikafka]

That is  right. Cluster is not working because FW-2 doesn not have a WAN cable (ISP has not given Port2 for FW-2 wan connection yet.). Only the rules and databbase are the same. This is a temporary situation.

I want to upgrade FW-2 and I want it to get the upfates, which is not possible at the moment. I will import the upgrade files from Gaia and upgrade. Thanks. 

[the_rock]

Put it this way...On Check Point, unlike say Cisco or Fortinet, as there is VIP involved, you have to ensure that all the routes and config matches on backup member, as it wont replicate automatically to standby when you make a change on the active. So, if that cable is unplugged it would make sense why it fails, as Im sure if you were to run command ip r g 8.8.8.8, it would not be reachable.

You can also run below (example from my lab)

[Expert@quantum-firewall:0]# ip r l
default via 172.16.10.103 dev eth0 proto 7
4.205.75.119 via 173.46.3.216 dev eth3 proto 7
10.1.0.0/16 via 169.254.21.1 dev vpnt1 proto 7
169.254.21.1 dev vpnt1 proto kernel scope link src 169.254.21.2
172.16.10.0/24 dev eth0 proto kernel scope link src 172.16.10.205
173.46.3.208/28 dev eth3 proto kernel scope link src 173.46.3.220
192.168.205.0/24 dev eth2 proto kernel scope link src 192.168.205.205
205.195.249.0/24 dev eth1 proto kernel scope link src 205.195.249.1
[Expert@quantum-firewall:0]#

Andy

[ikafka]

I'm with you. I know it's like you said. Temporarily unable to plug in a WAN cable. It's a physical problem. I want internet access to continue until the physical problem is solved. I just want it to receive updates. I know that all ports must be mapped for redundancy!

[the_rock]

Just do traceroute and it will show you where it fails, its that simple.

Andy

[ikafka]

There commands outputs

tracert output:

[Expert@fw2:0]# tracert 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 40 byte packets
sendto: Network is unreachable

ip r l output:

[Expert@fw2:0]# ip r l
10.255.255.0/30 dev eth5 proto kernel scope link src 10.255.255.2
1.1.1.0/30 dev Mgmt proto kernel scope link src 1.1.1.2
10.99.4.0/24 via 10.99.0.1 dev eth1 proto routed
10.99.5.0/24 via 10.99.0.1 dev eth1 proto routed
10.99.6.0/24 via 10.99.0.1 dev eth1 proto routed
10.99.7.0/24 via 10.99.0.1 dev eth1 proto routed
10.99.0.0/24 dev eth1 proto kernel scope link src 10.99.0.6
10.99.1.0/24 via 10.99.0.1 dev eth1 proto routed
10.99.2.0/24 via 10.99.0.1 dev eth1 proto routed
192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.4
10.99.3.0/24 via 10.99.0.1 dev eth1 proto routed
10.99.13.0/24 via 10.99.0.1 dev eth1 proto routed
10.99.14.0/24 via 10.99.0.1 dev eth1 proto routed
10.99.15.0/24 via 10.99.0.1 dev eth1 proto routed
10.99.8.0/24 via 10.99.0.1 dev eth1 proto routed
10.99.9.0/24 via 10.99.0.1 dev eth1 proto routed
10.99.10.0/24 via 10.99.0.1 dev eth1 proto routed
10.99.11.0/24 via 10.99.0.1 dev eth1 proto routed

netstat -nr output:

[Expert@fw2:0]# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.255.255.0 0.0.0.0 255.255.255.252 U 0 0 0 eth5
1.1.1.0 0.0.0.0 255.255.255.252 U 0 0 0 Mgmt
10.99.4.0 10.99.0.1 255.255.255.0 UGD 0 0 0 eth1
10.99.5.0 10.99.0.1 255.255.255.0 UGD 0 0 0 eth1
10.99.6.0 10.99.0.1 255.255.255.0 UGD 0 0 0 eth1
10.99.7.0 10.99.0.1 255.255.255.0 UGD 0 0 0 eth1
10.99.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
10.99.1.0 10.99.0.1 255.255.255.0 UGD 0 0 0 eth1
10.99.2.0 10.99.0.1 255.255.255.0 UGD 0 0 0 eth1
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
10.99.3.0 10.99.0.1 255.255.255.0 UGD 0 0 0 eth1
10.99.13.0 10.99.0.1 255.255.255.0 UGD 0 0 0 eth1
10.99.14.0 10.99.0.1 255.255.255.0 UGD 0 0 0 eth1
10.99.15.0 10.99.0.1 255.255.255.0 UGD 0 0 0 eth1
10.99.8.0 10.99.0.1 255.255.255.0 UGD 0 0 0 eth1
10.99.9.0 10.99.0.1 255.255.255.0 UGD 0 0 0 eth1
10.99.10.0 10.99.0.1 255.255.255.0 UGD 0 0 0 eth1
10.99.11.0 10.99.0.1 255.255.255.0 UGD 0 0 0 eth1

ip r g 8.8.8.8 output:

[Expert@fw2:0]# ip r g 8.8.8.8
RTNETLINK answers: Network is unreachable

Thanks/regards