Anyone here know cisco AND palo Alto

I'll start with this: Does anyone know if this:

Gateway of last resort is 10.x.x.x to network 0.0.0.0

     10.0.0.0/28 is subnetted, 1 subnets
C       10.X.X.X is directly connected, FastEthernet0/1
S*   0.0.0.0/0 [1/0] via 10.x.x.x

equals this:

destination              nexthop              metric flags      age   interface          next-AS
0.0.0.0/0                10.x.x.x              1 A S              ethernet1/3
10.x.x.x/28          10.x.x.x                 0 A C              ethernet1/3
10.x.x.x/32          0.0.0.0                   0 A H

For the life of me I cannot see why one works and the other doesn't.

Find more posts tagged with

Save $250 on 2025 certification boot camps from Infosec!

Book now with code EOY2025

Button

Comments

Bl8ckr0uter

bump.

I am going to take another look at this in a little bit.

Forsaken_GA

never touched palo alto, but I'm guessing it's the one that's not working (you never specified, btw!)

It'd be better to put in fake numbers than a bunch of x's btw

destination nexthop metric flags age interface next-AS
0.0.0.0/0 10.x.x.x 1 A S ethernet1/3
10.x.x.x/28 10.x.x.x 0 A C ethernet1/3
10.x.x.x/32 0.0.0.0 0 A H

Where the x's get confusing is on the /28 route and the /32 route, as well as what's defined as next hop. I know the /32 route has to be a valid IP. It's a /32, after all, so the numbers the x's are replacing shouldn't be the same in every case. This makes it hard to help you.

At a guess, the way I'm parsing it is this - default route points to an IP on the 10. network for the next hop

10.x/28 points to the same next hop as the default route?

10.x/32 points to the default as the next hop

so here's my question - is the 10.x/32 route the one the default is using for it's next hop?

If so, well, that's probably a problem - there's a more specific route to the next hop, which is pointing to the default, which the default is going to use to reach the next hop, which is the default, and so on, and so forth.

If all my assumptions are correct, either pull the /32 route, or point it out an interface, not to the default route as the next hop.

Bl8ckr0uter

Sorry sir and yes the Palo Alto isn't working.

I have two problems. In order to put a default route, you have to put something like 0.0.0.0/0 (which is already odd to be but whatever).

So lets it looks like this:


VIRTUAL ROUTER: Test
  ==========
destination              nexthop              metric flags      age   interface
         next-AS
0.0.0.0/0                1.1.1.49              1   S              ethernet1/
3
1.1.1.48/28          1.1.1.58              0   C              ethernet1/
3
1.1.1.58/32          0.0.0.0                   0   H

192.168.99.0/24          192.168.99.1              0 A C              ethernet1/
4
192.168.99.1/32          0.0.0.0                   0 A H

Ignore the class C's

The default gateway should be 1.1.1.49 which it sees but it also has a directly connected route for the 1.1.1.48/28 subnet. So here's what happens, it can ping the default gateway, it can ping things off the network (8.8.8.8 ), it can ping things on the network but nothing can ping it. I thought it was the firewall but I turned it off for this test. Nothing from the subnet can ping it and nothing from the outside world can ping it. I plug in my cisco router and it can ping it everything and I can even ssh into from the outside world (from my phone

). I don't understand how it is even possible for it to be pinging things but unpingable WITHOUT a firewall issue.

erpadmin

Is the Palo Alto doing something with ICMP? Maybe there is some sort of filter on the Palo Alto device?

Bl8ckr0uter

erpadmin wrote: »

Is the Palo Alto doing something with ICMP? Maybe there is some sort of filter on the Palo Alto device?

That's what I was thinking and that's what I am looking for. Honestly the gui is too busy. The cli is pretty slick but I can't find what I need. Maybe it's a default configuration or something.

erpadmin

Bl8ckr0uter wrote: »

That's what I was thinking and that's what I am looking for. Honestly the gui is too busy. The cli is pretty slick but I can't find what I need. Maybe it's a default configuration or something.

We have Palo Alto here too. I don't deal with it though. We use it for HTTPS VPN, which is fine if you don't have to do file transfers. I do, so I tend not to use it.

Bl8ckr0uter

found the problem. Hidden in the config is a setting called management profiles. Basically if you don't define a management profile and allow services it won't let you use do anything even with all other firewall services turned off (so no telnet, ping snmp, telnet, ssh, http or https). That's actually kind of brilliant.

Ahriakin

I haven't had a chance to play with ours but most firewalls have a totally separate section for allowing services to it's control plane (including ICMP to the device). From what I've seen a lot of the basic configuration principals are very similar to Juniper, and it is Zone based with a default of block-all, you likely have to enable host-inbound-traffic/ICMP for the zone that the OUTSIDE interface is in.

EDIT: heh...great minds...;)

Bl8ckr0uter

Ahriakin wrote: »

I haven't had a chance to play with ours but most firewalls have a totally separate section for allowing services to it's control plane (including ICMP to the device). From what I've seen a lot of the basic configuration principals are very similar to Juniper, and it is Zone based with a default of block-all, you likely have to enable host-inbound-traffic/ICMP for the zone that the OUTSIDE interface is in.

EDIT: heh...great minds...;)

Yea. I think this is the first device that I have worked with that actually did that. I actually like that alot from a security perspective. I just wish it said something in the logs like "packet dropped due to management profile settings" That would be awesome.

gregorio323

I may be 2 years late for this but have you created a management profile and applied it to the interface?

Bl8ckr0uter wrote: »
Sorry sir and yes the Palo Alto isn't working.

I have two problems. In order to put a default route, you have to put something like 0.0.0.0/0 (which is already odd to be but whatever).

So lets it looks like this:
VIRTUAL ROUTER: Test
  ==========
destination              nexthop              metric flags      age   interface
         next-AS
0.0.0.0/0                1.1.1.49              1   S              ethernet1/
3
1.1.1.48/28          1.1.1.58              0   C              ethernet1/
3
1.1.1.58/32          0.0.0.0                   0   H

192.168.99.0/24          192.168.99.1              0 A C              ethernet1/
4
192.168.99.1/32          0.0.0.0                   0 A H
Ignore the class C's

The default gateway should be 1.1.1.49 which it sees but it also has a directly connected route for the 1.1.1.48/28 subnet. So here's what happens, it can ping the default gateway, it can ping things off the network (8.8.8.8 ), it can ping things on the network but nothing can ping it. I thought it was the firewall but I turned it off for this test. Nothing from the subnet can ping it and nothing from the outside world can ping it. I plug in my cisco router and it can ping it everything and I can even ssh into from the outside world (from my phone ). I don't understand how it is even possible for it to be pinging things but unpingable WITHOUT a firewall issue.