Pingdom & Management Profiles

[Brett.Hoshaw]

Quick write here.  We currently use Pingdom to monitor external reachability to services and our remote office edge devices.  In some scenarios such as new office deployments, we may need to utilize the WAN interface to setup the device.  The problem here is the All-or-None approach of management profiles.  We want only ping from pingdom's probes and http from our specified management nodes.

Since pings to any interface are considered 'management' there's no way to setup a security policy to allow the probes, so my next question is now whether or not this is even possible?

Thanks in advance.

[Raido_Rattameister]

Can you configure GlobalProtect to connect to remote offices?

If not then you can create loopback interface and permit management on it (or DNAT to mgmt interface directly).

Set up DNAT to this loopback for mgmt traffic.

In security policy specify what source IPs are permitted to connect to manage firewall.

On external interface permit ping-only mgmt profile.

Be careful to limit this traffic as every now and then there are issues with security on mgmt traffic ( https://securityadvisories.paloaltonetworks.com/ ).

[Brett.Hoshaw]

Thanks for the link.  Question - it seems like those vulnerabilities are all towards the 'management interface'.  In my case, the management interface would not be accessible externally only internally.

I need a management profile on an external interface to allow pingdom probes to ping it, however I also need a management profile on the same interface to allow remote access in case of setup failures or VPN outages.

The loopback is a good idea but I question the security policy aspect since it seems like ping traffic with a destination of an interface on the palo does not show up in the traffic monitor which makes me wonder if this specific type of traffic is going to a different process - as if it classifies it as management traffic and compares it against the management profile.

[Raido_Rattameister]

Security policies are evaluated top to down. 

First one that matches will take effect (either permit or deny).

If you don't have custom rule like this:

from zone - wan

from address - any

to zone - wan

to address - fw public ip

application - ping (or more relaxed like any)

Then at the bottom intrazone-default rule will match.

This is not configured to write log by default.

Click on intrazone-default rule.

Click override at the bottom.

Open rule.

Actions tab.

Check "log at session end"

Do the same with interzone-default

[Brett.Hoshaw]

I'm familiar with the evaluation, what I'm not familiar with is how Palo treats specific traffic.

I had a specific security policy yesterday setup to allow pingdom probes to ping the external interface.  The pings still failed and the traffic monitor never showed any indicatation this traffic was attempted.

This is why I'm assuming that if traffic matches ping and the destination is the physical interface, it bypasses the security policy and utilizes the management profile instead.

[Raido_Rattameister]

It does not pass security policy.

Enable loggign on intrazone-default and interzone-default rules.

If no rule mathes then they will.

[Brett.Hoshaw]

Alright, I think we are going in circles here.

Security policies are evaluated top to down. 
First one that matches will take effect (either permit or deny).

If you don't have custom rule like this:
from zone - wan
from address - any
to zone - wan
to address - fw public ip
application - ping (or more relaxed like any)

Then at the bottom intrazone-default rule will match.

This is not configured to write log by default.
 
Click on intrazone-default rule.
Click override at the bottom.
Open rule.
Actions tab.
Check "log at session end"

Do the same with interzone-default

The specific rule did exist in the security policy yesterday so the intrazone-default rule should not be catching this - therefor there should be a log and it should show in the traffic monitor tab, correct?

It does not pass security policy.
Enable loggign on intrazone-default and interzone-default rules.
If no rule mathes then they will.

Now you've got me confused.  You said if there is a specific rule it should match and log there correct?  Otherwise it goes to intrazone-default or interzone-default.  So, even if there is a rule in the security policy for this traffic, it is still no matter what, considered intrazone-default or interzone-default? I have to turn on the logging for those to see the traffic logs, but this does not help reach the end goal of specifying what can and cannot ping an interface and what can browse (https) to the external interface.

[Raido_Rattameister]

Well if the rule would have matched it would be in the log.

For example if you have following Security policy then you should see log:

From zone - wan

To zone - wan

From address - any

To address - fw public IP

Application - ping

As soon as you add DNAT rule like the one below your security policy does not match any more because destination zone of the session is now LAN (not WAN):

From zone - wan

To zone - wan

Service - any

To address - fw public IP

Destination NAT to - some internal ip

In this case the rule does not match any more because <some internal ip> is in LAN zone and destination zone is switched in session header before security policy is checked so without knowing exactly how your security and nat policy were set up we don't know if the rule supposed to match.

For this reason i suggested to enable logging on default rules.

[Brett.Hoshaw]

I see now, I never setup the DNAT because I didn't want to expose the management interface externally.  So the rule in place is

From - External

Source - Probes

To - External

Destination - External Interface

I'm also questioning whether the external dynamic list is correctly populated.  I assume it does an initial pull before it re-checks on the schedule specified in creation?  Is there a way to see the current value of an external dynamic list?

The external dynamic list is populating correctly, verified through CLI.

After 30 minutes we should have seen 30 logs, yet there's nothing there, even with the intra/inter logs enabled and filtering explicitly on the external interface address as the destination.

At this point I'm convinced that the management profile set on the external interface is the reason why it's failing and again the fact that you're pinging a physical interface proves that they somehow handle this management traffic differently than normal intra/inter zone traffic.

[Raido_Rattameister]

Are you using External Dynamic List?

In this case you can see entries if you go to Objects > External Dynamic Lists

Open the one you are using as source address.

List Entries And Exeptions tab.

[Brett.Hoshaw]

That's correct - it is populating correctly.

[Raido_Rattameister]

Did you enable loggign on intrazone-default rule?

Do you see incoming pings now?

[Brett.Hoshaw]

Intra and Inter zone logging are both enabled.  There are no logs pings.

[Raido_Rattameister]

Go to Monitor > Session Browser

Use filter:

(application eq 'ping')

Do you see active sessions?

What rule do they match against?

[Brett.Hoshaw]

Negative.  No ping sessions.