MTU/MSS とは｜PPPoE・IPsec で通信が止まる原因と対策

はじめに

ネットワークの設定は正しいはずなのに「小さい通信は問題ないが、大きなデータを送ると止まる」「Web ページの一部だけ表示されない」「VPN 越しの特定サイトだけ開けない」といった症状に遭遇することがあります。ping は通り、DNS も引けるのに特定の通信だけが失敗するこうした事象は、MTU と MSS の設定が関係しているケースが少なくありません。

MTU と MSS は、PPPoE や IPsec、IPoE（IPv4 over IPv6）といったトンネル・カプセル化を伴う環境で特に問題になりやすく、値の意味と決まり方を理解していないと原因の切り分けに時間がかかります。この記事では、機器別の設定手順に入る前提となる MTU/MSS の考え方を、仕組みからトラブルの原因、調整方法まで一通り整理します。

結論を先に述べると、MTU はある区間で一度に送れる IP パケットの最大サイズ、MSS はその中で TCP が運べるデータの最大サイズであり、両者はヘッダー分だけずれた関係にあります。トンネルを通すと利用可能な MTU が縮み、その縮小を TCP 側へ正しく伝えられないと通信が止まります。TCP では MSS クランプで調整できますが、MSS は TCP 固有の仕組みであり、UDP には効かないという非対称性が実務では重要になります。

MTU と MSS の基礎

MTU と MSS はどちらも「一度に送れるサイズの上限」を表しますが、扱う層が異なります。まず両者の定義と関係を整理します。

MTU とは

MTU（Maximum Transmission Unit）は、あるネットワーク区間で分割せずに一度に送信できる IP パケットの最大サイズを指します。単位はバイトで、イーサネットの標準的な MTU は 1500 バイトです。この 1500 バイトは IP ヘッダーやその上位（TCP/UDP）のヘッダーを含んだ値で、イーサネットフレームのヘッダー（宛先・送信元 MAC、タイプなど）や FCS は含みません。

MTU は物理・データリンクの種類や、後述する PPPoE などのカプセル化によって変わります。送信したい IP パケットが経路上のある区間の MTU を超えると、そのパケットは分割（フラグメント）されるか、条件によっては破棄されます。

MSS とは

MSS（Maximum Segment Size）は、TCP が 1 つのセグメントで運べるデータ（ペイロード）の最大サイズです。ここで重要なのは、MSS はデータ部分のみを数え、IP ヘッダーと TCP ヘッダーを含まないという点です。

参考: RFC 879（The TCP Maximum Segment Size and Related Topics）
“The MSS counts only data octets in the segment”
（MSS はセグメント内のデータオクテットのみを数える）
https://www.rfc-editor.org/rfc/rfc879.html

MSS は TCP コネクション確立時の 3 ウェイハンドシェイクで、SYN パケットのオプションとして各ホストが「自分はこのサイズまで受け取れる」と相手へ通知します。RFC 879 が指摘しているとおりこれは通知（announcement）であって、双方の値をすり合わせる交渉（negotiation）ではありません。実際の通信では、両端が通知した MSS のうち小さいほうが上限として使われます。

MTU と MSS の関係

MTU と MSS は、IP ヘッダーと TCP ヘッダーの分だけずれた関係にあります。オプションを含まない標準的なヘッダーサイズは、IPv4 ヘッダーが 20 バイト、TCP ヘッダーが 20 バイトです。

参考: RFC 6691（TCP Options and Maximum Segment Size (MSS)）
“The size of the fixed TCP header is 20 bytes”
（固定の TCP ヘッダーのサイズは 20 バイトである）
https://datatracker.ietf.org/doc/html/rfc6691

このため、IPv4 ＋ TCP の一般的なケースでは次の関係が成り立ちます。

MSS = MTU - IPヘッダー(20) - TCPヘッダー(20)

イーサネット標準の MTU 1500 バイトなら、MSS = 1500 - 20 - 20 = 1460 バイトが基本値になります。なお IPv6 では基本ヘッダーが 40 バイトのため、同じ MTU 1500 でも MSS = 1500 - 40 - 20 = 1440 バイトとなり、IPv4 より 20 バイト小さくなります。この 20 バイトの差は、IPoE（IPv4 over IPv6）のようにパケットを IPv6 でカプセル化する構成でオーバーヘッドとして効いてきます（詳細は後述します）。

