topic Hosts and DNS Configuration for a 7000 appliance in General Topics

Hosts and DNS Configuration for a 7000 appliance

gemechisd — Sat, 30 Mar 2024 11:01:50 GMT

We have two 7000 security gateways configured as active / standby. When we make the standby gateway active, our end devices won't gate internet access but the gateway itself pings google.com. And now we have cross checked both gateway configurations and found a major difference between HOSTS & DNS TAB.

STANDBY Gateway (PROBLEMATIC GATEWAY)

CP-STANDBY> show host names
Host Name IP Address
CP-STANDBY 7.7.7.3
localhost 127.0.0.1
localhost ::1

ACTIVE Gateway (WORKING GATEWAY)

CP-ACTIVE> show host names
Host Name IP Address
CP-ACTIVE 10.100.100.10
localhost 127.0.0.1
localhost ::1

NOTE THAT: 7.7.7.3 is the management IP address for that gateway.

The Real IP of 10.100.100.11 of the PROBLEMATIC GATEWAY.

10.100.100.10 is the Gateway IP Address for ACTIVE GATEWAY.

7.7.7.2 is the management IP address of the ACTIVE GATEWAY.

Which configuration of HOSTS is correct?

This is an urgent issue and we need your support.

Re: Hosts and DNS Configuration for a 7000 appliance

the_rock — Sat, 30 Mar 2024 16:17:02 GMT

The way I always know that command is that it would show whatever IP is tied to eth0, ie external interface...I checked 2 clients' firewalls and thats what it shows. See example from my Azure lab:

master:

cpazurecluster1> show host names
Host Name IP Address
cpazurecluster1 10.5.0.4
localhost 127.0.0.1
localhost ::1
cpazurecluster1>

backup:

cpazurecluster2> show host names
Host Name IP Address
cpazurecluster2 10.5.0.5
localhost 127.0.0.1
localhost ::1
cpazurecluster2>

Re: Hosts and DNS Configuration for a 7000 appliance

the_rock — Sat, 30 Mar 2024 16:37:35 GMT

To add a comment I forgot before...IF ip addresses are right, do "get interfaces" in smart console, but WITHOUT topology, make sure it fetches correct info, install policy, do failover test.

Andy

Re: Hosts and DNS Configuration for a 7000 appliance

AmirArama — Sun, 31 Mar 2024 10:09:19 GMT

i'm not sure the hosts are related, but in order to investigate what is going on you can do the following:

first, i assume your cluster is in active/standby mode (healthy cluster).

1. prepare some workstation for testing

2. switch between cluster members

3. now from the workstation, run: ping 9.9.9.9

3.A if the ping doesn't work (no replies) do this:

A. run on both members the following command:

fw monitor -F "0,0,9.9.9.9,0,0" -F "9.9.9.9,0,0,0,0"
(https://support.checkpoint.com/results/sk/sk30583)
the filter used here with 9.9.9.9 is an example of internet address, and i'm filtering it once on the destination side (original connection), and once on the source side (for reply).
you can replace 9.9.9.9 with any internet ip address you want to test.

*the reason i tell you to run on both, it to verify that the traffic from workstation to internet and the replies are flowing only through the new active member, and not via the old active member (such as when the old ARP is stuck on some network device). once that's verified you can run only on the active member for the next tests.

B. copy all the outputs from both members to notepad, note which is active and which is standby.

3B. if the above ping worked, try to ping something that needs resolving, like ping cnn.co

if that doesn't work, figure out who is configured on the workstation as DNS server, and we will go from there:

A. if it's internal server, try to look for logs from that dns server to the internet, or between the workstations to this dns server.

B. you also can use the same fw monitor with custom filter to this dns server traffic).

4. if the ping to domains also works and you have resolving, but you can't open http/https pages than do the same fw monitor above and this time open browser and brose to http://9.9.9.9 or https://9.9.9.9

copy all outputs and paste here.

break fw monitor with ctrl+C

once you find what exactly doesn't work, you can also run fw ctl zdebug + drop on the active member let it run for 30sec, while you simulate the non working connection, copy and paste the output here.
break fw ctl zdebug + drop with ctrl+c
and then run: fw ctl debug 0 to reset the debugging.
(notice the zdebug consume CPU, so make sure you do that on proper maintenance window)

in addition to that looks for the logs for the non working connections (some for example), you can also take screenshots and paste here.

mention your workstation IP. and the non working connection you have tested while running fw monitor or debug.