I have a simple virtual wire installation here, just testing policies. I have a policy that is:
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
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 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.
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?
@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.
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!