Proxy ARP after upgrade to R80.30

[Maarten_Sjouw]

This week we had some clusters upgraded from R80.10 to R80.30, the customer wants the new and improved HTTPS functionality.

When we were done, on 2 VRRP clusters we had some automatic NAT and a special Hide NAT (for WiFi guests) After upgrading you install the policy twice, first the acces and then again for the Threat Prevention policy.

After some time we were told the Guest WiFi did not work, investigation pointed in the end to the proxy ARP that was not active, so we added the Proxy ARP command for the Hide address, pushed the access policy (the third time). After looking with fw ctl arp we then saw 2 Proxy ARP addresses, the one we added and the other was a automatic NAT.

After removing the manual Proxy ARP again, the fw ctl arp kept showing both ARP entries.

When we upgraded the other cluster we checked again after 1, 2 and 3 pushes of the access policy and only after the third push the Proxy ARP addresses showed up.

It has been reported and R&D will be informed.

[FedericoMeiners]

Last friday we performed a gateway migration from R80.10 to R80.20 via a fresh install and some published services that needed Proxy ARP stopped working (Not all), as soon as we performed a failover to the cluster member with R80.10 everything was working again.

The traffic from these servers passes the firewall but never "came back".

We could not perform too much troubleshoot since our maintenance window was ending but now that you mention this it could be related, we are not using VRRP although.

This week we are going directly to try R80.30 and will keep in mind your solution.

Thanks for sharing!

[Maarten_Sjouw]

This morning I needed to reboot these gateways due to some TLS issues we are having, therefore we needed to flip the cluster (VRRP) over, after the switch we found that the Proxy ARPs are gone.
Case is open.

[FedericoMeiners]

Hello everyone,

As stated, today we upgraded one of the members to R80.30 and we had the same issue as in R80.20, this time we could verify that it was an ARP issue only affecting in the Proxy ARP configuration.

It seems like magic but as soon as we pushed policies for the third time the affected services started to work, and the output of fw ctl arp was complete.

If R80.30 is stable we will upgrade the other member by monday 22/7, I'm really eager to see how this issue is handled after failovers, will update afterwards.

Regards,

[Maarten_Sjouw]

After the failover we checked and fw ctl arp did not show anything, but after 1 policy push it worked again.

[Peter_Lyndley]

Did anyone get any response from TAC about why this happens and how to avoid it ?

thanks

Peter

[FedericoMeiners]

We have not opened a TAC case for this, just applied the solution from Maarten.

[Maarten_Sjouw]

We have a case open with TAC.

[Marco_Valenti]

bump

[Maarten_Sjouw]

Are you guys using clusters while having these problems and if so which type of cluster? VrRRP or ClusterXL?
When you flip the cluster is the Proxy ARP moving along with the cluster master? (Check with fw ctl arp on both members)

[FedericoMeiners]

Maarten,

In our case we are using ClusterXL and this behaviour happened with R80.20 and R80.30 (The other member is in R80.10). During the first test with R80.20 we could not see the output of fw ctl arp, but after seeing your post we checked the fw ctl arp state of the active cluster in R80.10, as soon as we generated the failover with cphastop the output of the same command was by far incomplete compared to the other member with standby member of R80.10.

After the third policy push fw ctl arp output was properly complete and our switches started to see the correct MAC.

Regards,

[Vladimir]

bump

[Ilya_Yusupov]

Hi all,

We found an issue with Cluster VRRP and we are working on a fix.

if someone encounter same issue on none VRRP environment can he please contact me offline so we can investigate the system?

iliay@checkpoint.com

[Peter_Lyndley]

Please let us know when this fix is available and in what JHF if possible

[Ilya_Yusupov]

Hi,

currently we have the fix as HF so customers that encounter with this issue can open ticket to get the fix.

the fix will be included on future JHF.

Thanks,

Ilya 

[Er0chan]

We have a similar situation encounter.

We currently has a cluster of R77.20 and going to upgrade to R80.20
We upgraded the Standby GW and force it to be Active, then we make some traffic testing.
After test, we find that the upgraded GW seems cannot response the ProxyArp configurated, but when we failover the traffic to the R77.20 GW, everything work fine.

Later on, we decide to upgrade the rest R77.20 to R80.20, after all the GW upgraded, both the GW start to response to the ProxyARP configurate.