App-id tcp/993 having issues
cancel
Showing results for 
Search instead for 
Did you mean: 

App-id tcp/993 having issues

L4 Transporter

New install of dual PAN 3020s on 8.0.2  that went really well for the most part and the only issue I am having now is imap(s) and Linux clients w/office 365 not working right. 

 

  1. I have a 'known ok' rule with outlook-web-online (among other allowed apps -- ssl included) using app-default but I get tcp-resets from the far end and users are not able to get mail via imaps on Linux clients ( I can on windows using latest TB).
  2. I added a specific rule for tcp/993 with 'any' for app-default and it still doesn't work.
  3. The only way I can get it to work is a blanket ANY/ANY with specific source IPs, no specific app-ids and using application default.  If I specify outlook-web-online and SSL I don't see the traffic even hit the PAN and clients complain about not being able to get email.  Without those app-ids I see the traffic and everyone is happy as a clam. 

Not doing SSL decryption. Has anyone seen this behavior before?  It seems to be local to some Linux users and the only thing I can think of is maybe outdated version of SSL/TSL on their local systems?  PAN not doing much to help me at all with this either as the logs are either there when its working or pretty much nothing when its not.  

17 REPLIES 17


@gwesson wrote:

Application-default won't work here. You can see from your previous screenshots that the connection starts as SSL. The default port for SSL is 443. Since the connection starts as SSL, your "Known OK" application list including SSL will break.

 

That's why you see your start log showing SSL but the end log is incomplete.

 

You'll need to remove the "application-default" from your rule. If you really want the application-default for the rest of the traffic, you'll need to split the rule, add one with "ssl" as the application and port (service) 993 as allowed.


 

Like this? 

 

pa-new-rule.JPG


When I did that the logs showed the traffic matching both rules now from a single source machine,  But at least no incompletes now.

 

pa-logs-02.JPG

Yes ;)

 

This is again the expected behaviour. The firewall identifies first the general app 'ssl'. But then after a few more packets it sees 'outlook-web-online'. And with this application change the firewall has to reevaluate the policy to check if this app is allowed or not and in your case this app then is allowed in another rule than the initial ssl application.


@vsys_remo wrote:

Yes ;)


Thanks.  Just odd to me becase the PA classifies that traffic as those two app-ids but can't seem to do anything with it.  And why below the known-OK rule?  It has those app-ids in it so it would break if that rule were below it because it would match the known-OK correct? 

 

I assumed that because both ssl and outlook-web-online were included in the known-OK that the traffic would pass because both are allowed.  So even if it starts out as SSL and moves to outlook-web-online then it should be OK.  BUt you are saying once it classifies it as SSL it moves down the list of policies to check to see if outlook-web-online is allowed as well? 


@drewdown wrote:

Thanks.  Just odd to me becase the PA classifies that traffic as those two app-ids but can't seem to do anything with it.  What does linux/OSX do differently than Windows and IMAPs? 


What do you mean with "can't seem to do anything with it"?

 

I don't know the difference between the OSes in case of IMAPs but ther hase to be a little one. But in this case it actually isn't imaps that the firewall sees. This would be the case if you decrypt the traffic.

 

Here there is probably a little difference in the TLS handshake as this is the only cleartext part which the firewall is able to check to determine the actual application (outlook-web-online).

The "problem" was 'application-default' as service. This really means that the allowed apps are only allowed on their default ports - and default port for ssl is only 443/tcp.

 

The policy check is done at the beginning and when the application changes.

@drewdown

FYI,

If you are not going to be decrypting traffic and plan on simply using an application filter with an application-default rule, you'll be breaking a lot more than simply imap due to the same issue you are running into here.


@BPry wrote:

@drewdown

FYI,

If you are not going to be decrypting traffic and plan on simply using an application filter with an application-default rule, you'll be breaking a lot more than simply imap due to the same issue you are running into here.


The plan was to decrypt but logistics in installing the cert and so forth stopped me from doing it day 1.  I plan on doing it just need to figure out the best way.  So far the only thing that has broken is this so  with fingers crossed will wait and see what if anything else breaks. 

 

 

@drewdown,

One thing when you do decrypt that you will need to setup is a rule allowing ssl on 80. It's a quirk with decrypting and Palo can't modify the default ports for the app-id without destroying it for anybody not decrypting. 

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!