对于上下文来说，我的原始问题是，当我通过VPN（在这种情况下，运行在pfsense中的OpenVPN）连接到我的服务器时，与我的服务器的SSH连接挂起， expecting SSH2_MSG_KEX_ECDH_REPLY 。
互联网指出可能与MTU问题有关。
在尝试debugging时发生这种情况：
ping -s 297 -M do $HOST
工作正常，但是
ping -s 298 -M do $HOST
只是挂起。
MTU在我的机器，主机和pfsense界面都设置为1500（尽pipe界面在pfsense的用户界面中被禁用，我不确定是否应该这样）。
为什么会这样呢？ 阻止数据包的东西是否太大？ 哪里可以find更多的线索？
mtr $HOST表示两跳：到pfsense，然后到服务器本身
在你控制的主机上设置MTU的事实并不意味着它们之间的数据包在理论上可能通过任何媒体与任何MTU进行传输。
为了解决这个问题（除了IP分片机制），存在所谓的“pathMTU发现”机制。
请注意，它依靠ICMP协议正常工作。 除此之外，这意味着如果您的防火墙设置比较严密，则必须具有类似的function
iptables -t nat -A $CHAIN -m state --state RELATED -j ACCEPT
在你的INPUT链的规则中（如果你的防火墙也为它的客户端做SNAT的话，在FORWARD链中）。
“相关”状态意味着当接收到types3的ICMP数据包（目的地不可达/分段要求）时，conntrack子系统决定它与哪个连接相关 ，然后将其传递到netfilter栈的下方。 这种数据包的状态与
iptables已知的“相关”，所以如果你传递了这样的数据包被拒绝 – 就像人们禁用所有东西时经常发生，然后打出最小的漏洞 – P-MTU发现将无法正常工作。
还要注意的是，即使你在你身边“断开”了对P-MTU的适当支持，它仍然可能在两者之间的某个地方被打破。
为了处理它，至less有两个旋钮：
tun-mtu ， tun-mtu-extra和mssfix旋钮在OpenVPN级别限制这些内容。 请注意，这些设置确实会影响性能，所以请作为最后的手段使用。
¹因为虽然不是知识产权交易的一部分，但与其明显相关。
我在家中遇到了一个非常类似的问题，SSH连接（正如我记得的那样）挂在连接设置中的完全相同的地方。 对我来说，调整本地MTU设置有助于减less这个问题，但为了使问题消失， 我不得不打开TCP MTU探测。 这样做后，我没有任何类似的问题。 正如kostix的回答中所讨论的，只有通过iptables允许RELATED数据包没有帮助。
对于Linux，请尝试
sudo sysctl net.ipv4.tcp_mtu_probing=1
可能的值是：
0 =禁用 1 =默认禁用，当检测到ICMP黑洞时启用 2 =始终启用，使用tcp_base_mss的初始MSS 其他操作系统将是相似和不同的。
请注意，这需要在客户端系统上完成，而不是在防火墙上（所以不要在pfSense框中） – 除非您正在从防火墙启动SSH连接。