Teamviewer application not allowed by policy

[tajman]

I'm encountering a strange situation where teamviewer is not allowed by the policy in which it is defined but is instead blocked by my clean up rule.

I have all the dependencies matched but for some reason the firewall does not match on the rule where teamviewer is configured but only matches on the deny all clean up rule. There are no other logs except the traffic log showing teamviewer-base as the application and that it was denied.

Appreciate any that can be provided with this issue.

Thanks,

Tarquin.

[mivaldi]

Post a screenshot of the policy allowing teamviewer.

Also try changing Service to both application-default or 'any'.

Policies act on a 6-tuple basis, so they have to match all conditions to have the policy go in effect.

The 6 tuples are: Source IP address, Destination IP address, Source Port, Destination Port, Protocol and Security Zone.

Mariano.

[tajman]

Thanks Mivaldi.

I can't take a screenshot now since the device is at a customer.  I've defined the Source Zones (Trust and WAN), Source-Users, Destination Zone (Untrust), Applications (there are several for this policy one of which is teamviewer-base) and profile options (antivirus, antispyware, and threats).  The logs show the zones for source and destination and they are defined correctly by the policy.

I had a similar issue with dropbox and Palo Alto support required we put a URL category for dropbox in the Service/URL field when defining the application however there was a corresponding URL log showing the traffic was denied. This is not the case now.  I should add that I'm running 5.0.9 on the firewall.

T.

[mivaldi]

Use the data you already learned for the 6-tuple caught on the deny rule.

Then create a rule that simply matches the IP on the corporate side.

Do an allow any, no layer 7 inspection profiles, application teamviewer, service any.

If traffic hits this new rule, you can add settings one at a time to check what is amiss.

I'm suspicious of your source user setting, try changing that to any, and service to any.

You may be using a group for source user, and your user may not be in the group you think it is. If you are using a group, log in to the CLI, and run:

> show user group list

(identify long name of the group)

> show user group name "long name" | match (your user)

Mariano.

[tajman]

We checked with support on this because there was nothing in the rule that looked incorrect.  It turns out that a previously added URL Category under the "Service/URL Category" tab was the culprit.  This was even more strange based on the fact that that entry was recommended by Palo Alto Networks support to solve a similar issue with dropbox application.  I'm sending the two cases to my SE since it may be a possible bug.