Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Hamza
Participant

Automatic Proxy ARP on VSX R80.40

Jump to solution

Hi all,

We did have an issue with the Automatic Proxy ARP configuration.

After all troubleshooting we decided to put the Manuel Proxy arp configuration and it worked right away.

Im still confused on how to configure the Automatic Proxy configuration for manuel NAT rules :

Server Manager --> NAT  -- > Automatic NAT configuration -- > Merge Manuel Proxy ARP configuration :

or 

Using the sk114395 where you have to modify the file : $CPDIR/tmp/.CPprofile.sh

Thanks

0 Kudos
Reply
1 Solution

Accepted Solutions
_Val_
Admin
Admin

Let's do this from the start.

  1. Proxy ARP entries allow FW to answer ARP requests on IP addresses that do not belong to FW itself, but to other servers under NAT.
  2. Proxy ARP entries can be created automatically by FW itself for Automatic NAT rules, where static NAT IP is defined on the object itself, or manually, by administrators, by manually editing a special file, or from Gaia CLI.
  3. If both manual ARP entries and automatic ARP is used, you need to enable "Merge manual proxy ARP config" for correct operation. Quoting from the Help manual:
    Merge manual proxy ARP configuration merges the automatic and manual ARP configurations. Manual proxy ARP configuration is required for manual Static NAT rules. If a manual ARP configuration is defined in the local.arp file and Automatic ARP configuration is enabled, both definitions are maintained. If there is a conflict between the definitions (the same NAT IP address appears in both), then the manual configuration is used. If this options is not enabled and Automatic ARP configuration is enabled, the Security Gateway ignores the entries in the local.arp file.
  4. Proxy ARP is mostly needed for DMZ servers, where external users are accessing them from Internet. In theses cases, we are talking about Destination, not Source, NAT
  5. Source NAT means you you are doing manual static NAT translation for servers accessing Internet.

sk30197 describes multiple procedures to create manual ARP entries for different implementation cases.

sk114395 provides you with a new way to create manual ARP entries in a limited case of Source NAT only. Not in any circumstances should you consider sk114395 being a replacement of "Merge manual proxy ARP" option. Even if you are using sk114395, you should still enable that option in case you have both manual and automatic ARP entries on you FW.

View solution in original post

10 Replies
_Val_
Admin
Admin

Did you look into sk30197 before anything else?

0 Kudos
Reply
Reevsie147
Contributor

Hi @Hamza ,

When you mention Automatic Proxy ARP, are you referring to Proxy ARP entries being automatically created for Manual NAT rules (manually defined in the NAT policy) or are you referring to Automatic NAT rules? (where you set the NAT properties within the properties of the network object itself)

 

0 Kudos
Reply
Hamza
Participant

Yes im refering to Proxy ARP entries bieng automatically created for manual rules defines in NAT Policy.

So my question is to know the difference between the two configuration. And which is the right one to use :

following the sk114395

or from the SMS by checking the boxes Automatic NAT configuration -- > Merge Manuel Proxy ARP

0 Kudos
Reply
Reevsie147
Contributor

Hi @Hamza , I'm by no means an expert, but from my understanding, "Merge Manual Proxy ARP" will combine manually created ARP entries (created in GAiA WebUI or cli or previously via $FWDIR/conf/local.arp) with the Proxy ARP entries created by using Automatic NAT (where you define the NAT on the network object rather than a manual NAT rule which automatically adds a Proxy ARP entry) and allows you to use both methods simultaneously.

My understanding of sk114395, is that this feature now creates these previously manual Proxy ARP entries automatically (at least for Source Manual NAT). If I'm correct, this would mean that you wouldn't have to manually add the Proxy ARP entry as you mentioned you did in order to make it work.

@_Val_ is vastly more experienced than myself however so maybe he can confirm or correct this understanding

0 Kudos
Reply
_Val_
Admin
Admin

@Reevsie147 
Before commenting on the sk114395 procedure, I need to understand if @Hamza actually read and followed the default recommended procedure from sk30197.

"Merge Manual Proxy Arp" will not lead to creating automatic entries for manual NAT rules. sk114395 is only applicable to specific scenarios and for source NAT rules exclusively. It is not an ultimate replacement of manual proxy ARP method.

0 Kudos
Reply
Hamza
Participant

Hello VAL,

I did read the sk114395 and sk30197.

from what i understand; these options are doing the same thing  :

Automatic ARP Configuration 

sk114395 (source NAT) : by modifying the file $CPDIR/tmp/.CPprofile.sh : but Most cases where we use Proxy ARP in our Production is for source NAT

Manual proxy ARP configuration

This is based on the Note on the sk30197 : 

If "Automatic ARP configuration" setting is enabled, but "Merge manual proxy ARP configuration" setting is not enabled, then the Security Gateway ignores the Proxy ARP entries in the $FWDIR/conf/local.arp fil"

Still cannot see the difference between these options. Or maybe there are 3 oprions to configure Proxy ARP ?

Hamza

 

0 Kudos
Reply
_Val_
Admin
Admin

Absolutely not the same thing. 

0 Kudos
Reply
_Val_
Admin
Admin

Let's do this from the start.

  1. Proxy ARP entries allow FW to answer ARP requests on IP addresses that do not belong to FW itself, but to other servers under NAT.
  2. Proxy ARP entries can be created automatically by FW itself for Automatic NAT rules, where static NAT IP is defined on the object itself, or manually, by administrators, by manually editing a special file, or from Gaia CLI.
  3. If both manual ARP entries and automatic ARP is used, you need to enable "Merge manual proxy ARP config" for correct operation. Quoting from the Help manual:
    Merge manual proxy ARP configuration merges the automatic and manual ARP configurations. Manual proxy ARP configuration is required for manual Static NAT rules. If a manual ARP configuration is defined in the local.arp file and Automatic ARP configuration is enabled, both definitions are maintained. If there is a conflict between the definitions (the same NAT IP address appears in both), then the manual configuration is used. If this options is not enabled and Automatic ARP configuration is enabled, the Security Gateway ignores the entries in the local.arp file.
  4. Proxy ARP is mostly needed for DMZ servers, where external users are accessing them from Internet. In theses cases, we are talking about Destination, not Source, NAT
  5. Source NAT means you you are doing manual static NAT translation for servers accessing Internet.

sk30197 describes multiple procedures to create manual ARP entries for different implementation cases.

sk114395 provides you with a new way to create manual ARP entries in a limited case of Source NAT only. Not in any circumstances should you consider sk114395 being a replacement of "Merge manual proxy ARP" option. Even if you are using sk114395, you should still enable that option in case you have both manual and automatic ARP entries on you FW.

View solution in original post

Hamza
Participant

Hello Val,

This is much more clear now : The option " Automatic creation of Proxy ARP entries option in the SMS is applicable only for Automatic rules)

For me and it make sense with the response that i received from TAC today :

 " If we want automatic proxy arp creation for manuel NAT rule we need to modify the file  $CPDIR/tmp/.CPprofile.sh "

The LAST points under investigation with TAC team  : is why automatic creation of proxy ARP is working for manuel NAT rules without editing the file  $CPDIR/tmp/.CPprofile.sh and without entries in local.arp in one of our firewalls (VSX R80.40 / 7000 appliance)

Hamza

0 Kudos
Reply
Hamza
Participant

Hello,

Actually automatic creation of proxy ARP was not working for manuel NAT at all, i discovered that we were Nating to the IP address of the interface , and the incoming NAT was not working too.

Thank you Val for all explanations.

Hamza

0 Kudos
Reply