- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
08-02-2017 05:50 PM
Hi,
PA does not seem to be able to distinguish between Dropbox and Cloudfront. In the Traffic logs, all sessions are identified as dropbox-base. Outputs from show session id:
DROPBOX:
start time : Thu Aug 3 09:58:15 2017
timeout : 120 sec
total byte count(c2s) : 4843
total byte count(s2c) : 6128
layer7 packet count(c2s) : 11
layer7 packet count(s2c) : 12
vsys : vsys1
application : dropbox-base
rule : Staff
session to be logged at end : True
session in session ager : False
session updated by HA peer : False
address/port translation : source
nat-rule : STAFF_NAT(vsys1)
layer7 processing : completed
URL filtering enabled : False
session via syn-cookies : False
session terminated on host : False
session traverses tunnel : False
captive portal session : False
ingress interface : vlan.100
egress interface : ethernet1/1
session QoS rule : N/A (class 4)
tracker stage l7proc : ctd decoder bypass
end-reason : aged-out
CLOUDFRONT:
start time : Thu Aug 3 10:03:34 2017
timeout : 30 sec
total byte count(c2s) : 3485141
total byte count(s2c) : 96056293
layer7 packet count(c2s) : 46500
layer7 packet count(s2c) : 63461
vsys : vsys1
application : dropbox-base
rule : Access Rule
session to be logged at end : True
session in session ager : False
session updated by HA peer : False
address/port translation : source
nat-rule : ACCESS_NAT(vsys1)
layer7 processing : completed
URL filtering enabled : False
session via syn-cookies : False
session terminated on host : False
session traverses tunnel : False
captive portal session : False
ingress interface : vlan.100
egress interface : ethernet1/1
session QoS rule : N/A (class 4)
tracker stage firewall : TCP RST - client
tracker stage l7proc : ctd decoder bypass
end-reason : tcp-rst-from-client
PAN-OS: 8.0.3 using latest content version.
Any idea how to fix this?
Thanks in advance.
08-03-2017 08:19 AM
Without decryption the firewalls app-id is kind of in a 'best guess' situation. It'll identify the application to the best of it's ability but the ability to do application identification is limited when you only give the device limited availability into the device. The only real fix would be to decrypt the traffic; if you open a TAC case they'll probably look at it and tell you the same thing.
I wouldn't really rely on the app-id being correct if you aren't decrypting the traffic, they can only inspect the headers and such within the traffic flow to try and identify the traffic.
08-03-2017 01:51 AM
Please open a TAC case. They will have to inspect this and get it rectified if its a decoder issue.
08-03-2017 02:46 AM
It doesn't appear you are using SSL decryption? You may need to enable decryption to be able to look inside the flow and properly identify the apps
08-03-2017 08:19 AM
Without decryption the firewalls app-id is kind of in a 'best guess' situation. It'll identify the application to the best of it's ability but the ability to do application identification is limited when you only give the device limited availability into the device. The only real fix would be to decrypt the traffic; if you open a TAC case they'll probably look at it and tell you the same thing.
I wouldn't really rely on the app-id being correct if you aren't decrypting the traffic, they can only inspect the headers and such within the traffic flow to try and identify the traffic.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!