Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Maarten_Sjouw
Champion
Champion

Proxy ARP after upgrade to R80.30

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.

Regards, Maarten
15 Replies
FedericoMeiners
Advisor

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!
____________
https://www.linkedin.com/in/federicomeiners/
0 Kudos
Maarten_Sjouw
Champion
Champion

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.
Regards, Maarten
FedericoMeiners
Advisor

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,

____________
https://www.linkedin.com/in/federicomeiners/
0 Kudos
Maarten_Sjouw
Champion
Champion

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

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

thanks

Peter

0 Kudos
FedericoMeiners
Advisor

We have not opened a TAC case for this, just applied the solution from Maarten.
____________
https://www.linkedin.com/in/federicomeiners/
Maarten_Sjouw
Champion
Champion

We have a case open with TAC.
Regards, Maarten
0 Kudos
Marco_Valenti
Advisor

bump

0 Kudos
Maarten_Sjouw
Champion
Champion

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)
Regards, Maarten
0 Kudos
FedericoMeiners
Advisor

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,

____________
https://www.linkedin.com/in/federicomeiners/
0 Kudos
Vladimir
Champion
Champion

bump

0 Kudos
Ilya_Yusupov
Employee
Employee

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

 

0 Kudos
Peter_Lyndley
Advisor
Advisor

Please let us know when this fix is available and in what JHF if possible
0 Kudos
Ilya_Yusupov
Employee
Employee

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 

0 Kudos
Er0chan
Explorer

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

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events