I am working on a Palo Alto Networks Firewall migration project. I exported and imported the configuration with a few errors that I fixed and when migrating from the old to the new PA-3220 firewalls. All internal communications wtih LDAP and other servers are working and the routing protocols are coming up internally and externally. I can also ping the default gateway of ISP from the outside interface of the new Firewall, but the internet is totally down. I checked the traffic under monitor and found that all the packets are aging-out although they are all allowed.
I do have default gateway setup and a default route towards the gateway, I checked the arp and routing table looks fine. What is the issue? anybody please?
Solved! Go to Solution.
It was nothing but ARP cache from the Service Provider side, There was another switch between the Palo Alto Networks Firewall and ISP router. The ARP cache that i was getting on the firewall was from the switch not from the actual ISP router. The issue immediately got fixed upon ARP cache clear.
Hopefully you have this corrected already. However unplug the external interface for a few minutes to see if the ISP can clear their ARP. Or just call them and see if they see traffic and it they can clear the arp tables.
I did [show arp all] and found the ISP router gateway ip address has a proper arp cache. I also did a traceroute, but found a couple of hopes after the gateway is not being properly resolved, instead of IP address there was *** which indicates arp cache issue at that nodes. It is still not solved, i am following that closely.
@PAN-Bariz2020Check under Source NAT rule if translation type is selected as Dynamic IP And Port but not Dynamic IP only. This will create issue if other option is selected.
1>Did you check the traffic logs that traffic is getting natted to public IP address ?
2>You do not need bi directional option checked if you are only allowing users to access the Internet using Outside Interface IP.
3>Also check which rule it hits when you can successfully ping and compare it with non working security rule.
4>Use the test nat command
test nat-policy-match protocol 6 from L3-Trust to L3-Untrust source ip destination ip destination-port 443
I had performed those steps on the first failure and did not found any issue. I believe there might be a VRF issue from the ISP site. I will be able to get back on this next week.
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!