Enhanced Security Measures in Place:   To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.

Proxy-Arp behavior and NAT's

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

Proxy-Arp behavior and NAT's

L1 Bithead

Hi All,

This problem is a little confusing to explain but I will do my best to lay this out.  Keep in mind I have changed the IP addresses to keep examples simple.

I have a Palo Alto 2020 with a basic configuration.  One internet connection and One LAN network behind it.

The firewall has a public IP address of 5.5.5.2/24 with a default route pointing to 5.5.5.1. We ran out of IP space and the provider started to route a new  6.6.6.0/28 block to us , this now gives us a bunch more IP addresses to use.  I know that on the Palo Alto I simply have to create a NAT which references these new addresses and the Firewall will take care of the rest.

I have created a NAT to translate traffic hitting 6.6.6.5 over port 443 to go to my internal server 192.168.1.10.  This works great, when someone surfs to https://6.6.6.5 they get my webpage.

The weird issue is when someone pings 6.6.6.5.  The traffic ends up looping between my firewall and the ISP.  As far as I can tell since the Paloalto does not have a specific NAT for the ping, the packet gets forwarded by the routing table back out the ISP who in turn routes it back to me.  This is very confusing for people when they try to ping the website.

Am I doing something wrong?

Thanks!

1 accepted solution

Accepted Solutions

For each IP that you want the firewall to ARP out for, in this case you would have to apply all 32 external addresses to the firewall external interface in order to avoid the TTL expired loop if those IPs "belong" to the firewall NATs.

You can script it out via CLI commands and make it really easy to just blast all the commands onto your PA via an SSH session, but that's completely up to you.

View solution in original post

6 REPLIES 6

L4 Transporter

Is there some reason you don't just also go add that IP to your externally facing interface on your PA? That way the PA should ARP out for it and things should work as you expect. Leave the default gateway alone and just add 6.6.6.5/28 to the outside interface.

L5 Sessionator

Hello,

Palo alto doesn't send grat arps for IPs not existing on palo alto.

if you assign 6.6.6.5 as secondary ip address and point an interface management profile with pings enabled to your untrust interface, ping should succeed.

Regards,

Hari Yadavalli

L6 Presenter

you may add this subnet as second and see it should work for ping.

another way for second ip subnet, enable untagged subinterface option from your interface, add a subinterface and use that new interface with new ip subnet.

Then you may use different management profile for each if you want.

Thanks for the replies everyone.  I just want to clarify a few things.  I dont especially care if the ping replies or not, id rather the firewall just drop the traffic instead of creating a TTL expired loop.

It sounds like the general idea is to apply an address in the 6.6.6.0/28 network to the external interface.  Can it be any IP in the range?  I certainly do not want to apply 32 address to the outside interface just so the firewall does not loop all traffic heading to that /28.

Would just applying lets say 6.6.6.2/28 to the outside interface take care of all other addresses in the /28?  For example pings sent to 6.6.6.5 would now just die at the firewall isntead of being routed back out.

I know in other vendor firewalls if traffic is sent to a box on which a NAT is configured but the traffic does not match the NAT service the packet is dropped, not sent pack out to the internet to be looped to death.  I just want to avoid that weird behaviour.

Thanks!

For each IP that you want the firewall to ARP out for, in this case you would have to apply all 32 external addresses to the firewall external interface in order to avoid the TTL expired loop if those IPs "belong" to the firewall NATs.

You can script it out via CLI commands and make it really easy to just blast all the commands onto your PA via an SSH session, but that's completely up to you.

L4 Transporter

ttl_expired if this question was answered to your satisfaction can you please mark answers as helpful and/or correct? It's good forum etiquette

  • 1 accepted solution
  • 10351 Views
  • 6 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!