In Palo Alto Firewalls, what is the correct command in the CLI, to "validate" if I have or don't have a route, to reach a particular destination?
The correct command is "show routing route" or "show routing fib" ???
What is the command that can help me to know if my Firewall has a route to a particular destination?
Thanks for your comments.
Your image only gives half the picture, but lets assume the routing table on the 'inside' router also includes the FW Eth1/4 subnet.
On the firewall when you issue the 'ping host ...' command, the traffic is sourced on the MGMT interface, the next-hop is the router shown in your screenshot. I'd imagine the the destination subnet 10.7.25.0/24 (?) is also directly routed on this router, you therefore have a routable path with not security policy to get in the way.
When you use the 'ping source <eth1/4_ip> host xx' command, traffic should egress the firewall towards the inside router and then onto the destination subnet, again you have a routable path between the endpoints. The issue you have when sourcing from any interface other than mgmt0 is that an intra-zone policy must exist to permit those flows.
Another point that is probably worth looking at is that your mgmt interface is not out-of-band and can be reached by any 'inside' device. Without re-architecting your logical design, I suggest you edit the allowed-hots ACL on that interface to permit access from an operations subnet/ jump box.
Please mark this post solved it you feel your original question has been answered.
The FIB is used to determine the egress interface to reach a particular destination, typically the next-hop. The routing table contains all unfiltered/ permitted prefixes and their preferred next-hops.
show routing route
...is the CLI command your want.
It is worth noting that the RIBs associated with dynamic routing protocols may contain additional prefixes which due to routing which have not been added to the routing table.
Thank you for your response.
Based on your comment, I have a question.
I want to "validate" if I have a route to reach an IP from my Firewall.
The IP is 10.7.25.107.
When I test the "connectivity" from the Firewall, with the command "ping host 10.7.25.107". the result is successful, but I have "understood" that this command "pulls all the traffic" through the MGMT Interface of the Firewall, is this correct?
When I query the "show routing route", the command shows me the following.
I understand from the output of the command, that to reach that destination, I do it through the ethernet interface 1/4, but I do not understand why when I do a "ping" with origin, it does not work (And according to what I understand, it should work).
I have the idea that is the "ping host x.x.x.x.x" that should not work, and the "ping <source> host <destination>", that if, should work, at least in my scenario, but this does not happen.
Could you help me to clarify this doubt, please.
I have read the KB, and it is useful, but the theory is still not clear to me.
My question is "why does the "ping host x.x.x.x.x" to my destination work, if according to the routing table, to reach that destination, you "reach it" through the ethernet1/4 interface. I believe that this test should not be satisfactory.
I understand that the test to validate connectivity from the FW, towards the destination that I expose in the images, should be a test of "ping with origin", but when I make this test, the result, is negative.
Hi @Matlu_NN ,
If the source interface is not specified then "ping host x.x.x.x" will be sourced from the management interface.
It is clear to me that the "ping hos x.x.x.x.x" takes out all the traffic through the mgmt interface, in my scenario, this should not happen, because for me to reach the destination 10.7.25.107, according to the routing table, I must reach it through the Ethernet1/4 interface.
So, the correct way to test the connectivity to that destination, should be with a "ping with source", that is with the command "ping source <IP of the interface Eth1/4 source 10.7.25.107" (As it is in the pictures that I attached above the case), but when you do this test, it simply does not work, and I do not understand why.
It is not supposed to work??????
You say that traffic sourced from the mgmt interface shouldn't be able to reach 10.7.25.107, but remember that interface will probably have been configured with a default gateway. Now unless this mgmt subnet is truly out-of-band, it is highly likely that it is routed on your 'core' router. Does the router with the interface 10.7.44.1 receive the palo alto mgmt subnet via an IGP update or have a static route installed for it or an aggregate route which directs back to your 'core' router? It would be great to see a topology to determine if this path is not possible.
Regarding using the ping command and specifying the Eth1/4 interface IP, what does your security policy look like? Is intra-zone communication permitted? If not, then does a rule exist to permit icmp/ping sourced from your eth1/4 interface ?
Is it necessary to have a security rule to allow traffic from the Ethernet1/4 Interface for ping tests to my destination 10.7.25.107?????
I have checked the rules, and also the logs, and this is what I found.
It is necessary to create an explicit rule to allow me to simply ping from the eth1/4 interface to my destination ????.
What I do not understand so far, is why the "PING HOST X.X.X.X.X" responds me positively, if in the routes, I do not have any evidence that to reach this destination, I do it by the MGMT.
Unfortunately, I do not have the routes of the router with IP 10.7.44.1
Thanks for all your help.
The default intra-zone permit rule would have allowed this particular flow to work, but as you have shown, your 'BLOCK-ALL' rule is denying it.
Since you are pinging within the subnet from the eth1/4 interface this is covered by the intra-zone rule which cannot be reached, so yes, you need to explicitly permit it.
Regarding the mgmt interface routing, this does sound like a case of that particular prefix being advertised explicitly or as part of an aggregate to the other router.
Can you share the routing table of the router which has the DGW interface for the mgmt subnet? Also what is the mgmt subnet Id?
Unfortunately the router that is the DGW of the MGMT interface, is managed by another "Team", and I do not have that information now, but I will talk to them to provide me the route that they have from their equipment, to reach the IP that has my MGMT interface of the Firewall.
Is this type of scenario common?
I mean, if I validate that to get to any destination, I leave through a specific interface (any, for example eth1/5, eth1/8, etc], and if I want to test PING with ORIGIN, from the Firewall CLI, I must always have an Intazone rule enabled and in "permit"?????
This is as a general concept????
To understand why in my case, "ping host x.z.z.z" works, you need the routing from the Router, right?
For now, I can assume that for any kind of traffic to reach my specific destination, it is going out on the eth1/4 interface????.
Looking at your screenshots,I notice that the zone which your destination IP resides is 'Inside'. Your mgmt subnet even if not part of the inside zone is clearly going to be routed on a router somewhere in this inside zone. This makes your mgmt subnet and the destination IP subnet highly likely to exist on the same routing table.
Has your mgmt subnet been sold to your as out of band??
Regarding your intra-zone question, a ping is typically sourced from the interface 'closest' to the destination, for this reason it will typically be an intra-zone flow. Arguably you could source the ping from another interface in a different zone therefore requiring an inter-zone rule.
The default intra-zone rule is set to permit, and unless you override it or place a block above it, this scenario wouldn't normally be a problem.
I'd wager that most firewall admins have a setup like yours, which necessitates an explicit rule for every flow, even those originating from the firewall. Life is better this way!
Your final assumption is correct, for that particular prefix the FIB would ensure that your packets leave via Eth1/4, unless they come from a ping flow initiated on the CLI !
Thanks for taking the time to be able to help me.
Right now, I have no idea, if the MGMT interface, was "sold" as "Out of band".
Is this something I should check with the project implementer?
Or can I answer this question myself by checking the configuration?
The only thing I know is that the Firewall model, which is a 3020, has a dedicated leg to be MGMT.
In your experience, I ask you 2 questions.
When you have connectivity problems between a source and a destination, and you want to validate if that destination is "available or reachable" from the Firewall point of view, you do tshoot tests, involving the simple PING from the FW???? CLI.
For you to validate if you have a route or not, to reach a destination, from the FW, it is valid to use the command "show routing route"????
I still have pending, the routing table of the Router that GW from the MGMT of the FW.
Thanks for everything, bro.
It is only worth confirming the mgmt subnet routing as you seem surprised by what parts of the network are reachable from it.
As for troubleshooting connectivity, you first want to check that a valid route exists (your CLI command is valid for this, or the virtual router runtime info via the webgui). I would then start looking as security policy, traffic monitor logs, session browser, packet capture and policy match troubleshooting. As you have seen from the ping command, trying to troubleshooting connectivity from the firewall does not give a representative test.
Hello, my friend.
I got this information regarding the SwitchCore machine that has the IP 10.7.44.1, which is the GW of my Palo Alto.
The Router with IP 10.7.44.1, knows my MGMT IP (eth1/4 of the FW), by a static route, as I show you in the following image.
All your explanation is clear, I just want to give "sense" to the explanation of why the "ping host 10.7.25.107" works, if according to the routing table, to reach that destination, I must leave through the eth1/4 interface and it does not work, but it seems that it does reach that destination through the MGMT interface of the Firewall (with IP 10.7.15.166).
Hopefully, you can clarify this theory.
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!