<div dir="ltr"><div dir="ltr"><div>Rajiv,</div><div><br></div><div>Thanks very much for taking the time to provide me with such a detailed response.</div><div><br></div><div>Since I wrote this message I've established with the appliance vendor that in general their systems should work properly with  adjusted MSS values and respect icmp unreachable messages, while our specific system didn't they were unable to reproduce the issue in their lab.</div><br></div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br>d) Some things you need to check after applying the above mss-clamping. <br><br>- Capture the tcp-session packets flowing between appliance1 and peer-router1 lan-interface, and <br>- check whether the MSS value is being negotiated and set to 1240 OR are both appliances1/2 continue to set their MSS to 1460 ignoring the mss-clamping?<br><br></div></div></blockquote><div><br></div><div>We have done this, the packets are adjusted as you would expect by our rules.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br>a) This i think can most probably done by "disabling pmtu-discovery" on both the appliances as below:<br><br>"echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc"<br>- this will ensure that the tcp/udp packets are NOT set with the df-bit flag<br><br>b) The above should be possible on Linux/Unix systems if thats what the appliances are using.<br><br></div></div></blockquote><div><br></div><div>We don't have the necessary access to the OS to make this change.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br><br>c) So FYI, since you are using XFRMi interfaces with strongswan-ikev2 and specifically using swanctl.conf, you may please try the below setting for "clearing the df-bit flag in the outer-ip-hdr of the ESP packets"<br><br><br>connections.<conn>.children.<child>.copy_df (since 5.7.0)        yes(by default)<br><br>- Whether to copy the DF bit to the outer IPv4 header in tunnel mode. <br><br>set this as:<br><br>connections.<conn>.children.<child>.copy_df=no<br><br></div></div></blockquote><div><br></div><div>This is extremely interesting, I didn't notice this setting in my review of the documentation and it looks like it's the setting that I need if the appliances don't properly respect ICMP unreachables. <br></div><div><br></div><div>Thanks again for your time and for bringing this setting to my attention.<br></div><div><br></div><div>-JohnF</div></div></div>