Default route on Standby Member not showing

[Ashutosh_Mishra]

Default route on Standby Member not showing once i checked configuration default route command is configured and trying to ping 8.8.8.8 error is Network is unreachable meanwhile active member working fine.

[Vladimir]

It is perhaps the same issue as described here, I suspect and should be resolved using same methods:

https://community.checkpoint.com/message/13566-re-problem-accessing-standby-cluster-member-from-non-... 

[Kaspars_Zibarts]

Most likely connectivity to the next hop is lost. Check your next hop that's defined on default route.

[Ashutosh_Mishra]

Hi Kaspars,  Next hop is same as active member 

In active member default route is showing but not showing on standby member

[Vanesa_Benito_O]

Hi! I had the same issue a few weeks ago, do you have the ping option enablen in the static route? are you using more than one default route?

[Ashutosh_Mishra]

Hi Vanesa,  yeah i enabled ping on static route and i'm using single default route

[Vanesa_Benito_O · Accepted solution]

If you had the same issue that mine, the default route in the standby member appeared when you disable the ping option.

I have two default route so... this option was necesary for me... (I had to install the hotfix 142 but it isnt in GA yet)

PMTR-12798, PMTR-10503

Routing

Enabling ping option for static routes causes the routes to disappear on the standby member.

Regards!

[Ashutosh_Mishra]

Hi Vanesa,

Many many thanks to you , As of now issue resolved. i disabled ping on default route both firewall have default route.

Thanks again for your support !

[Vladimir]

Looks like this issue is addressed in the Jumbo Hotfix Take 154 released just now:

Routing

Enabling ping option for static routes causes the routes to disappear on the standby member.

[Ashutosh_Mishra]

Thanks Vladimir, Update showing in CPUSE, Will install As soon as possible.

[Jerry]

interesting as I've got similar one just now, take a quick look and imagine (R80.10 Take 154 Physical 5200 appliances)

1. you've got ClusterXL with only 1 member having single eth3 interface used for something totally none-clustered

2. you've got eth3 configured as 10.10.10.3/29 and your next hop towards some 192.168.16.0/24 network is 10.10.10.4

3. you did a clish route

4. you wanna see netstat -anr or route -n and your outputs are as following:

CP01> show configuration static-route
set static-route 192.168.16.0/24 nexthop gateway address 10.10.10.4 on

[Expert@CP01:0]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.10.10.0      0.0.0.0         255.255.255.248 U     0      0        0 eth3
0.0.0.0         a.b.c.d  0.0.0.0         UGD   0      0        0 eth1   

what you think folks? I just don't seem to see configured route in a kernel table (install/push was done few times - no change)

what is wrong with that route that it does not appear in a kernel routing table?

I cannot even verify that I can reach 10.10.10.4 as I constantly see arp broadcast over the eth3 from of my interest 192.168.16.0 network:

0:49:11.474796 00:0c:29:5d:53:45 > Broadcast, ethertype IPv4 (0x0800), length 243: 192.168.16.98.netbios-dgm > 192.168.16.255.netbios-dgm: NBT UDP PACKET(138)
00:49:11.659178 00:09:0f:dc:2e:0d > Broadcast, ethertype ARP (0x0806), length 60: arp who-has 192.168.16.21 tell 192.168.16.10
00:49:12.203831 c8:cb:b8:32:a7:64 > Broadcast, ethertype ARP (0x0806), length 60: arp who-has 192.168.16.21 tell 192.168.16.171
00:49:12.659180 00:09:0f:dc:2e:0d > Broadcast, ethertype ARP (0x0806), length 60: arp who-has 192.168.16.21 tell 192.168.16.10
00:49:12.677339 c8:cb:b8:32:a5:9e > Broadcast, ethertype ARP (0x0806), length 60: arp who-has 192.168.16.21 tell 192.168.16.185
00:49:12.683713 58:38:79:06:e8:aa > Broadcast, ethertype ARP (0x0806), length 60: arp who-has 192.168.18.195 tell 192.168.16.20
00:49:12.708609 58:38:79:06:e8:aa > Broadcast, ethertype ARP (0x0806), length 60: arp who-has 192.168.18.172 tell 192.168.16.20
00:49:12.794152 c8:cb:b8:32:a5:4c > Broadcast, ethertype ARP (0x0806), length 60: arp who-has 192.168.16.21 tell 192.168.16.142
00:49:12.875228 c8:cb:b8:30:1e:19 > Broadcast, ethertype ARP (0x0806), length 60: arp who-has 192.168.16.21 tell 192.168.16.191
00:49:12.954510 64:ae:0c:f1:8c:10 > Broadcast, ethertype IPv4 (0x0800), length 198: 192.168.16.248.4554 > 192.168.16.255.4554: UDP, length 156
00:49:13.138192 c8:cb:b8:32:a7:64 > Broadcast, ethertype ARP (0x0806), length 60: arp who-has 192.168.16.21 tell 192.168.16.171
00:49:13.290692 64:ae:0c:f1:90:60 > Broadcast, ethertype IPv4 (0x0800), length 198: 192.168.16.249.4554 > 192.168.16.255.4554: UDP, length 156

I don't beleive I've done any misconfig but I would appreciate any heads up on that matter folks.

Seems my route does not exist in a kernel but config ist jus fine

ps.

[ExpertCP01:0]# cphaprob -a if

Required interfaces: 4
Required secured interfaces: 1

eth1       UP                    non sync(non secured), multicast
eth3       Disconnected          non sync(non secured), multicast

but