ここで押さえておきたいのは、MTU が変われば適切な MSS も変わるという点です。トンネルやカプセル化で実効的な MTU が小さくなった場合、MSS もそれに合わせて下げないと、TCP は経路に収まらないサイズのセグメントを送り続けることになります。

MSS は TCP 固有（UDP には MSS がない）

MSS は TCP のオプションとして定義された仕組みであり、UDP には MSS という概念がありません。UDP はコネクションレスで、TCP のようなハンドシェイクを持たないため、送信サイズを事前に通知・調整する仕組みそのものがないためです。

この違いは、後述する MSS クランプ（adjust-mss）による調整が TCP にしか効かないという実務上の非対称性につながります。DNS・QUIC・IPsec の IKE・VXLAN・L2TPv3（UDP カプセル化時）など、UDP 上で動く通信は MSS クランプの対象外です。「TCP 通信は MSS クランプを入れたら直ったのに、特定の UDP アプリだけ通らない」という切り分けの難しい事象は、この非対称性が背景にあります。UDP でのサイズ超過にどう対処するかは、対策のセクションで改めて整理します。

パケット分割の仕組みとフラグメンテーション

IP パケットが経路上の MTU を超えたとき、何が起きるかを整理します。ここを理解しておくと、次のセクションで扱う障害の原因を切り分けやすくなります。

フラグメントと再構築の負荷

送信された IP パケットが、経路上のある区間の MTU より大きい場合、そのパケットは複数の小さな断片（フラグメント）に分割されて転送されることがあります。分割されたフラグメントは、最終的に宛先ホストで元の 1 つの IP パケットへ再構築（リアセンブル）されます。

フラグメンテーション自体は IP の仕様に含まれる正常な動作ですが、実務上はいくつかの負荷・リスクを伴います。1 つは、宛先での再構築に CPU とメモリを消費する点です。もう 1 つは、フラグメントのうち 1 つでも失われると、IP には部分再送の仕組みがないため、元のパケット全体が失われる点です。この場合、上位が TCP なら TCP がパケット全体を再送しますが、スループットの低下につながります。こうした理由から、経路上でのフラグメントは可能な限り避け、送信側が最初から適切なサイズで送る設計が推奨されます。

なお IPv4 と IPv6 では、経路途中のルーターによる分割の扱いが異なります。IPv4 では途中のルーターがフラグメントできますが、IPv6 では経路途中のルーターはフラグメントを行わず、分割は送信元ホストのみが担う仕様になっています。IPv6 環境では、経路の MTU に収まらないパケットは途中で破棄され、後述の ICMPv6 で送信元へ通知される動作が基本となります。

DF ビットと ICMP “Fragmentation Needed”

IPv4 ヘッダーには DF（Don’t Fragment）ビットがあります。このビットが立っているパケットは「途中のルーターで分割してはならない」という指示を持ちます。DF ビットが立ったパケットが、次のホップの MTU を超えて転送できない場合、ルーターはそのパケットを破棄し、送信元へ ICMP エラーを返します。

このとき返される ICMP メッセージが、Type 3（Destination Unreachable）Code 4（Fragmentation Needed and Don’t Fragment was Set）です。このメッセージには、次のホップで通せる MTU の値が含まれており、送信元はこの値を見て送信サイズを下げられます。IPv6 の場合は、対応する通知として ICMPv6 の Packet Too Big（Type 2）が使われます。

現代の OS（Windows・Linux・macOS など）は、TCP 通信で DF ビットを立てるのが一般的です。つまり、経路上に MTU の小さい区間があると、そのままでは破棄され、ICMP による通知を頼りにサイズ調整が行われます。この通知が届かない場合に何が起きるかは、後述の PMTUD ブラックホールで扱います。

PMTUD の動作

PMTUD（Path MTU Discovery）は、送信元と宛先の間の経路全体で通せる最小の MTU（Path MTU）を、DF ビットと ICMP を使って動的に見つける仕組みです。RFC 1191 で定義されています。

参考: RFC 1191（Path MTU Discovery）
“sends all datagrams on that path with the DF bit set”
（その経路上のすべてのデータグラムを DF ビットを立てて送信する）
https://datatracker.ietf.org/doc/html/rfc1191

