application any not actually "any"

[GMTPaul]

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 imap.gmail.com and imap.mail.yahoo.com with the openssl client: openssl.exe s_client -connect imap.mail.yahoo.com:993 with the policy enabled.

I then made a URL Category object containing imap.gmail.com and smtp.gmail.com and added it to the service/category page on the policy that had gmail-base but was still able to connect to imap.mail.yahoo.com 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 imap.mail.yahoo.com?

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

[Remo]

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.

[GMTPaul]

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 imap.gmail.com:993
CONNECTED(00000004)
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 = imap.gmail.com
verify return:1
---
Certificate chain
 0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = imap.gmail.com
   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
-----BEGIN CERTIFICATE-----
MIIExjCCA66gAwIBAgIQPWEmwAUPba0FAAAAAIfqPjANBgkqhkiG9w0BAQsFADBC
MQswCQYDVQQGEwJVUzEeMBwGA1UEChMVR29vZ2xlIFRydXN0IFNlcnZpY2VzMRMw
EQYDVQQDEwpHVFMgQ0EgMU8xMB4XDTIxMDYwNzAzMDUwNloXDTIxMDgzMDAzMDUw
NVowaDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcT
DU1vdW50YWluIFZpZXcxEzARBgNVBAoTCkdvb2dsZSBMTEMxFzAVBgNVBAMTDmlt
etc.....

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

C:\Program Files\Git\usr\bin>openssl.exe s_client -connect imap.gmail.com:993
CONNECTED(00000004)
write:errno=104
---
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.

[aleksandar.astardzhiev]

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?

[Remo]

@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.

[GMTPaul]

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.

[aleksandar.astardzhiev]

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.

[Remo]

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.