<html><body><div style="color:#000; background-color:#fff; font-family:Helvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;font-size:16px"><div id="yui_3_16_0_1_1433295309312_3825"><span id="yui_3_16_0_1_1433295309312_3824">MSS hacking is definitely a hack, it doesn't work on non-TCP protocols, and involves looking far deeper into each and every packet to</span></div><div id="yui_3_16_0_1_1433295309312_3823"><span><br></span></div><div id="yui_3_16_0_1_1433295309312_3822" dir="ltr"><span id="yui_3_16_0_1_1433295309312_3987">- see if they're TCP</span></div><div id="yui_3_16_0_1_1433295309312_3822" dir="ltr">- find the TCP header (which in theory may not always be in the same place because of IP options) <br></div><div id="yui_3_16_0_1_1433295309312_3822" dir="ltr"><span id="yui_3_16_0_1_1433295309312_5695">- then see of they're TCP SYNs, </span></div><div id="yui_3_16_0_1_1433295309312_3822" dir="ltr"><span id="yui_3_16_0_1_1433295309312_3944">- find the TCP MSS option, if it exists (it's optional), and if it does, find where it is, because it isn't required to be in the same place,</span></div><div id="yui_3_16_0_1_1433295309312_3822" dir="ltr"><span id="yui_3_16_0_1_1433295309312_5776">- update the TCP MSS value</span></div><div id="yui_3_16_0_1_1433295309312_3822" dir="ltr"><span id="yui_3_16_0_1_1433295309312_4731">- since the contents of the TCP header has been intentionally changed, recalculate the TCP header checksum and update that too. </span></div><div id="yui_3_16_0_1_1433295309312_4256"><br></div><div id="yui_3_16_0_1_1433295309312_4256" dir="ltr">and after all that, you still haven't fixed your PMTUD problem, you've just pasted over it for just one of the possible protocols that can be used end-to-end over the Internet (which could include TCP hidden inside some other protocol e.g. GRE, PPTP, IPsec, so you haven't even fixed it for all TCP traffic either). MSS hacking should really only be used when it isn't possible or feasible to fix or avoid PMTUD issues.<br></div><div dir="ltr" id="yui_3_16_0_1_1433295309312_4257"><br></div><div dir="ltr" id="yui_3_16_0_1_1433295309312_4257">If you want to avoid the cost of PMTUD for dumbbell MTU paths, it is better to lower the interface MTU on the source and destination hosts, as it will then work for all protocols the hosts' use, not just TCP. There is a DHCPv4 MTU option that can be used to do this, although some hosts may not support it, so it'd be best to check it, and manually change the MTUs on hosts that don't. IPv6 RAs have an MTU option that can be used to lower hosts' interface MTUs, and support for that option by IPv6 hosts is mandatory. You'll lose some performance for transfers between hosts attached to the same LAN with lower host MTUs, but if the majority of traffic is to or from off-link destinations or sources, as most traffic is for most LANs, the loss of LAN performance won't occur very often, and when it does, it may not be significant anyway.</div><div id="yui_3_16_0_1_1433295309312_4259"><br></div><div id="yui_3_16_0_1_1433295309312_4260"><br></div> <div style="font-family: Helvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif; font-size: 16px;" id="yui_3_16_0_1_1433295309312_3679"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif; font-size: 16px;" id="yui_3_16_0_1_1433295309312_3678"> <div dir="ltr" id="yui_3_16_0_1_1433295309312_3681"> <hr size="1" id="yui_3_16_0_1_1433295309312_3945"> <font size="2" face="Arial" id="yui_3_16_0_1_1433295309312_3680"> <b><span style="font-weight:bold;">From:</span></b> Jeremy Visser <jeremy@sunriseroad.net><br> <b><span style="font-weight: bold;">To:</span></b> ausnog@lists.ausnog.net <br> <b><span style="font-weight: bold;">Sent:</span></b> Wednesday, 3 June 2015, 10:51<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [AusNOG] MTU debugging? (Or possibly just a fault with Amazon SES?)<br> </font> </div> <div class="y_msg_container" id="yui_3_16_0_1_1433295309312_3677"><br>On 03/06/15 08:44, Damien Gardner Jnr wrote:<br clear="none">> This one is doing my head in somewhat. I have a customer who needs <br clear="none">> to receive emails from a body who use Amazon SES in the US to send <br clear="none">> emails. I can see the connections coming into the customer <br clear="none">> mailserver, however they then timeout with no data after connecting.<br clear="none"><br clear="none">Sounds like one or both ends are filtering the ICMP Packet Too Big messages.<br clear="none"><br clear="none">If this error is specific to Amazon SES, then they could well be the ones doing this and it will be beyond your control.<br clear="none"><br clear="none">If it comes to it, a hack is to lower the TCP MSS by mangling the TCP SYN packets on both ends of the tunnel. This has the added bonus of saving a RTT by not needing to wait for the ICMP message.<br clear="none"><br clear="none">Linux example:<br clear="none"><br clear="none"> # iptables -t mangle -A FORWARD \<br clear="none"> -o tun0 \<br clear="none"> -p tcp \<br clear="none"> --tcp-flags SYN,RST SYN \<br clear="none"> -j TCPMSS --set-mss=1412<br clear="none"><br clear="none">Cisco example:<br clear="none"><br clear="none"> interface Tunnel0<br clear="none"> ip tcp adjust-mss<div class="qtdSeparateBR"><br><br></div><div class="yqt8679644388" id="yqtfd20628"><br clear="none">_______________________________________________<br clear="none">AusNOG mailing list<br clear="none"><a shape="rect" ymailto="mailto:AusNOG@lists.ausnog.net" href="mailto:AusNOG@lists.ausnog.net">AusNOG@lists.ausnog.net</a><br clear="none"><a shape="rect" href="http://lists.ausnog.net/mailman/listinfo/ausnog" target="_blank">http://lists.ausnog.net/mailman/listinfo/ausnog</a><br clear="none"></div><br><br></div> </div> </div> </div></body></html>