動作の流れは次のとおりです。送信元は、まず自分の最初のリンクの MTU を経路全体の MTU と仮定し、DF ビットを立ててパケットを送ります。経路上に MTU の小さい区間があると、そこでパケットが破棄され、ICMP Type 3 Code 4 が次ホップの MTU 値とともに返ります。送信元はその値まで送信サイズを下げて再送します。これを繰り返し、経路全体を分割なしで通れるサイズへ収束させます。経路が変わって Path MTU が小さくなった場合も、最初に超過したパケットが ICMP を引き起こすことで、新しい値が検出されます。

PMTUD は、ICMP のエラーメッセージが送信元まで正しく届くことを前提としています。この前提が崩れると通信が止まるため、次のセクションで扱う障害の主要因になります。

TCP と UDP でのフラグメント挙動の違い

TCP は PMTUD を透過的に利用します。TCP はデータを連続したストリームとして扱い、パケット境界に依存しないため、Path MTU に合わせてセグメントサイズを下げれば、アプリケーションを意識させずに調整が働きます。

一方 UDP は挙動が異なります。UDP アプリケーションが DF ビットを立てずに送信した場合、そのデータグラムは経路上で必要に応じてフラグメントされます。DF ビットを立てて送信する場合は PMTUD に依存し、Path MTU を超えるデータグラムは破棄され ICMP で通知されます。DF を立てるかどうかは、Linux では IP_MTU_DISCOVER、Windows では IP_DONTFRAGMENT といったソケットオプションでアプリケーション側が制御します。UDP には TCP の MSS のようなサイズ通知の仕組みがないため、サイズ超過への対処はアプリケーションや下位の設計に委ねられる点が、TCP との大きな違いです。

MTU/MSS が原因で起きる通信障害

ここまでの仕組みを踏まえ、MTU/MSS が関係する典型的な障害と、その切り分けの勘所を整理します。

典型症状（小さい通信は通るが大きい通信で止まる）

MTU/MSS 起因の障害には特徴的な症状があります。小さいサイズの通信は成功するのに、大きいサイズの通信だけが失敗するというものです。具体的には、次のような形で現れます。

• ping（小さいパケット）は通るが、大きなファイル転送や特定の Web ページ表示で止まる
• TCP コネクション自体は確立する（SYN/ACK は小さい）が、データ転送の途中でハングする
• Web ページの HTML は表示されるが、画像など大きなレスポンスの読み込みが完了しない
• VPN 越しの一部のサイトやアプリだけが開けない

これらは、コネクション確立時の小さいパケットは経路を通れるものの、実データを載せた大きいパケットが MTU 超過で破棄され、かつその事実が送信元へ正しく伝わっていないときに起きる典型パターンです。「一部だけ動く」ため、経路や DNS の問題と切り分けにくいのが特徴です。

PMTUD ブラックホール（ICMP フィルタ）

PMTUD は ICMP のエラーメッセージが送信元へ届くことを前提としています。ところが、経路上のファイアウォールやルーターが ICMP を一律に遮断していると、Type 3 Code 4 の通知が送信元へ返りません。この状態を PMTUD ブラックホールと呼びます。

この状態では、送信元は「パケットが大きすぎて破棄された」という事実を知る手段がなく、同じサイズのパケットを送り続けます。結果として、大きい通信だけが応答なく失敗し続けます。セキュリティ強化の目的で ICMP を広く遮断した環境で起こりやすく、PMTUD を機能させるには、必要な ICMP（IPv4 では Type 3 Code 4、IPv6 では Packet Too Big）を通す設定が前提になる点は運用上の重要なポイントです。ICMP を遮断せざるを得ない場合の代替策として、後述の MSS クランプがあります。

トンネルによる実効 MTU の縮小

PPPoE・IPsec・GRE・IPoE（IPv4 over IPv6）といったカプセル化を伴う構成では、元のパケットに追加のヘッダーが付くため、実際にデータへ使える MTU（実効 MTU）が標準の 1500 バイトより小さくなります。たとえば PPPoE ではヘッダー分だけ MTU が下がり、IPsec では暗号化のためのヘッダーが加わります（具体的なバイト数は次のセクションで整理します）。

問題は、この実効 MTU の縮小が、通信するホストからは見えにくい点です。ホストは自分の LAN 側インターフェースの MTU（多くは 1500）を基準にパケットを送るため、途中のトンネル区間で MTU を超え、前述のブラックホールや破棄が起きます。トンネル構成では、MTU の縮小を見込んで送信側のサイズを調整する対処が必要になります。

