Check Point vsec virtual ARP not updated on VMware hosts

[dehaasm]

We have a cluster R80.40 installed on VMWARE in ESX server and the three options are configured on all VLANS, forged transmit, promiscuous mode and mac learning on accept.

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

currently the VMAC is not enabled so after failover we depend on ARP(MAC) address update on the surrounding hosts. Whenever we do a failover to activate the next member, the hosts are receiving the traffic but they still respond to the old (now STANDBY) gateway.

So the fact is that for some reason their default gateway MAC address is still pointing to the old firewall. The problem is not on a single server but many hosts all have the same issue and became unreachable.

What could be the cause of the old gateway MAC address being stuck on the servers in VMWARE?

note: this perhaps aint a CP issue but perhaps someone has experience dealing with the same issue.I know enabling VMAC would resolve the MAC change but we want to find the root cause of this issue.

[Chris_Atkinson]

Is something filtering the GARPs sent from the gateway on failover, do you see them in a packet capture upon failover at an affected host?

[_Val_]

Second GARP question.

[dehaasm]

Yes that is something that i am figuring out, trying to send the G-ARP manually would be a nice test indeed

[Ruan_Kotze]

Don't think this is a CP issue as such, but you can force your gateway to send g-arps with "arping". 

So let's say your gateway IP is 1.2.3.4 the command will be arping -c 4 -A -I eth1 1.2.3.4

[Rafael_Lima2]

Hi dehaasm,

Did you find a solution to the issue? I've the same issue in a cluster using vSec gateways too.

[dehaasm]

Hi Rafael,

We performed a normal failover with and without vmac enabled on R80.40. Our conclusion is that without vmac and just relying on the ARP update it works perfectly, the servers are updating their ARP table directly with new mac address of the activated CP gateway. Strangely enough when we enable VMAC the servers also correctly updated the ARP table, however when performing a failover it takes about 1 minute before communication starts to work and we tested this several times (vmac only depends on network switches to learn the same MAC address from the other firewall), we didnt have time to investigate this. Coming back to our problem knowing that the normal failover works perfectly witouth using VMAC, it caused issues when we upgraded to R81.10 take 87 so we suspect the CP gateway not to send the ARP updates properly. We will investigate further and also try to solve this by manually sending the arping command.

[Chris_Atkinson]

Sorry to clarify, the above appears to contradict your original post?

[dehaasm]

Hi Chris, Yes sorry about that I was assuming (including the end user) that they always have this issue after performing a failover, however after advanced testing last night it appears to work properly. Some weeks ago we tried to upgrade one member to version r81.10 take 87 and tried to failover and I confirmed that the replies from the servers arrived on the standby firewall. Therefor I can conclude that the ARP update wasnt properly send from the upgraded member to inform the servers that it is now the gateway, I used MVC method and cluster was always working.

Sorry for the confusion I should modify the question to include that this is only occuring with upgrade for some reason. Are there any known issues regarding this in version R81.10?

[Chris_Atkinson]

There are some MVC fixes in the JHF but nothing that matches based solely on ARP that I can see.

Also just because it doesn't arrive doesn't mean it wasn't sent so further isolation is required to validate.