application any not actually "any"

Showing results for 
Show  only  | Search instead for 
Did you mean: 

application any not actually "any"

L1 Bithead


I have a simple virtual wire installation here, just testing policies.  I have a policy that is:

source: inside
destination: outside
application: any
service: application default


I attempted to connect to gmail through Outlook with IMAP and was being blocked.  Logs showed application of "insufficient-data" and "incomplete" with session end reason "tcp-rst-from-server".


I then created another near-identical policy with the only difference being application is "gmail-base".  I placed it above the original (see screenshot)


With this new policy added I am able to connect to gmail through Outlook with IMAP. The policies are otherwise identical. I'm now seeing application "gmail-base" and "yahoo-mail-base" in the traffic logs. If I disable the gmail-base policy I can no longer connect to any IMAP server over port 993.

I can connect to both and with the openssl client: openssl.exe s_client -connect with the policy enabled.


I then made a URL Category object containing and and added it to the service/category page on the policy that had gmail-base but was still able to connect to with the openssl client.


So, I guess I have two questions:


Why does application:any not allow IMAP but application:gmail-base does allow it?
Shouldn't the URL Category object containing only gmail domains prevent me from connecting to


2021-06-29 11_24_11-fw1.png


edited to add that this is a PA-220 running 8.1.13


L7 Applicator

Hi @GMTPaul 

Prior to the creation of the second policy that allows gmail-base, did you check the action that is shown in the logs? Because incomplete or insufficient-data does not mean the traffic was blocked. It means that there was something else wrong so the firewall was not able to see the application in the traffic because there was only a tcp handshake. I assume if you now delete the gmail-base policy, the connection is still working.

Unfortunately that's not the case.  With the gmail-base policy enabled IMAP in Outlook works and, for example:


C:\Program Files\Git\usr\bin>openssl.exe s_client -connect
depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
verify return:1
depth=1 C = US, O = Google Trust Services, CN = GTS CA 1O1
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN =
verify return:1
Certificate chain
 0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN =
   i:C = US, O = Google Trust Services, CN = GTS CA 1O1
 1 s:C = US, O = Google Trust Services, CN = GTS CA 1O1
   i:OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
Server certificate

With the gmail-base policy disabled IMAP in Outlook fails and:

C:\Program Files\Git\usr\bin>openssl.exe s_client -connect
no peer certificate available
No client certificate CA names sent
SSL handshake has read 0 bytes and written 316 bytes
Verification: OK
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)

Enable the policy and it's working again.


I went through and instead of taking a bunch of screenshots, here are the two policies:

inside to outside policy:
source: inside any
user: any any
destination: outside any
application: any
service/url: application-default any
actions: allow, various profile lists

allow gmail imap etc policy:
source: inside any
user: any any
destination: outside any
application: gmail-base
service/url: application-default any
actions: allow, various profile lists (identical to other policy)

 I don't understand why adding a more restrictive policy allows an application to work.

Hi @GMTPaul ,

- Regarding your question about URL Category. You forget that URL is not FQDN... URL Category will work only if it web based traffic, that is why it is called URL.

- Back to your main problem... I am also confused and I believe there is something that you are missing.... Have you download latest dynamic updates?

@aleksandar.astardzhiev as long as the firewall sees an "url" which is also the case in pop3s/imaps (specially if SNI is used in the TLS handshake and if not the firewall sees the CN from the certificate which is also logged in url logs. So for TLS connections - almost no matter which protocol is used - url filtering can be used to restrict the access.

I'm on the latest AV and threat definitions, I believe:

AV: 3762-4273
Threat: 8422-6787


The URL filtering is just a curiosity - I really don't care if anyone uses imap to read yahoo mail, I was just surprised to see it pop up after enabling the gmail application.

Hey @Remo ,

I know FW will use the cert CN as URL if traffic is encrypted, but I got the impression this is only valid for web-based traffic.


So far I did not use it (in production) to restrict anything else than webtraffic (only in lab environments, but I can confirm it works generally and I also have logs in the url log from smtps, imaps and ftps connections.

  • 7 replies
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!