UDP アプリで顕在化するケース（DNS・QUIC・IKE 等）

MTU/MSS の問題は、UDP を使う通信でより切り分けが難しくなります。MSS は TCP 固有の仕組みで、UDP には効かないため、TCP 向けの MSS クランプで対処しても UDP 通信は救済されないためです。UDP 上で動き、サイズ超過の影響を受けやすい代表例には次のものがあります。

• DNS: 大きな応答（DNSSEC や TXT レコード等）で UDP のサイズが大きくなり、フラグメントや破棄が起きる
• QUIC（HTTP/3 など）: UDP 上で動作し、Path MTU を超えると影響を受ける
• IPsec の IKE: 鍵交換のメッセージ（証明書を含む場合など）が大きくなり、UDP フラグメントの問題が出る
• L2TPv3 や VXLAN（UDP カプセル化時）: トンネル自体が UDP のため、オーバーヘッド分の影響を受ける

「TCP のサイトは MSS クランプで改善したのに、DNS や特定の UDP アプリだけ不安定」という事象は、この非対称性が背景にあります。UDP に対する具体的な対処（MTU 調整・PMTUD の確保・アプリケーション側の対応）は、後半の対策セクションで整理します。

カプセル化によるオーバーヘッドと実効 MTU

PPPoE・IPoE・IPsec・GRE・L2TPv3 のように、元のパケットを別のヘッダーで包む（カプセル化する）構成では、追加ヘッダーの分だけデータに使える MTU が小さくなります。このセクションでは、代表的な方式ごとに追加されるバイト数と、そこから導かれる実効 MTU・MSS の目安を整理します。

冒頭で結論を述べると、PPPoE や GRE のように固定バイト数で決まる方式と、IPsec や L2TPv3 のように条件で変動する方式があり、後者は単一の値で語れない点が調整の難しさにつながります。以下の数値は標準的なヘッダー構成に基づく目安で、回線事業者や機器の実装によって推奨値が異なる場合があります。

PPPoE（固定 8 バイト）

PPPoE は、PPPoE ヘッダー 6 バイトと PPP プロトコル ID 2 バイトの合計 8 バイトが追加されます。このため、標準 MTU 1500 バイトの回線では PPPoE 区間の MTU が 1492 バイトになります。

参考: RFC 2516（A Method for Transmitting PPP Over Ethernet (PPPoE)）
“the PPPoE header is 6 octets and the PPP Protocol ID is 2 octets”
（PPPoE ヘッダーは 6 オクテット、PPP プロトコル ID は 2 オクテット）
https://www.rfc-editor.org/rfc/rfc2516.html

MTU 1492 に対応する TCP の MSS は、IPv4 では 1492 - 20（IP）- 20（TCP）= 1452 バイトが基本値です。PPPoE を使う環境で MTU/MSS の調整対象としてよく登場するのがこの 1492/1452 という値です。なお RFC 4638 に対応した環境では 1492 を超える MTU を利用できる場合がありますが、経路全体がジャンボフレームに対応している必要があります。

日本のフレッツ回線など、事業者によっては独自の推奨 MTU/MSS 値を案内している場合があります。実際の設定値は、利用する回線事業者の公式情報で確認することをおすすめします。PPPoE の機器別設定は、関連記事『NEC IX の PPPoE 設定手順』『YAMAHA RTX の PPPoE 設定手順』もあわせて参照してください。

IPoE（IPv4 over IPv6: MAP-E・DS-Lite）

IPoE の IPv4 通信（MAP-E や DS-Lite など、IPv4 over IPv6 方式）は、日本の読者が MTU で最も戸惑いやすい構成です。これらの方式では、IPv4 パケットを IPv6 パケットで包んで運ぶため、IPv6 ヘッダーの 40 バイトがオーバーヘッドとして加わります。標準 MTU 1500 バイトの場合、内側の IPv4 パケットに使える実効 MTU は 1460 バイトになります。

参考: RFC 6908（Deployment Considerations for Dual-Stack Lite）
“accounts for the additional overhead (40 bytes)”
（追加のオーバーヘッド（40 バイト）を考慮する）
https://datatracker.ietf.org/doc/rfc6908/

