Hi there! I have the following scenario: Client <-> Tunnel <-> VPN Server <-> FileServer The client is requesting a file on a fileserver on the internet (ubuntu hosted in windows azure cloud) through a VPN that is terminated the VPN server (hosted in Germany at a different provider). Now when performing this download I have a very strange effect: on the client and on the file server packets are only being sent with max packet length 1390 which is fine. Nonetheless, when performing TCPDUMP traces on the VPN server I suddenly see occasional jumbo frames that exceed the allowed packet length of 1390. Suddenly there are TCP packets that have a length of twice the allowed packet size and the TCP segments are also combined accordingly. This is causing a coughup on the VPN server causing the connection to drop. But I cant see the fileserver sending those jumbo frames. I assume that those jumbo frames were not transmitted over the internet, so the ubuntu fileserver on windows azure probably didnt sent them out, but maybe a loadbalancing/optimizing element in the datacenter of the VPN server? is that actually possible? Would an intermediate network element be able to combine multiple TCP packets that were originally sent from a location to a single jumbo framed packet? This is the capture on the VPN server: And this is the capture on the file server: I can also upload the packet traces if required. Thanks & Best Regards Qiong Wu asked 28 May '14, 14:17 Freundschaft edited 28 May '14, 14:18 |
One Answer:
This may be a problem of where and how you are capturing the packets. I wrote a new blog post recently that explains some of those effects you mention here: http://blog.packet-foo.com/2014/05/the-drawbacks-of-local-packet-captures/ answered 29 May '14, 02:26 Jasper ♦♦ |
good point, but is there actually any way of verifying whether this is connected with TCP optimization done on the local system or actual data on the line being too large? As far as I get it from your post, the only thing I can do is connect a TAP and check whats REALLY going over the line. Thanks for the input!
well, if you did capture locally on a system that gives you strange results (like oversized packets) it is a safe bet that this is the reason.
A dead giveaway of TCP optimization is if the TCP checksum is 0. Everything else is hard to say.
thanks a lot for the help! I'll mark the answer as correct answer.
by the way: I have another question, if I use a virtual TAP device to mirror the traffic on the network interface that I want to monitor and capture on that interface, would I also produce these side effects?