I'm facing issue with an embedded device webpage. Webpage of the device works fine when used directly in local intranet but when its behind one corporate firewall it becomes extensively slow. When i wireshark the packets i found
Please help me with this i'm trying to figure this out..any help will be greatly appreciated. Please let me know if you need wireshark captures on both ends i have captured at both ends in parallel asked 12 Feb '14, 05:26  Sumeet edited 12 Feb '14, 06:20  Kurt Knochner ♦ |
2 Answers:
well, that's a first sign for the source of the problem ;-) If it's a firewall with content inspection for HTTP (AV, URL filter, etc.), it's absolutely 'normal' that the access through the firewall is slower than in the local network. How much slower, depends on the capacity of the firewall, the firewall configuration, etc.
that's the second sign for the source of the problem. Either there is a transparent proxy on the firewall (see content inspection above) or the port change is the result of a NAT operation. But then you should see a different source IP as well.
hard to answer. It depends who sets the ECN flag. If it's the client (browser), it would be kind of strange. If it's the firewall (or a QoS or WAN acceleration device), I would understand it for certain conditions.
Sure. Every proxy will slow down the connection, compared to a direct local access, as the proxy might also have content inspection (AV, URL filtering) enabled, which obviously costs some time to perform. How much time it costs, depends on the capacity of the proxy, the proxy configuration and where the proxy is placed in your network.
Go ahead and post them somewhere (google drive, dropbox, cloudshark). However, based on your description and my experience, I recommend to talk to the firewall/proxy admins how to solve the problem by configuring exceptions for your web gui access. Regards answered 13 Feb '14, 14:55 Kurt Knochner ♦ |
The ip addresses 144.191.148.4/5 are actually a NAT devices. In this trace there are at least two different clients coming from the same NATed IP address.
As for the 'extensively slow' problem: You don't support window-scaling in your SYN_ACKs which over long latency connections will be causing performance degradation as the advertized windowsizes will never exceed 64k. answered 13 Feb '14, 22:43  mrEEde Thanks for explanation so just to understand better the SYN with ECN bit set are not valid/genuine http webpage request its some kind of probe which network infrastructure is trying to do [Linux requests]? Thanks again for your help (14 Feb '14, 04:59) Sumeet If you know your clients are not on Linux, then it must be something else. The fact that after the failing retransmissions of the linux SYNs the client ip address changes to its "twin brother" 144.191.148.5 makes me think it might be a loadbalancer that checks for availaility and then decides that it doesn't have connectivity so better hand off the next requests to the other NAT device ... (14 Feb '14, 05:30) mrEEde |
The Linux client has ECN,CWR set in its SYN packet which your server silently discards. Not responding to those SYNs might not be a good idea if those requests are validly coming in. It might howerver also be a mo nitoring device probing your server. So if you reply without those bits being set you will at least get a tcp session and see what this linux client is trying to do...
We are developing this embedded device and question what i have is our current webserver on device doesn't respond to any of the SYN with ECN flag set even the flag is not set at IP level. So we need your expert opinion should it respond to it or not and why its set? other SYN doesn't have it...please look at the wireshark capture and suggest. Again many thanks for your help... https://www.dropbox.com/s/euslq9yac6gmaxn/WireShark%20FEB%2010%20%20Capture.pcapng please let me know if you have any problem accessing the file..
All clients have the same IP address, so there is either NAT or a (reverse or transparent) proxy in place.
The frames with the ECN flag set have a different IP TTL and IP ID sequence, so it's likely that it's two (or) more different systems.
So, it's rather unlikely, that your firewall/proxy modified those frames and set the ECN flag. It's the (external) clients that do it on their own, because their TCP/IP stack is configured in that way.
As a result, you'll have to support connections with the ECN flag on your embedded device if you want to support those clients as well. As an alternative, you could implement a reverse proxy in front of the embedded device, that handles those connections, but I guess that embedded device is meant to be working on its own in the wild, so a reverse proxy is probably not an option.
O.K. can you please post both capture files?