実効 MTU 1460 に対応する MSS は 1460 - 40 = 1420 バイトが目安です。PPPoE の 1492 とは異なる値になる点に注意が必要で、「PPPoE 向けに 1454 や 1452 を設定していたが、IPoE に切り替えたら通信が不安定になった」といった事象は、この 40 バイトのオーバーヘッド差を反映できていないことが原因になり得ます。IPoE の設定については、関連記事『IPoE の設定手順』も参照してください。

なお MAP-E と DS-Lite は同じ「IPv4 over IPv6」でも方式が異なり、事業者やサービスによって推奨値や仕様が変わる場合があります。個別の推奨値は各サービスの公式情報での確認をおすすめします。

IPsec（暗号方式・モード・NAT-T で変動）

IPsec のオーバーヘッドは固定値ではなく、いくつかの条件の組み合わせで変わります。単一の数値で「IPsec は何バイト」と断定できない点が、MTU/MSS 設計で最も注意すべきポイントです。オーバーヘッドを左右する主な要素は次のとおりです。

 モード: トンネルモードは新しい外側 IP ヘッダー（IPv4 で 20 バイト）が加わる。トランスポートモードは元の IP ヘッダーを流用するため、その分小さい。

 暗号方式: AES-GCM は暗号化と認証を 1 つの処理で行うため、認証タグ（ICV）が別途必要な AES-CBC ＋ HMAC 構成よりオーバーヘッドを抑えやすい。

 ブロック暗号のパディング: AES は 16 バイト単位で処理するため、ペイロード長に応じて 0〜15 バイトのパディングが加わる。

 NAT-T（UDP カプセル化）: 経路上に NAT がある場合、ESP を UDP で包むため 8 バイトの UDP ヘッダーが追加される。

一例として、ESP トンネルモードで AES-GCM-128 を用いる場合、外側 IP ヘッダー 20 ＋ ESP ヘッダー 8 ＋ IV（nonce）8 ＋ 認証タグ 16 ＋ ESP トレーラー・パディングを合わせて、おおむね 54〜73 バイト程度のオーバーヘッドになります。NAT-T を使う場合はさらに 8 バイトが加わります。パディングはペイロード長で変動するため、同じ設定でもパケットごとに数バイトの差が出ます。

こうした変動があるため、実務では余裕を見た固定値を用いる運用が一般的です。Cisco のドキュメントでは、多くの GRE ＋ IPsec の組み合わせを吸収できる値として、トンネルインターフェースの MTU を 1400 バイト、TCP の adjust-mss を 1360 バイトに設定する例が示されています。

参考: Cisco（Resolve IPv4 Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPsec）
“The MTU value of 1400 is recommended because it covers the most common GRE + IPsec mode combinations”
（多くの一般的な GRE ＋ IPsec モードの組み合わせを吸収できるため、MTU 値 1400 が推奨される）
https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html

クラウド VPN でも同様に、各サービスがオーバーヘッドを見込んだ推奨 MTU を案内しています（実装により値は異なるため、利用するサービスの公式情報で確認することをおすすめします）。IPsec の設計上の前提や設定については、関連記事『IPsec の設定手順』もあわせて参照してください。

GRE（固定 24 バイト）と L2TPv3（構成で変動）

GRE は、外側 IPv4 ヘッダー 20 バイトと GRE ヘッダー 4 バイトの合計 24 バイトが基本の追加分です（RFC 2784）。標準 MTU 1500 バイトなら実効 MTU は 1476 バイト、MSS は 1476 - 40 = 1436 バイトが目安になります。ただし GRE のチェックサムやキー、シーケンス番号のオプションを有効にすると、それぞれ 4 バイトずつ増えます。

L2TPv3 は、運ぶ対象（ペイロード）の種類やオプションによってオーバーヘッドが変わります。IP で直接カプセル化する場合（プロトコル 115）、外側 IP ヘッダー 20 バイトに加え、セッション ID 4 バイト、Cookie 0/4/8 バイト、シーケンス用の擬似ワイヤ制御カプセル化 4 バイト、さらに運ぶ L2 フレームのヘッダー（Ethernet で 14 バイト、VLAN タグ付きで 18 バイト等）が加わります。UDP カプセル化を選ぶ場合は、これに UDP ヘッダー 8 バイトが上乗せされます。

