Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Reevsie147
Contributor

Automatic Proxy ARP issue on R80.40

Jump to solution

Hi all,

Am having a bit of an odd issue with automatic proxy ARP on an R80.40 cluster and was wondering whether somebody maybe able to shed some light on it?

Whenever I configure an automatic NAT rule and push the policy, the firewall seems to be applying a strange MAC address to the proxy ARP entry shown when I run "fw ctl arp":

(x.x.x.150) at 00-00-00-00-64-65 interface x.x.x.5

(Note: I have obfuscated the IP addresses but they are correct)

This is also verified if I look at the arp table on my upstream router:

x.x.x.150 ether 00:00:00:00:64:65 C eth1

It doesn't seem to matter what automatic entries I make, they all seem to show the same odd MAC.

If I create a manual NAT rule, define a manual Proxy ARP entry in GAiA and push the policy, it works fine and shows the MAC of the active cluster member:

(x.x.x.150) at 00-0c-29-90-3f-bf

The strange MAC seems to look like a little like a Magic MAC that ClusterXL used to use and I've tried to find references to it but it doesn't seem like any of the old commands (cphaconf cluster_id get or cphaprob mmagic) seem to work in R80.40 anymore so it's somewhat difficult to verify.

If anyone had any debugging tips or ideas as to why this is happening I'd really appreciate your insight!

 

0 Kudos
Reply
1 Solution

Accepted Solutions
PhoneBoy
Admin
Admin

It sounds like the TAC should be involved.

View solution in original post

0 Kudos
Reply
6 Replies
PhoneBoy
Admin
Admin

With the weird MAC, is it actually working (the NAT, I mean)?

0 Kudos
Reply
Reevsie147
Contributor

Hey @PhoneBoy ,

Alas, no, it doesn't!

I see the weird MAC in the ARP table on the upstream router and the firewall actually replies to ARP requests with the same MAC:

tcpdump -eni eth0 arp | grep x.x.x.150

19:53:07.362530 00:0c:29:3c:62:b9 > Broadcast, ethertype ARP (0x0806), length 60: Request who-has x.x.x.150 tell x.x.x.2, length 46
19:53:07.362677 00:0c:29:90:3f:bf > 00:0c:29:3c:62:b9, ethertype ARP (0x0806), length 60: Reply x.x.x.150 is-at 00:00:00:00:64:65, length 46

Any actual connections to the x.x.x.150 address just never actually reach the firewall or are visible in the logs/tcpdump/fw ctl zdebug + drop on that interface.

I'm just really stumped where it's pulling that MAC from. It's not showing under any interface on a ifconfig -a and I'm not using VMAC mode for ClusterXL so I don't think it will be coming from there either.

Any advice would be greatly appreciated.

Not sure whether this would make a difference but this is Cloudguard IaaS on VMware installed from the latest R80.40 image and fully up to date on the JHFA front.

0 Kudos
Reply
PhoneBoy
Admin
Admin

It sounds like the TAC should be involved.

View solution in original post

0 Kudos
Reply
Reevsie147
Contributor

Thanks @PhoneBoy , only issue is that this is currently on an evaluation license (running as a PoC for CloudGuard IaaS), will TAC accept a ticket under an eval? Or will I have to get these licensed first?

Apologies, just never logged a ticket for an eval before so not sure if it's possible.

Many thanks.

0 Kudos
Reply
PhoneBoy
Admin
Admin

As long as you have a support agreement in place, it shouldn't be an issue.

0 Kudos
Reply
Reevsie147
Contributor

We do indeed.

OK great, I'll go ahead and get a case raised then.

Many thanks again for your help!

0 Kudos
Reply