MTUが小さいVPN間でファイル共有通信をすると通信できなくなる問題

ヤマハルータのデフォルトMTUはVPN区間とそうでない区間で違っていることをご存知でしょうか？
VPN通信では1280Byte、それ以外は1500Byteになっていて、ICMPパケットを破棄する設定になっていると通信できなくなる問題を引き起こすようです。
ファイルサーバー
　　　|
LAN | MTU1500
　　　|
　RTX1100
　　　|
VPN | MTU1280
　　　|
　RTX1100
　　　|
LAN | MTU1500
　　　|
クライアント
それは、ファイル共有サービスについてはファイル共有の仕組みが(アプリケーション層で)MTUからTCPヘッダ分である40バイト引いた1460Byteで事前に分割して送信しようとするのですが、パケット分割禁止のフラグをあわせてつけて送ってしまっているために、VPNを構築している区間が通信できず、再送手続きを要求されてしまうようです。(アプリケーション層で分割しないような通常のTCP通信であればルータ間でファイル分割をしなおすだけなので、再送手続きにまでは至らないのです)
このとき、Packet needs to be fragmented but DF set.を送信元に返して、再送を要求しますが、これがICMPなので、経路で破棄されていると通信できなくなってしまうというわけです。
この問題は、Path MTU Discovery Black Hole）：RFC2923と呼ばれていて、結構有名な問題のようです。詳しくは@ITをご覧ください。図解入りで詳しく説明されています。
ファイル共有サービスはMicrosoft固有の小さな親切大きなお世話で成りたっているようです（パケット分割をするのはアプリケーション層の仕事ではなく、本来ネットワーク層の仕事だから）

(追記)
ちなみにこの問題は、Etherealでネットワークを調査していた際に、TCP segment of a reassembled PDU のメッセージが大量にあったことから発覚しました。ちなみにこのエラーメッセージは、送信（受信）データがMSS（MTU-IPヘッダ、TCPヘッダ）より大きい場合にTCPレイヤで分割された場合に通知されます。
ところで、MTUを調査するにはどうしたらよいのでしょうか？それは、@ITにありますが、
ping -l XXXX -f (あて先IPアドレス)
でXXXXを徐々に大きくしていってPacket needs to be fragmented but DF set.がでた値から1を引いたのに28を足したものがMTUになります。ちなみに、28バイトというのは、pingコマンドが28バイト分のヘッダ情報をつけて送っているためです。