Mucker's questions

I only really need help understand the following image, but I will give the background for context.

We have an app that is configured to use a proxy on port 8080 and requires Internet access. At random times throughout the day, the app fails to connect and just dies. We are trying to figure out the cause. We have ruled out FW and proxy URL rules (it's always hitting the same URL when it works and fails anyway). I think the issue is network related on a performance issue on the proxy itself. To get to the bottom of it I have been taking network captures when it happens.

If you look at the following image, it is a snippet with the IP details removed. The first line with source "42" is the client machine making a TLS request through the proxy (IP 35) on port 8080. NOTE: It usually works and requests the same URL/IP, but this is one of the times it failed. The bottom window is the details of the first green line.

The highlighted part "Next sequence number" matches the ACK of the last returned packet from 35 (2nd to last line). This is 35 essentially replying to the client stating it has received all the data that was sent to it (this means the device is up as it acknowledgesdreceipt of the data (meaning no FW or network issues)). Notice that it does not send any data back though. Immediately after this the client issues a TCP RST. Here is my interpretation but I'd like someone to verify, as my TCP skills are a little rusty.

The client is sending some form of request to the proxy, but for some reason the proxy is not responding (at the application layer). Since the proxy DOES reply with TCP ACKs, this means that at the networking layer all is good. This would imply that when the data is passed up the networking stack to the proxy itself, it is the proxy that is dropping the connection. Why it does that I do not know yet, but I am looking for clarification so that I can speak to the proxy team and tell them they need to investigate this (they don’t think it is the proxy).

Other evidence to support my case is that the 4 first lines you see in the image before the RST are repeated many times. Again, this implies that the client is re-sending whatever request it has but never gets a response; and then it eventually gives up and issues a reset.

There is apparently a load balancer that sits in front of the proxy, and the proxy is actually several machines. I have a feeling that the there is an issue with one of them at the backend and the LB is not removing the node from the pool, and therefore sends the data to a black hole potentially.

I am looking for a second opinion, does this summary I have above look accurate based on the capture?

I am interested in PPTP passthrough here not Ipsec etc. I have looked on the net but can't find out how it is done. I am an IT administrator myself and know a lot routing, NAT etc. I think I know how it works but have found it officially. I am just curious and would like someone to confirm my theory. here it is.

The problem first of all comes down to NAT when sharing one public IP address. NAT works using PAT to share the one public IP with with several private IP's. Without ports and PAT this woudn't be possible as when the packets come back from the destination they would all be addresseed to the public IP address. The router would have no way to distinguish the different packets from each other. By using the source ports and PAT it can though.

PPTP uses GRE which in itself is a different protocol to TCP or UDP. It doesn't actually use ports at all so this poses a problem with traversing a NAT device. When the packets come back from the internet to the router how can tell it which private IP these packets belong to without using PAT?

I think it works by monitoring the 1723 "channel". Using PPTP Passthrough the router associates the 1723 connection (which will use PAT/NAT) with the GRE packets going to the same destination IP. On other words when the GRE packets come back it doesn't know where to send them so it looks like the 1723 connection instead to find the private IP address. Is this correct, if not then how does it work?

I know there is NAT-T but I am led to believe that this is different to VPN passthrough...