PA device responds to unwanted ARP requests

[serwis.nge]

Hi,

I've stumbled upon a tricky situation that I've managed to resolve but still don't know why PA did what it did.

The scenario is as follows:

1) Internet traffic comes into PA from the WAN zone, internal users use the LAN zone.

2) There is a DMZ switched VLAN. PA has an L3 interface in that VLAN with an IP of 192.168.0.1. This interface is in the DMZ zone.

3) In the DMZ there is a server 192.168.0.2 and a proxy 192.168.0.3.

4) The goal is to enble people from the WAN and LAN zone to communicate with the web service on the server through a proxy.

5) Any necessary security policies are ok.

To accomplish that I've set up a destination NAT policy that translates traffic incoming from any zone to the DMZ zone to port 80 from dest.ip 192.168.0.2 to dest.ip 192.168.0.3.

And here is the tricky part I don't understand. After commiting this rule and issuing a ping from PA device (or after a while when the ARP cache expires) PA device starts to reply to ARP requests for the IP 192.168.0.2 hence breaking the communication to the server from any other machine in the DMZ. ARP table on proxy states that indeed the server's IP is at the PA MAC, and on the PA's ARP table flag of 192.168.0.2 is "incomplete".

When I changed the NAT rule to: from zone (LAN or WAN) to zone DMZ; everything is OK.

I thought that any firewall would response to an ARP request only if it had the requested IP configured on one of it's interfaces or if it had a source NAT configured with the IP address in question. So how come PA did respond to those ARPs ?

Any insight will be welcome 🙂

[andreip]

Hello!

Assuming that there was no bidir (source static nat) or U-Turn entanglement, which was the source IP you used for ping (I presume you used 192.168.0.1, the firewall's interface in DMZ and not and not the management interface having a service route to DMZ destination) ?

Have you tried to ping with LAN firewall's interface source IP in the faulty setup ?

If you used DMZ interface source IP, due to the double forwarding lookup and the incoming and outgoing interface being the same, the firewall might just answered to itself that server (192.168.0.2) can be reached using DMZ interface as next-hop - a debug dataplane packet-diag set log feature flow basic and arp for non-ip packet-filter would have explained the forwarding decision (I couldn't replicate the symptom using a 7.0 VM).

Hope that helps, andreip