App-id tcp/993 having issues

[drewdown]

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.  

[Raido_Rattameister]

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.

[drewdown]

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.  

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;
}

[drewdown]

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.  

[BPry]

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

[drewdown]

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

[Remo]

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?

[drewdown]

---

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

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

[gwesson · Accepted solution]

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.

[Remo]

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.

[drewdown]

---

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

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

[Remo]

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.

[drewdown]

---

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

[Remo]

---

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

[Remo]

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.