App Identification and ALLOW rule - does this make any sense?

[TonyDeHart]

Attached is a screenshot of a rule that is ALLOW'ing ICMP, IKE, IPSEC, PING.  Can someone explain why SSL is in the APPS SEEN list?  I don't see where any of these applications have an implicit allow for SSL/443 trafffic yet if I read this right it is saying it sees SSL and more importantly allows it here because it hasn't narrowed it down to what it really is yet.  But even if it didn't know is SSL somehow part of the four APPS in the rule itself?

Service is set to ANY not APPLICATION-DEFAULT - is that the problem here? If so, still not quite sure how port 443 is getting into this rule.

Thanks for the help!

[aleksandar.astardzhiev]

Hi @TonyDeHart ,

I would like to look at the log details for one of the sessions logged, but I am almost certain that the reason is the "any" service.

When you create a rule with "any" service you essentially tell the firewall "open any port and protocol". This way firewall will accept any traffic (matching the source and destination addresses of course) and only when it have enough data to identify this traffic it will re-evaluate the rule to check if the identified application is part of the allowed list.

This could explain why TCP/443 is allowed - because you told the firewall that the allowed application may run on any of the ports, so it will allow the initial TCP handshake.

It is still strange tho, so I would guess it may be related to the logging setting - does your rule log at session start, end or both.In combination to how those SSL sessions are ended - are they fully established or closed due to ageout, or not even completed.

I would search the traffic logs filtering by rule name and application SSL and look at the log details - how the sesson end, is there traffic in both directions, was the log created at sesson start or end?

Is this rule related to traffic TO the firewall itself? Or traffic that is just passing the firewall?

[santonic · Accepted solution]

It is not strange to see this in traffic log. If the service is 'any' PA has to allow the traffic until it identifies the app and then decide on action. So yeah, ssl on port TCP 443 can be seen as detected app in this rule.

[TonyDeHart]

I get the "ANY" service allowing all ports but it would seem that would apply only if SSL was implicitly allowed by one of the other applications which it is not. 

Either way, there was a missed clue for me as to something else going on here and I did get an explanation from a Palo engineer with some references to KB and conversations here.

I've included a screenshot of the clue but it has to do with the Palo tracking GlobalProtect clients IP's and us using the same IP for our GP traffic as other traffic inbound. It is recognizing SSL traffic as possible GP traffic until it is thoroughly identified.  The screenshot included shows it NAT'ing traffic to destination port 20077.  I'm told the Palo is intercepting this and forwarding it to the management plane and once it is clear it is destined for GlobalProtect or not it applies the right rule to the traffic.

It still seems odd to me that this is the rule getting applied but it does eventually turn the traffic over to another rule in the logs.

Here some of the related info to this issue:

If a GlobalProtect Portal uses the same IP address as the traffic. The Dataplane knows which host IPs GlobalProtect is enabled on.
Whenever the PAN-OS sees traffic on those IPs and the dport= 443 then it would changes the dport to 20077 and sent it over to Management plane. Once the firewall sees enough packets it then knows this isn't GlobalProtect traffic.

Also:

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClM1CAK
https://live.paloaltonetworks.com/t5/general-topics/ports-used-for-paloalto/td-p/522816

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClVHCA0

[TonyDeHart]

---

It is still strange tho, so I would guess it may be related to the logging setting - does your rule log at session start, end or both.In combination to how those SSL sessions are ended - are they fully established or closed due to ageout, or not even completed.

I would search the traffic logs filtering by rule name and application SSL and look at the log details - how the sesson end, is there traffic in both directions, was the log created at sesson start or end?

---

 This is logged at the end and there are no "packets received" just "packet sent".  It does show reason for ending as "tcp-fin" so it doesn't appear to just be dropping or cutting it off unless I'm misunderstanding...just odd there is not a received.  It all seems to be some anomaly related to GlobalProtect.

[aleksandar.astardzhiev · Accepted solution]

Hi @TonyDeHart ,

---

@TonyDeHart wrote
...just odd there is not a received.  It all seems to be some anomaly related to GlobalProtect.

---

I wouldn't say it is anomaly. I don't have exact explanation, but I believe this is normal behaviour - traffic related to GlobalProtect or IPsec site-to-site tunnels that is targeting the firewall itself (not passing through it) is always showing only received and no sent.

I have noticed the same behaviour when FW is the destination - log is not recording packet sent, that is why I asked if the traffic is TO the FW 🙂

---

@TonyDeHart wrote
It still seems odd to me that this is the rule getting applied but it does eventually turn the traffic over to another rule in the logs.

---

Firewall will use the first rule that maches the TCP SYN packet (source, dest addresses and ports).

Because your rule is allowing any port and matching the addresses (and being above the actual rule for the SSL), traffic is first allowed by this rule.

As you mentioned traffic is then properly identified and moved to another rule, but that SSL traffic has already been added to the first rule statistics.

[TonyDeHart]

---

@aleksandar.astardzhiev wrote:

I have noticed the same behaviour when FW is the destination - log is not recording packet sent, that is why I asked if the traffic is TO the FW 🙂

---

You did ask that didn't you? 🙂

Appreciate the insights and it is all starting to gel now in my brain.  It makes sense now.