我们有运行VMWare ESXi 6.0的ProLiant DL360 Gen8和Gen9服务器，虚拟机使用各种版本的Windows，通过带有Open-VM-Tools软件包10.1.0.1的pfSense 2.3.4-RELEASE（64位）进行路由。
通过pfSense工作的虚拟机performance出非常低的上传速度，例如：ping 2ms，下载134 Mbps，上传0.25 Mbps（顺便说一下，远程桌面连接的速度可以达到0.25 Mbps，但实际上RDP几乎不能工作，客户经常停顿几秒钟，或刷新正方形，5-10秒刷新屏幕，是不稳定的，有时甚至重新连接 – 通过RDP实际上是不可能的）。
调整受影响的Windows机器，如“netsh接口tcp设置全球autotuninglevel =高度限制”没有改变任何东西。
直接连接虚拟机，绕过pfSense，没有这些问题 – 他们有相同的上传和下载速度。
所有虚拟机（pfSense，Windows等）都使用VMXNET3适配器。
以下选项均未在pfSense中选中：
[ ] Disable hardware checksum offload [ ] Disable hardware TCP segmentation offload [ ] Disable hardware large receive offload pfSense上没有交通形状。 可能是什么原因？
如果我检查选项“禁用硬件大接收卸载”，它会变得很快，但我不想禁用它，我希望pfSense使用VMWare VMXNET3的硬件大接收卸载。
更新：我已经将VMWare升级到了最新的6.5，所有补丁和pfSense都升级到3.4.5testing版，已经将固件升级到了最新版本，并没有帮助。
我已经通过在pfSense设置（系统/高级/networking|networking接口）中禁用“Hardware Large Receive Offloading”来解决这个问题。
有一个checkbox“禁用硬件大接收卸载”，我已经把它变成“检查”（ON）。
说明在这个选项上说明如下：
选中此选项将禁用硬件大接收分载（LRO）。 这种卸载在某些硬件驱动程序中被破坏，并可能会影响某些特定NIC的性能。 这将在机器重新启动或重新configuration每个接口后生效。
其他选项未选中。 所以现在“networking接口”中的选项如下：
[ ] Disable hardware checksum offload [ ] Disable hardware TCP segmentation offload [✓] Disable hardware large receive offload
根据HP文档，Gen8 / Gen9（基于Broadcom BCM5719芯片组的 331型号）上的networking适配器支持标准的TCP / IP卸载技术，包括： – TCP / IP，UDP校验和卸载（TCO）（移动TCP和IP校验和卸载从CPU到networking适配器）。 – 大发送卸载（LSO）或TCP分段卸载（TSO）（允许TCP分段由适配器而不是CPU处理）。
这就是pfSense写这些function的原因 ：
networking选项卡上的系统>高级下的硬件TCP分段卸载（TSO）和硬件大容量接收卸载（LRO）的设置默认为选中（禁用）。 几乎所有硬件/驱动程序都有这些设置的问题，并且可能导致吞吐量问题。 确保选项被选中。 有时通过sysctl禁用也是必要的。
实际上没有硬件/驱动程序有问题，但configuration错误。 LRO和TSO不应该在路由器上启用。 只有将pfSenseconfiguration为端点（例如DNS服务器）时，才可以启用这些选项。
让我引用FreeBSD的bug追踪条目 ：
从我的testing中，这不是一个错误，一切都按照devise工作。 当LRO打开并使用pfSense作为网关时，我看到性能大幅下降。 这是由于始发分组具有IP DF（不分段）标志集合，然后通过LRO将其组合成更大的分组。 当这个（更大的）数据包需要被分割以匹配另一个NIC时，FreeBSD内核看到DF标志，丢弃数据包，然后向发送者发送一个ICMP“unreachable-need to frag”消息。 它的原因完全是由于其他stream量不允许LRO发生，一些数据包被转发。 我做的一个testing是开启LRO并使用scp将文件放到pfSense应用装置上，从而获得了良好的性能（没有看到性能下降）。 我会感兴趣，如果你1）看到良好的性能与LRO打开并scp一个大文件到设备和2）看到ICRO“需要碎片”LRO打开和scp到远程端的机器。 由于pfSense设备正在用作网关，因此应closuresLRO。
有时我已经试验过这些问题，而快速解决scheme是：重新启动机器。 Windows内存pipe理不是最好的，有时需要重启。
如果重新启动不起作用，请确定问题。 服务器还是客户端？ 服务器处于TS模式，还是TS仅用于pipe理？ 您是连接到控制台还是连接到标准的远程会话？
另外，如果他们都是“新”机器（服务器，支持的），他们可以得到所有相同的更新。 也许，你需要更新客户端来处理terminal服务器服务的变化。
作为直接响应，我已经pipe理了一组15台服务器超过6年。 从Windows 2000到Windows 2012 R2的。 我有时会遇到这些问题，但是有90％的时间在重启后解决。 另有10％，客户端更新。
我对此的build议，使用WSUS服务，并pipe理服务器上安装的所有更新的批准。
Ps如果无法解决问题，则可以使用“系统还原”实用程序在一个星期前还原计算机，然后再安装更新。 卸载不会重新configuration，但系统还原会将所有系统恢复到过去状态（卸载应用程序，撤消configuration更改，还会删除文档或机器上的其他内容）。