参考: RFC 3931（Layer Two Tunneling Protocol – Version 3 (L2TPv3)）
“The optional Cookie field contains a variable-length value (maximum 64 bits)”
（オプションの Cookie フィールドは可変長の値（最大 64 ビット）を持つ）
https://datatracker.ietf.org/doc/html/rfc3931

GRE・L2TPv3 とも、PPPoE 上で用いる場合は PPPoE の 8 バイトも重なるため、実効 MTU はさらに小さくなります。トンネルを二重に重ねる構成（GRE over IPsec など）では、各層のオーバーヘッドが積み上がる点に注意が必要です。

オーバーヘッド早見（目安）

標準 MTU 1500 バイトを起点とした、各方式のオーバーヘッドと実効 MTU・MSS（IPv4）の目安を整理します。IPsec と L2TPv3 は構成で変動するため、代表的なケースの値です。

上記はあくまで標準構成に基づく目安です。回線事業者・機器・オプションによって推奨値が変わるため、実際の設定値は対象製品と回線の公式情報で確認することをおすすめします。

特に PPPoE に IPsec を重ねるような構成では、各層のオーバーヘッドが積み上がり、実効 MTU と MSS を手計算するのは煩雑になりがちです。ベース回線とトンネルを選ぶだけで実効 MTU の上限と推奨 MSS を内訳つきで算出できる『MTU/MSS 計算ツール』を作成しましたので、自分の構成での目安を確認する際に活用いただけます。

次のセクションでは、これらのオーバーヘッドを踏まえた具体的な調整方法（MTU の設定、MSS クランプ、UDP への対処）を整理します。

MTU/MSS の対策と調整方法

ここまで整理した仕組みとオーバーヘッドを踏まえ、MTU/MSS 起因の障害を防ぐための調整方法をまとめます。結論を先に述べると、対処は大きく 送信サイズを経路に合わせて下げる（MTU 調整・MSS クランプ） ことと、PMTUD が機能する環境を保つ（必要な ICMP を通す） ことの 2 方向です。TCP と UDP で有効な手段が異なる点にも注意が必要です。

MTU の調整

最も基本的な対処は、トンネルやカプセル化の区間で、インターフェースの MTU を実効値に合わせて下げることです。たとえば PPPoE 区間では 1492（フレッツ網では 1454 が広く使われます）、IPsec トンネルでは 1400 前後といった値を設定します。MTU を正しく設定すると、その機器が生成・転送するパケットのサイズが抑えられ、経路上での破棄やフラグメントを減らせます。

MTU 調整は TCP・UDP の両方に効く点がメリットです。一方で、通信するエンドホスト自身の MTU までは制御できないため、ホストが大きいパケットを送ってくるケースには、次の MSS クランプや PMTUD と組み合わせて対処します。

MSS クランプ（TCP のみ有効）

MSS クランプ（MSS 書き換え、adjust-mss）は、通過する TCP の SYN / SYN-ACK パケットの MSS オプションを、経路に収まる値へ書き換える手法です。エンドホストが大きい MSS を通知してきても、途中の機器が値を下げることで、実データのパケットが経路に収まるようになります。PMTUD が ICMP 遮断で機能しない環境でも有効なため、実務で広く使われる対処です。

ただし前述のとおり、MSS クランプは TCP にしか効きません。UDP には MSS がないため、この手法では救済できない点を理解しておく必要があります。代表的な機器での設定例を示します（各コマンドは公式リファレンスで確認した表記です）。

Cisco IOS では、インターフェースに対して adjust-mss を設定します。

interface Tunnel0
 ip tcp adjust-mss 1360

参照: https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html

FortiGate では、ファイアウォールポリシー単位（tcp-mss-sender / tcp-mss-receiver）またはインターフェース単位（tcp-mss）で設定できます。

config firewall policy
    edit <ポリシーID>
        set tcp-mss-sender 1360
        set tcp-mss-receiver 1360
    next
end

参照: https://community.fortinet.com/fortigate-3/technical-tip-setting-tcp-mss-value-96548

なお FortiOS の一部バージョンでは、IPsec トンネルを通過する TCP の MSS 自動調整の挙動が変更されています。適用中の FortiOS バージョンでの挙動は、公式ドキュメントで確認することをおすすめします。

