message security over http

[dieter_b]

How does PA handle message security over http ?

Whereas https secures the communication, message security secures the content.

I would expect PA does not touch http content. But we are having issues with an application that connects to a partners server.

Application throws this error, I guess it's a pretty default .net error:

An error occurred while receiving the HTTP response to http://blabla/blablaConnectorHostService.svc. This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down).

Partner says it has something to do with large transfers that get interrupted. I'm guessing it happens somewhere on the firewall.

[TranceforLife]

Hi,

Good place to start is a traffic logs for this particular session (s), session-end reason and application identification. What can you see?

[BPry]

Look at your threat logs and make sure the PA isn't resseting something due to it identification anything as a possible threat. 

[TranceforLife]

good point threat logs, totally forgot about them :0 busy day............

[dieter_b]

Right now the application seems to generate no logging at all...

I will get back when I have something useful 🙂

[BPry]

@dieter_b make sure that you actually have logging enabled on your security policies that you suspect this should be hitting, sounds like you likely don't have it set to log at start or end. 

[TranceforLife]

or traffic is not even hitting that policy!

[dieter_b]

I have logging enabled for start and end. And I'm pretty sure the traffic should hit the rule. Logging is enabled for almost everything (except for some dns, ntp and "internal" traffic). So if there would be a deny somewhere or a threat blocked, I would see it.

So here's the fun part:

If there's no user-to-ip mapping for the clients ip, nothing is logged.

If there is a user-to-ip mapping, I have log entries.

Session end reasons are tcp-rst-from-client and tcp-fin, so pretty normal.

Known user or not should not even matter. The rule allows Any app/service for Any user from clients fixed ip. And for troubleshooting I don't even have a security profile attached.

In a wireshark capture on the client I only get a dry RST from the server. But that could be the firewall sending a RST.

Would the option "Disable Server Response Inspection" do any good ?

[TranceforLife]

DSRI option may be useful under heavy server load conditions.  Post the security policy here same as PCAP snip. Firewall, as far as l know, will not intercept the session (in your case as you can see tcp-rst-from-client and tcp-fin logs). If the firewall sends you RST you should see its IP address as a source. Firewall only generates a logs based on how it seing the session between client-server.

[dieter_b]

That's all there is to the rule:

Sorry I can't give PCAP, would reveal too much info.

You say firewall ip would be seen as source ip of RST. That's not the case so I assume RST is really coming from remote server.

Can anyone confirm PA does not alter http content ? There's no such thing as http message security decryption ? Or an option that blocks encrypted http messages ?

[TranceforLife]

This is how l understand 3-way handshake :0 If you are not using user-id on trust zone please disable this future under the zone configuration:

[BPry]

@dieter_b if you don't have a profile associated with it the firewall should never issue a reset, since it should just be allowing the traffic. I would take a look at what the identified applications TCP Timeout, TCP Half Closed, and TCP Time Wait settings are. Just for giggles customize those to something completely unreasonably high and see if the issue persists. The firewall may not be seeing any type of response from the other server and terminating the session because it believes the session has gone stale. 

[dieter_b]

---

@TranceforLife wrote:

This is how l understand 3-way handshake :0 If you are not using user-id on trust zone please disable this future under the zone configuration

---

We heavily use user-id for that zone. But for some traffic, that doesn't matter. User Any solves that problem for most cases.

[dieter_b]

---

@BPry wrote:

@dieter_b if you don't have a profile associated with it the firewall should never issue a reset, since it should just be allowing the traffic. I would take a look at what the identified applications TCP Timeout, TCP Half Closed, and TCP Time Wait settings are. Just for giggles customize those to something completely unreasonably high and see if the issue persists. The firewall may not be seeing any type of response from the other server and terminating the session because it believes the session has gone stale. 

---

Good idea, I will give this a try. I just hope our session limit is not reached, since we're talking about http 🙂

[dieter_b]

I have pretty much default general session timeouts

Connections are dropped way faster than that.

Where can I find application specific timeouts ?