[Expert@CP01:0]# ethtool eth3
Settings for eth3:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: pumbg
        Wake-on: d
        Current message level: 0x00000007 (7)
        Link detected: yes

Any clues ?

[Vladimir]

Well, it will only show route if the interface is connected and the next hop reachable.

If you cannot get to the 10.10.10.4, I'd suggest looking into that.

Possible misconfiguration on the switch side. I.e. access instead of trunk, incorrect VLAN membership, no IP assigned to the VLAN interface, etc...

[Jerry]

Thanks Vlad but ...

1. there is no switch in between - just int to int between one firewall and another (Fortigate <-> CheckPoint)

2. there are no L2 configs - just plain static route but when querried ip r g 192.168.16.0 it shows totally diff. direction - via eth1 (wrong!)

3. L1 is just fine (links are up) and both interfaces are blinking green

next hope should be reachable as it is configured plainly as eth1 on Forti with 10.10.10.4/29 with static route against nets behind CP with next hope 10.10.10.3

any ideas chaps?

[Vladimir]

Tell me if the eth3 is defined in the cluster topology as a "Non-clustered monitored" interface.

[Jerry]

eth3 is indeed defined as "Private" as it is not Clustered nor Sync interface.

thing is that this Fortigate 80C is driving me mad already, got routes in place, acl's in place on both FWs but still no go,

arp table on CP Cluster shows mac from 10.10.10.4 hosts on respectful interface:

[Expert@CP01:0]# arp -an
? (10.10.10.4) at 00:09:0F:DC:2E:13 [ether] on eth3

but still I'm not only unable to ping above host but olso not able to ping anything behind (192.168.16.0/24 net) which is a desirable goal here

[Vladimir]

If you have a physical access to the equipment, why not connect directly to the Fortigate's port from the laptop and determine if it is working as intended?

I do not think that the cphaprob -a if should be showing "Disconnected".

The problem may very well be in Fortigate's config.

[Jerry]

I'll find out next week just made following recommendations to the "Fortigate Team" in New Zeland

- connect little 4-8 port switch to the Fortigate DMZ Port

- connect pachcords between two eth3 ports from CheckPoints to the swithc

- connect pachcord between one dmz port from Frotigate to the switch

- let me know when done

I've made a Cluster with VMAC on ClusterXL with 10.10.10.1 (2/3 physicals) and let's see how it goes when little switch arrives

Unfortunately I have no ways ot flying over there just for few days (not now!) as this site is very remote (Hamilton NZ) and the IT Team is just on-demand helping me with the migrations.

Thanks Vlad anyway, I'll keep you posted when next week "little netgear switch" won't solve my problems. I do know that theoretically it should work but this is the peering ClusterXL with Fortigate over 1G cooper port  super simple and complicated at the same time LOL

have a good weekend!

[Vladimir]

Beware of the "little netgear switch(es)", those suckers are known to be flaky.

Just had three of those yanked out from my home lab and replaced with Meraki gear.

[Jerry]

ok. here is a proper update for you all, should anyone knows what a heck I'm doing wrong (*wink*) - do let me know

obviously I was following IN DETAIL sk86582 but,:

exec ping 10.10.10.1 (from Fortigate CLI on 10.10.10.4)

5 packets transmitted, 0 packets received, 100% packet loss

whilst on zdebug on CP Cluster:

;[cpu_1];[fw4_0];fw_log_drop_ex: Packet proto=1 10.10.10.4:2048 -> 10.10.10.1:5649 dropped by vpn_drop_and_log Reason: Clear text packet should be encrypted;

when $FWDIR/lib/crypt.def (on SMS + successfuly pushed is like following:

vpn_exclude_src1={<192.168.16.0,192.168.16.254>};

vpn_exclude_dst1={<a.a.a.1,a.a.a.254>};

vpn_exclude_src2={<10.10.10.0,10.10.10.255>};

vpn_exclude_dst2={<10.10.10.0,10.10.10.255>};

vpn_exclude_src3={<a.a.a.1,a.a.a.254>};

vpn_exclude_dst3={<192.168.16.0,192.168.16.254>};

with following in a proper place as well:

((src in vpn_exclude_src1) and (dst in vpn_exclude_dst1)) and ((src in vpn_exclude_src2) and (dst in vpn_exclude_dst2)) and ((src in vpn_exclude_src3) and (dst in vpn_exclude_dst3))

ps. all in right space, spot and policy installed - just simply DOES NOT WORK and I cannot ping whatever direction I'll take based on the exclude_objects from above.

any clue chaps ?

[Jerry]

also:

[Expert@CP01:0]# tcpdump -nni any host 10.10.10.4
tcpdump: WARNING: Promiscuous mode not supported on the "any" device
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
01:29:02.431263 IP 10.10.10.4 > 10.10.10.3: ICMP echo request, id 512, seq 0, length 64
01:29:03.422064 IP 10.10.10.4 > 10.10.10.3: ICMP echo request, id 512, seq 256, length 64
01:29:04.421712 IP 10.10.10.4 > 10.10.10.3: ICMP echo request, id 512, seq 512, length 64
01:29:05.421711 IP 10.10.10.4 > 10.10.10.3: ICMP echo request, id 512, seq 768, length 64
01:29:06.421711 IP 10.10.10.4 > 10.10.10.3: ICMP echo request, id 512, seq 1024, length 64
01:29:07.421659 arp who-has 10.10.10.3 tell 10.10.10.4
01:29:07.421688 arp reply 10.10.10.3 is-at 00:1c:7f:83:2f:76