YAMAHA RTX では、pp インターフェースやインターフェース共通の設定で MSS 制限を行います。auto を指定すると、MTU または相手の MRU から計算した値へ自動的に書き換わります。

参考: YAMAHA RTpro（TCP セッションの MSS 制限の設定）
「キーワード auto を指定した場合には、インタフェースの MTU、もしくは PP インタフェースの場合で相手の MRU 値が分かる場合にはその MRU 値から計算した値に書き換える」
https://www.rtpro.yamaha.co.jp/RT/manual/rt-common/ip/ip_interface_tcp_mss_limit.html

ip pp tcp mss limit auto

Linux（iptables）では、mangle テーブルで SYN パケットの MSS を Path MTU に合わせて書き換えます。

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

各機器の詳しい設定手順は、関連記事『YAMAHA RTX の PPPoE 設定手順』などのスポーク記事もあわせて参照してください。

UDP に対する対処

UDP は MSS クランプで救済できないため、別の方向からの対処が必要です。主な選択肢は次のとおりです。

 MTU の調整: 前述の MTU 調整は UDP にも効くため、トンネル区間の MTU を実効値へ下げることが基本の対処になる。

 PMTUD を機能させる: DF ビットを立てて PMTUD を利用する UDP アプリケーションでは、ICMP が通る環境であれば経路に応じたサイズ調整が働く。

 アプリケーション側の対応: DNS では EDNS のペイロードサイズ調整や、応答が大きい場合の TCP フォールバックが用いられる。QUIC は初期パケットサイズを一定以下に抑える設計になっている。

UDP の不具合は「TCP は直ったのに一部だけ不安定」という形で切り分けが難しくなりやすいため、対象アプリケーションが UDP を使っているかどうかを早い段階で確認することが、切り分けの近道になります。

PMTUD を機能させる（ICMP を通す）

MSS クランプや MTU 調整と並んで重要なのが、PMTUD を機能させることです。PMTUD は ICMP のエラー通知に依存するため、IPv4 では ICMP Type 3 Code 4、IPv6 では ICMPv6 Packet Too Big を遮断しないことが前提になります。

セキュリティ強化で ICMP を広く遮断すると、前述の PMTUD ブラックホールを招き、大きい通信だけが失敗する事象につながります。ICMP をすべて遮断するのではなく、Path MTU の通知に必要な種別は通す設計をおすすめします。ファイアウォールのルール設計にあたっては、必要な ICMP 種別を許可する方針を検討してください。

切り分けの手順（参考）

MTU/MSS を疑う場合の基本的な確認手順を整理します。DF ビットを立てた ping でサイズを変えながら、どのサイズから通らなくなるかを調べる方法が有効です。

• Windows: ping -f -l <サイズ> <宛先>（-f で DF ビットを設定）
• Linux: ping -M do -s <サイズ> <宛先>（-M do で DF ビットを設定）

通る最大サイズが判明したら、そのサイズに IP・ICMP ヘッダー分を加えた値が経路の MTU の目安になります。そこから MSS（IPv4 で MTU − 40）を算出し、MTU 調整や MSS クランプの設定値を決めます。

まとめ

MTU と MSS は、経路で一度に送れる IP パケットとその中の TCP データの上限を表し、両者はヘッダー分だけずれた関係にあります。トンネルやカプセル化で実効 MTU が縮むと、その縮小を送信側へ正しく伝えられないときに「大きい通信だけ止まる」障害が起きます。TCP は MSS クランプで調整できますが、UDP には効かないため、MTU 調整や PMTUD の確保とあわせた対処が必要です。

• MTU は経路で分割せず送れる IP パケットの最大サイズ、MSS はその中の TCP データの最大サイズ
• IPv4 では MSS = MTU − 40（IP 20 ＋ TCP 20）が基本値
• MSS は TCP 固有の仕組みで、UDP には存在しない
• カプセル化のオーバーヘッドは PPPoE で 8 バイト、IPoE で 40 バイト、GRE で 24 バイト
• IPsec と L2TPv3 のオーバーヘッドは暗号方式やモード、NAT-T の有無で変動
• MSS クランプは TCP のみ有効で、UDP は MTU 調整や PMTUD で対処
• PMTUD の維持には ICMP Type 3 Code 4 と ICMPv6 Packet Too Big の通過が前提

以上、最後までお読みいただきありがとうございました。