Maybe some firewall or setting is not allowing Path MTU Detection, the process where routing tables are used to record, for specific hosts on normal routes, the discovered max MTU of the path to that host. This is done by sending DNF flagged packets and getting too-big ICMP messages back, or no response at all (a Path MTU Black Hole, where a firewall or setting prevents the ICMP too-big message).

Packet fragmentation is not uncommon with VPN, for instance, as the VPN wrapper expands the packet size. NAT just rewrites packets in place, does not expand packets, unless they have added NAT features since I was playing with NAT.

Normally, MTU is 1500 on Ethernet. The 802.3 MTU is 1492. I wonder what is trimming the MTU to 1464? Is VPN in play? http://en.wikipedia.org/wiki/Maximum_transmission_unit

Packet fragmentation should not be the end of the world, speed wise, just a bit less than optimal, with all the additional, small fragments. Can you, did someone turn off reassembly to avoid a related denial of service?

Extremely low MSS or RWIN (window size) settings can lower packet size. Low RWIN means the recipient does not have the buffer to hold the data in the packet, which seems very silly, but here we are. A "nice" TCP stack could ack the part it could digest (once it has some space) and discard the part it has no buffer for, but who knows? At one time, for Internet traffic, servers wanted an RWIN that is about 4 * MSS = (MTU - IP Header (20 for IPV4) - TCP Header (20 for IPV4 plus any modulo-4 byte option additions, one of which can send the MTU) ), so 4 packets are sent and then an ack is waited for, but you can go much higher to boost performance at the cost of more potential retransmission in case of error. Originally, RWIN maxed out at 65535, but later (RFC-1323) it was enabled to go higher. http://en.wikipedia.org/wiki/Transmi...Window_scaling RWIN represents the size of an end's TCP socket stream buffer (ret = setsockopt( sock, SOL_SOCKET, SO_RCVBUF, (char *)&sock_buf_size, sizeof(sock_buf_size) ), and RAM has gotten cheaper and more ample. RWIN needs to accommodate all the data you can normally send before the ack of the first packet returns, to not choke throughput. Big transmit socket buffers SO_SNDBUF are nice but not that critical to net throughput; they ensure that the sending app can write/send all the data of one ply off on the API and move on, not blocking. Of course, both ends have an MSS, but MSS is only important at the end receiving the bulk of the data, so the sourcing system can keep sending at max rate without delays. Welcome to the full duplex world of TCP, simulated if not real. Be careful to tune both ends! http://en.wikipedia.org/wiki/Maximum_segment_size http://en.wikipedia.org/wiki/Transmi...ment_structure

So, once you find choke points in the MTU, you need to tune the RWIN, MSS so TCP will use it, tune any apps for big buffers and ensure Path Detection and Black Hole Detection are properly configured, then you can get close to the throughput you paid for, at least in the more popular direction.