- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Re: Automatic Proxy ARP issue on R80.40
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Automatic Proxy ARP issue on R80.40
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!
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It sounds like the TAC should be involved.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
With the weird MAC, is it actually working (the NAT, I mean)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It sounds like the TAC should be involved.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As long as you have a support agreement in place, it shouldn't be an issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We do indeed.
OK great, I'll go ahead and get a case raised then.
Many thanks again for your help!