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.  

1 ACCEPTED SOLUTION

Accepted Solutions

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.

View solution in original post

17 REPLIES 17

L7 Applicator

Hey

Change policy to any/any so that traffis would work.

Go to traffic log and click on mag glass of this session and paste screenshot of session details.

Enterprise Architect @ Cloud Carib www.cloudcarib.com
ACE, PCNSE, PCNSI

I had the rule set to any/any and it was working, but when trying to get it working right I changed it to app-id and it broke again.  I changed it back to any/any but don't see any packets coming across on port 993 and this rule. Screenshot below is when it was set to any/app-default and was working.  It is now set to any/any but I don't see any packets on port 993 hitting the PAN from any of the 3 source IPs I have defined to log it.  

 

working-pa-any-any.JPG

 

 

test security-policy-match application outlook-web-online source 10.x.x.x destination 40.97.134.18 destination-port 993 protocol 6

"outbound-imaps; index: 14" {
        from trust;
        source [ 10.x.x.x 10.y.y.y 10.z.z.z ];
        source-region none;
        to untrust;
        destination any;
        destination-region none;
        user any;
        category any;
        application/service  any/any/any/any;
        action allow;
        icmp-unreachable: no
        terminal yes;
}

 

Ok, so the rule is currently any/any, locked down to the 3 users source IPs and its working.  I can't leave it like this so I need to figure what is going on.   Screenshot below is from today with everything working like it should.  

 

pan-any-any-today.JPG

 

 

@drewdown,

In both examples your destination port is 993 so I'm not really seeing the issue. It's highly unlikley that anyone that actually sends an email is going to actually send it from port 993, it simply goes to 993. If you are attempting to filter this policy by source port that really isn't going to work that well with modern email applications. 

@BPry wrote:

@drewdown,

In both examples your destination port is 993 so I'm not really seeing the issue. It's highly unlikley that anyone that actually sends an email is going to actually send it from port 993, it simply goes to 993. If you are attempting to filter this policy by source port that really isn't going to work that well with modern email applications. 


Come on man. 

 

They are connecting to o365 via port 993 and the issue is I have to have a rule set to ANY/ANY/ANY to allow Linux IMAPs to establish that connection.  So yes that is an issue when I already have a rule allowing those ports (80/443/587/993/995) via app-id, application default to ANY destination which works for everyone else but them.  I shouldn't have to have a specific rule locked down to source IPs to get this traffic to pass through the PAN.   Especially when the PAN is classifying the traffic as two app-ids (outlook-web-online and SSL) I am already allowing.   

 

But if you don't think thats an issue then we can just agree to disagree.  

You've set service to ANY or application-default? Would you mind sharing a screenshot of the rule where you expect traffic to flow through?

And are there differences in the traffic from the windows clients compared to the screens you already posted?


@vsys_remo wrote:

You've set service to ANY or application-default? Would you mind sharing a screenshot of the rule where you expect traffic to flow through?

And are there differences in the traffic from the windows clients compared to the screens you already posted?


 

Both. 

 

Yes there is and I don't see Windows clients using IMAPs/993 to o365 in the logs.  Just a bunch of iphones here and there and all of that traffic gets classified as application unknown.  Whereas the linux clients that I whitelisted all get classified as outlook-web and ssl.  Its just weird.    Someone on reddit mentioned maybe the way linux handles IMAPs vs Windows but I don't know enough about all that to be sure.

 

Rule 14 is the any any any and rule 15 includes the IMAPs app-ids I mentioned prior.  

 

pan-policy.JPG

 

You can see the two rules and what they produce in the logs here:

pa-logs.JPG

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.

View solution in original post

What @gwesson wrote is exactly the reason of this "issue". So because of the way you configured the rule, it is actually expected behaviour.

But the end reason is more likely because there wasn't enough data for paloalto to identify the application, so the session shows incomplete.

In your case I would add an additional rule (below) your known ok rule for application ssl and service 993/tcp.

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!