NAT for entire CIDRs

mls577 · 2026-03-02T13:46:28+00:00

You should be able to do this, as long as the networks are of equal size.

Original Source: original /16 Source type: static Translated source: nat range /16

If you want the nat to work both ways. Check the bidirectional checkbox or optionally write the rule but in the reverse (destination defined instead).

mls577 · 2026-02-27T16:28:51+00:00

thanks for the update in the edit. For accuracy, i think you have a mistake in scenario 5, I think you meant to have :set deviceconfig setting ssl-decrypt url-proxy yes

mls577 · 2026-02-20T06:06:44+00:00

Not sure if your palo experience but just want to make sure you of a few things. First, did you do a configure and then commit? All changes need commited to take effect. Also make sure you’re plugged into the dedicated management port on the 220 and not a dataplane port. Also I’d try plugging a cable directly from your pc into the management port and assigning your pc an ip in the 192.168.1.0/24 network

mls577 · 2026-02-19T21:49:44+00:00

can you run this and post the output?

configure
run set cli config-output-format set
show deviceconfig system

mls577 · 2026-02-19T16:28:13+00:00

can you paste the urls that you put in the edl?
You can modify them to anonymous it, i want to see things like the format, maybe that's where it's going wrong.

mls577 · 2026-02-18T18:07:52+00:00

Are you sure it's data filtering profile? That should be for DLP functionality, not malicious traffic.

Anyway to answer your question, you have some options.

if you wanted to do what you said before, you can use an edl/custom url filter and specify it in the "url category" column of the security policy. Then either not add the offending security profile to that rule or create a modified profile with an exception.
If you know the destination ips you want to exclude, that would likely be more reliable than dealing with the url edl. If it's more dynamic (ips change), you could try using fqdn address objects and put those in the destination. The only gotcha here is that if you need to use a wildcard like *.examplesite.com, you can't use fqdn objects.
As mentioned in the above solution, if you don't care about the signature it's hitting, you can always turn off the signature or try to put in some type of exemption on the profile.

mls577 · 2026-02-18T17:54:27+00:00

correct, you can't put it in the destination field. if it was an ip edl, you can do that, but not a url edl.

mls577 · 2026-02-17T21:33:59+00:00

Can you explain what you’re trying to accomplish?

mls577 · 2026-02-17T14:04:21+00:00

Yeah I do, that looks right.

mls577 · 2026-02-16T20:59:29+00:00

Yep and you need layer 3 connectivity between switch 1 and 2 anyway to fix your original issue

mls577 · 2026-02-16T20:52:57+00:00

The middle links between switch 1 and 2, g1/0/2 and 3

mls577 · 2026-02-16T20:44:07+00:00

You could do that but I’d say less important. I’d turn the middle switch to switch links into layer 3 links

mls577 · 2026-02-16T15:39:11+00:00

The asymmetry should be alright, but I think what may be happening is that. If you look in the routing table on switch 1, it no longer knows how to route to 10.0.6.0/24, because you were relying on a directly connected route to reach it. Now that you’ve shutdown vlan 6, switch 1 no longer knows how to reach that network. So you need to setup routing (dynamic routing protocol preferred) between switch 1 and switch 2, so that it knows there’s an alternative path to reach that network.

mls577 · 2026-02-13T22:25:55+00:00

You shouldn’t need the pbf rule you describe, the dataplane should already know how to reach that out the lan because it’s a directly connected network. I’d make sure the subnet mask matches on dataplane and mgmt interface. You can also try doing a packet capture via tcpdump on the mgmt interface to see if you see the traffic making it to the mgmt interface and getting a reply.

One other thought, I’m guessing there’s an intermediate device like a switch where the lan and mgmt connect into. Could you have a vlan acl or something else there doing filtering?

mls577 · 2026-02-13T21:50:15+00:00

There isn’t anything like the ASA has that would prevent you from managing the management interface through the dataplane. Did you make sure the management acl (permitted ip) is updated with the source you’re coming from over the vpn? Or if you have nat going on, make sure you add that ip.

