This Nominated Discussion Article is based on the post "Query For Routing Table" by @Matlu_NN and responded to by @seb_rupik , @Alin.Scarlat and @TomYoung. Read on to see the discussion and solution
In Palo Alto Networks 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?
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.
The CLI command you want is:
show routing route
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.
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 the "ping host x.x.x.x.x" should not work, and the "ping <source> host <destination>" should work.
If the source interface is not specified then "ping host x.x.x.x" will be sourced from the management interface.
https://live.paloaltonetworks.com/t5/blogs/tips-amp-tricks-how-to-ping-from-the-cli/ba-p/468784
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.
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
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 you 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 !
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 troubleshooting 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.
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 at 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.
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).
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 xxx' 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.
