proxy_arp_pvlan

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

proxy_arp_pvlan

L1 Bithead

Hi all,

 

I was dealing with a scenario recently which I eager to use the Palo Alto firewalls.

In my design, it is a must to use the feature which is called ARP alias in Cisco terms, and ARP publish in Juniper terms. In case of Linux as Palo Alto is using is proxy_arp_pvlan.

the explanation regarding to the proxy_arp_pvlan is as follows which is derived from the kernel.org:

proxy_arp_pvlan - BOOLEAN
	Private VLAN proxy arp.
	Basically allow proxy arp replies back to the same interface
	(from which the ARP request/solicitation was received).

	This is done to support (ethernet) switch features, like RFC
	3069, where the individual ports are NOT allowed to
	communicate with each other, but they are allowed to talk to
	the upstream router.  As described in RFC 3069, it is possible
	to allow these hosts to communicate through the upstream
	router by proxy_arp'ing. Don't need to be used together with
	proxy_arp.

	This technology is known by different names:
	  In RFC 3069 it is called VLAN Aggregation.
	  Cisco and Allied Telesyn call it Private VLAN.
	  Hewlett-Packard call it Source-Port filtering or port-isolation.
	  Ericsson call it MAC-Forced Forwarding (RFC Draft).

I have test the proxy_arp_pvlan scenario with my linux-router running Debian and it works like a charm.

The test case scenario is as follows:

there are two client which are in a same subnet isolated by private VLAN (PVLAN) in the switch. According they cannot talk to each other directly.

However, my upstream router which has the promiscuous port (Linux router) is set with the proxy_arp_pvlan to reply on isolated clients. The advantage of this case is that we can take control of the intra_vlan communication via the upstream router which in my case needs to be Palo Alto firewall.

In Cisco terms, it is called ARP aliasing.

 

My question is, as the Palo Alto is using the Linux under the hood, is there anyway to enable Palo Alto to respond to ARP request for the isolated clients which needs to communicate with one another?

 

It worth mentioning that, it is not feasible to use the community PVLAN as I need to inspect the traffic with firewall.

 

any help is much appreciated.

 

3 REPLIES 3

Cyber Elite
Cyber Elite

@seek_2,

It's been a while since I ran into a situation like this, so my information may be out of date, but I don't believe that this feature is exposed on the firewall outside of NAT rulebase entries which use proxy ARP behind the scenes. The last time that I ran into a situation where we had to make this work directly on the firewall we essentially had to get creative with our NAT rulebase to get things to function how the client expected. 

Hopefully someone has a better answer for you, but you can make things work through NAT if necessary. 

Hi @BPry 

I would like to thanks for your response and the solution.

However, as Palo Alto is using Linux in the backend, I think if they decide to enable the proxy_arp_pvlan in the linux proc file, it would be a great advantage and feature-set for the Palo Alto firewall.

 

Any other feedback regarding how to access the Palo Alto /proc file is much appreciated to enable it manually.

 

Thanks

@seek_2 
You would need to put in a feature request with your SE. Customers do not have access to the underlying operating system of the firewall, so manually enabling this isn’t going to be an option. 

  • 4856 Views
  • 3 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!