topic Re: Windows-Remote-Management & Implicit Use of Web-Browsing in General Topics

Windows-Remote-Management & Implicit Use of Web-Browsing

Brandon_Wertz — Wed, 24 Dec 2025 18:00:13 GMT

I need your help with understanding this.

We've got a rule that was intermittently working. We built a rule around the use of "windows-remote-management" which is using the standard port of 5985/tcp. The rule is a service "application-default" rule.

When we look through the logs we see that some of the traffic that should be matching this rule is not matching this rule and is being denied. It's being denied because "web-browsing" is being seen over port 5985.

I understand that the app-default port for web-browsing is 80/tcp, but given that the App-ID WRM was created to use the standard default port 5985, shouldn't web-browsing which is implicitly allowed on this app-id follow the default port of 5985?

I've got an active support case on this topic, and TAC is telling me that is not the way it works, but this just doesn't make sense to me. TAC is saying that eventhough web-browsing is implicitly allowed in the WRM app-id since web-browsing is being seen on the non-standard port of 5985 the traffic should be blocked.

If I build a rule intending to allow only "Windows Remote Management" and this traffic occurs over 5985/tcp shouldn't any other associated traffic also work and be allowed? To me the implicit association of web-browsing with WRM is never going to work, w/o the rule being a service "any" rule. Meaning web-browsing should be a "depends-on" and not an "implicit use" application.

Re: Windows-Remote-Management & Implicit Use of Web-Browsing

emr_1 — Thu, 25 Dec 2025 06:39:04 GMT

I agree with you, and TAC is wrong.

If I configured a rule as below:

The rule on the box is recognized as below:

)> show running security-policy

"test; index: 1" {
from any;
source any;
source-region none;
to any;
destination any;
destination-region none;
user any;
source-device any;
destination-device any;
source-advanced-device any;
destination-advanced-device any;
category any;
application/service [0:windows-remote-ma/tcp/any/5985 1:windows-remote-ma/tcp/any/5986 ];
application/service(implicit) [0:web-browsing/tcp/any/5985 1:web-browsing/tcp/any/5986 ];
action allow;
icmp-unreachable: no
terminal yes;
}

As you know, "web-browsing/tcp/any/5985" is "application/protocol/source-port/dest-port".

By the way, I found issue from release note.

===

PAN-194408

Fixed an issue where, when policy rules had the apps that implicitly depended on web browsing configured with the service application default , traffic did not match the rule correctly.

===

Even I don't know which version you are using, you should check you are hitting this or not.

I can find this bug-id on 10.1.6-h3, 10.1.7,10.2.3 release note

Re: Windows-Remote-Management & Implicit Use of Web-Browsing

Brandon_Wertz — Mon, 29 Dec 2025 14:32:39 GMT

@emr_1 wrote:

I agree with you, and TAC is wrong.

If I configured a rule as below:

The rule on the box is recognized as below:

)> show running security-policy

"test; index: 1" {
from any;
source any;
source-region none;
to any;
destination any;
destination-region none;
user any;
source-device any;
destination-device any;
source-advanced-device any;
destination-advanced-device any;
category any;
application/service [0:windows-remote-ma/tcp/any/5985 1:windows-remote-ma/tcp/any/5986 ];
application/service(implicit) [0:web-browsing/tcp/any/5985 1:web-browsing/tcp/any/5986 ];
action allow;
icmp-unreachable: no
terminal yes;
}

As you know, "web-browsing/tcp/any/5985" is "application/protocol/source-port/dest-port".

By the way, I found issue from release note.

===

PAN-194408

Fixed an issue where, when policy rules had the apps that implicitly depended on web browsing configured with the service application default , traffic did not match the rule correctly.

===

Even I don't know which version you are using, you should check you are hitting this or not.

I can find this bug-id on 10.1.6-h3, 10.1.7,10.2.3 release note

@emr_1 -- thank you for this confirmation. I'll be following up with our TAC team today and share the results. Also appreciate the bug info. FYI we're running 11.1.6h19.