pfSenseを介して動作するVMWare仮想マシンのアップロード速度が遅い
Open-VM-Toolsパッケージ10.1.0,1を使用してpfSense2.3.4-RELEASE（64ビット）経由でルーティングされるさまざまなバージョンのWindowsの仮想マシンでVMWare ESXi6.0を実行するProLiantDL360Gen8およびGen9サーバーがあります。
PfSenseを介して動作する仮想マシンは、アップロード速度が非常に遅いことを示しています。たとえば、ping 2ms、ダウンロード134 Mbps、アップロード0.25 Mbps（ちなみに、リモートデスクトップ接続では0.25 Mbpsが許容速度ですが、実際にはRDPはほとんど機能しません。クライアントが頻繁に数秒間停止する、または更新が四角で発生し、画面の更新に5〜10秒かかる、不安定になる、または再接続することさえあり、RDPを介した作業が事実上不可能になります）。
「netshinterfacetcp set global autotuninglevel = highlyrestricted」など、影響を受けるWindowsマシンを微調整しても、何も変更されませんでした。
PfSenseをバイパスして直接接続している仮想マシンには、これらの問題はありません。アップロードとダウンロードの速度はほぼ同じです。
すべての仮想マシン（pfSense、Windowsなど-すべて）はVMXNET3アダプターを使用しています。
次のオプションは、pfSenseですべてオフになっています。
[ ] Disable hardware checksum offload
[ ] Disable hardware TCP segmentation offload
[ ] Disable hardware large receive offload
PfSenseにはトラフィックシェイプはありません。その理由は何ですか？
「ハードウェアラージレシーブオフロードを無効にする」オプションをオンにすると、再び高速になりますが、無効にしたくないので、pfSenseでVMWare VMXNET3でハードウェアラージレシーブオフロードを使用します。
pdate：すべてのパッチを適用してVMWareを最新の6.5にアップグレードし、pfSenseを3.4.5ベータにアップグレードしました。ファームウェアを最新バージョンに更新しましたが、役に立ちませんでした。
PfSense設定（システム/詳細設定/ネットワーク|ネットワークインターフェイス）で「ハードウェアラージレシーブオフロード」を無効にすることで問題を解決しました
「ハードウェアラージ受信オフロードを無効にする」チェックボックスがあり、「チェック済み」（オン）にしました。
説明には、このオプションについて次のように記載されています。
このオプションをオンにすると、ハードウェアのラージ受信オフロード（LRO）が無効になります。一部のハードウェアドライバーではこのオフロードが機能せず、特定のNICのパフォーマンスに影響を与える可能性があります。これは、マシンの再起動または各インターフェイスの再構成後に有効になります。
他のオプションはチェックされていません。したがって、「ネットワークインターフェース」のオプションは次のとおりです。
[ ] Disable hardware checksum offload
[ ] Disable hardware TCP segmentation offload
[✓] Disable hardware large receive offload
HPのドキュメントによると、Gen8/Gen9（ Broadcom BCM5719チップセット に基づくモデル331）のネットワークアダプターは、次のような標準のTCP/IPオフロード手法をサポートしています。--TCP/IP、UDPチェックサムオフロード（TCO）（ TCPおよびIPチェックサムオフロードをCPUからネットワークアダプターに移動します）-ラージセンドオフロード（LSO）またはTCPセグメンテーションオフロード（TSO）（許可） TCPセグメンテーションはCPUではなくアダプターによって処理されます）。
それが pfSenseがこれらの機能について書いています ：
ハードウェアの設定TCPセグメンテーションオフロード（TSO）とハードウェアラージ受信オフロード（LRO）の設定は、[ネットワーク]タブの[システム]> [詳細設定]で、正当な理由によりデフォルトでオン（無効）になっています。ほぼすべてのハードウェア/ドライバーこれらの設定に問題があり、スループットの問題につながる可能性があります。オプションがオンになっていることを確認してください。sysctlによる無効化も必要な場合があります。
実際、ハードウェア/ドライバーに問題はありませんでしたが、構成の誤りがありました。 LROとTSOをルーターで有効にしないでください。 pfSenseがエンドポイント（DNSサーバーなど）として構成されている場合にのみ、これらのオプションを有効にできます。
FreeBSDバグ追跡エントリ から引用させてください：
私のテストによると、これはバグではなく、すべてが設計どおりに機能しています。 LROをオンにして、pfSenseをゲートウェイとして使用すると、パフォーマンスが大幅に低下します。これは、IP DF（フラグメント化しない）フラグが設定されている発信パケットがLROを介してより大きなパケットに結合されるためです。この（より大きな）パケットをフラグメント化して一致させる必要がある場合もう1つのNIC FreeBSDカーネルはDFフラグを確認し、パケットをドロップしてから、ICMP「到達不能-フラグを立てる必要がある」メッセージを送信者に送り返します。それがまったく機能する理由は、LROの発生を許可せず、一部のパケットが転送される他のトラフィックによるものです。私が行ったテストの1つは、LROをオンにし、scpを使用してファイルをpfSenseアプライアンスに配置することでした。同じパフォーマンスの低下が見られます。1）LROをオンにして良好なパフォーマンスを確認し、アプライアンスに大きなファイルをscpし、2）LROをオンにしてマシンにscpしてICMPの「断片化が必要」を参照してください。 pfSenseアプライアンスはゲートウェイとして使用されているため、LROをオフのままにしておく必要があります。
私は時々これらの問題を実験しました、そして、速い解決策は次のとおりです：マシンを再起動してください。 Windowsのメモリ管理は最善ではなく、再起動が必要になる場合があります。
再起動が機能しない場合は、問題を特定します。サーバーですか、それともクライアントですか？サーバーはTSモードですか、それとも管理専用のTSですか？コンソールに接続していますか、それとも標準のリモートセッションに接続していますか？
また、それらがすべて「新しい」マシン（サーバ、サポートされているマシン）である場合、すべて同じアップデートを入手できると考えてください。たぶん、ターミナルサーバーサービスの変更に対応するために、クライアントの更新が必要です。
直接的な対応として、私は15台のサーバーのグループを6年以上管理してきました。 Windows 2000からWindows 2012 R2へ。私は時々これらの問題を抱えていますが、90％の場合は再起動で解決します。クライアントのアップデートで、さらに10％。
これに関する私の推奨事項は、WSUSサービスを使用し、サーバーにインストールされているすべての更新プログラムの承認を管理することです。
P.s.問題を解決できない場合は、「システムの復元」ユーティリティを使用して、アップデートがインストールされる1週間前にマシンを復元できます。アンインストールは再構成されませんが、システムの復元はすべてのシステムを過去の状態に戻します（アプリのアンインストール、構成の変更の取り消しだけでなく、マシン上のドキュメントやその他のものの削除）。