thanks for the post.
Yes, this is correct understanding. Unless you have dynamic routing in place, for any indirectly connected subnet, you will have to configure static route with egress interface. Here is a KB for reference: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u0000001V3WCAU&lang=en_US%E2%80%A...
If the other subnet has a route back, this communication should be functional.
Thank you for reply @nemeses666
by looking into your edited post, no this is not expected behavior. May I ask, how did you diagnose/concluded that adding static route is resolving this issue?
Regarding ping, by default it is using management interface. If you want to change it to data plane interface you have to specify source: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Clk7CAC
Hi Pavel. Without the static route I am unable to communicate with IP address attached to the local interface. Even using the 'source' option with ping I am unable to ping 188.8.131.52 unless the static route exists. A site to site VPN will not come up without it. I can see the IKE packets from the remote peer however the Palo does not respond unless the static is in place.
There are an awful lot of things that could be going on; multiple route tables, more specific routes, incorrect netmask, NATs, PBFs, etc. Starting simple since you say you can not ping the directly attached host (this shouldn't need a source option since the device is locally connected, i.e.):
PA> ping host 184.108.40.206
Remove the static route for 220.127.116.11/24 you put in. Can you ping the PA itself?
PA> ping host 18.104.22.168
What does the routing table show for a destination matching 22.214.171.124?
PA> show routing route
Because the routing table will show:
- the route mask applied to the route, which may indicate incorrect or corrupted netmask applied to the interface
- route existing on an alternate interface, meaning the IP range is already being used elsewhere on the PA
- route existing with something other than "C" connected status, i.e. its being learned from elsewhere, overridden by some other static route "S", etc.
- a more specific route is redirecting traffic to another interface
- look at whether the route exists in your default routing table, as well as in alternate routing tables which may exist in your specific configuration
Also look carefully through your PBFs to see if something might be matching/redirecting traffic there. There is a "Test Policy Match" tool at the bottom that you can use to see if traffic would potentially match a rule.
You don't need to post your actual IPs from the routing tables, you can obscure them. Netmask/routing type/interface matching the expected values is more important than the actual IP.
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!