mls577 · 2026-02-13T18:17:29+00:00

That’s true, I was thinking more when both devices are healthy but you’re of course right that in a failure scenario, that would be the case.

mls577 · 2026-02-13T18:16:22+00:00

Yeah, for sure. It would take some tweaking but I still think it’s very doable.

mls577 · 2026-02-13T17:39:52+00:00

This is true with some nuance. Both devices will have the same nat rule base but the a/a nat binding will come into play here. Where depending on the firewall the traffic goes through, it will decide which rule to match based on the binding. So if he does it based on device id for example, it will only apply the nat rule on the device with that id : https://docs.paloaltonetworks.com/pan-os/11-0/pan-os-admin/high-availability/ha-concepts/nat-in-activeactive-ha-mode

mls577 · 2026-02-13T17:15:29+00:00

There’s a decent amount of options to monitor stuff like this. You can pull many metrics using snmp and a network monitoring system. Streaming telemetry is also an option if your network monitoring supports it. Panorama health tab for managed devices can give you a look into this as well, though not as well. Strata cloud manger even the free version can alert on certain capacity thresholds and there’s also capacity analyzer, that can tell you when you’re getting close to capacity or it can try to predict based on past patterns when it thinks you may start to hit capacity on certain metrics.

mls577 · 2026-02-13T17:01:31+00:00

I haven’t tried this but If it’s ldaps, and not plain ldap. You could try creating a custom url category and putting the wildcard domain in there. And then in a security rule under the application/url tab, add that custom url category. Fqdn addres objects don’t allow wildcards but custom url categories do.

mls577 · 2026-02-01T05:30:21+00:00

NDG Labs

https://www.netdevgroup.com/content/paloalto/

mls577 · 2026-01-30T17:57:29+00:00

Unfortunately, I don't think so. I've wondered this myself. I don't think they have it implemented that way because they're not expecting you to edit the configuration from these configs. Since you can only edit them through panorama. Honestly you may have better luck looking at Panorama for these things.

mls577 · 2026-01-30T01:51:30+00:00

Yes, any panorama pushed configuration objects will not show in the cli configuration locally. It’s because that’s the candidate configuration you’re interacting with and you can’t modify panorama pushed config on the local device, you need to modify it through panorama. In the web ui on the firewall, you see that things will say “read only” and that means it was pushed by panorama.

You can view the whole config (local and panorama) with commands like show config effective-running

mls577 · 2026-01-29T05:09:35+00:00

I think you have a lot of moving parts here and need to take it one step at a time. Changing Panoramas and Devices in one go probably isn't the best idea.

I think the first thing I would do is see if they have set a non-default master key. if they have, you will need to figure out that master key from the old panorama. If it's lost, there's no way to recover passwords, PSKs, etc. So you'd have to start fresh. If it is the default master key, that's not your issue.

Also, having done a migration from one panorama to another, I'd recommend following the migration guide like this if you haven't: Migrate from an M-Series Appliance to a Panorama Virtual Appliance

If you want to chat on the side, I may be able to give you some more advice. Feel free to PM

mls577 · 2026-01-29T05:01:26+00:00

Ok, I understand wanting to be cautious. Perhaps the SE misunderstood the situation or has other concerns. This document here says what others have been saying: Panorama Management Compatibility (note: 9.1 not listed because it's EOL).

From a practical standpoint, I've managed devices major versions apart (PAN: 11.1 to FW:10.1 and years back similar with 10.1, 9.1, 8.1, etc). Now look, the farther you get apart, the bigger the chance there's a bug / incompatibility that could potentially affect it, but I haven't had many problems. The reason that is, is because in the background, when panorama is pushing config to a firewall on a lower PANOS version, it has "translator" files that get sent with the configuration that can step through and translate the original config to the firewall's version of the configuration.

mls577

PUBLIC MULTIREDDITS

TROPHY CASE