FortiGateとMTUでハマった話し
はじめに
結構古いFirewall(J社)からFortiGateに更新した際に、特定の機種から特定の通信ができなかったのでハマった。原因究明のためイロイロ調べたのでメモ。どこかの誰かの助けになれば嬉しいけど、自分自身の理解も浅いためボチボチ整理していく予定。なお、まだ情報をまとめきれていないので順次アップデートしていく予定。
環境イメージ
[プロバイダのメールサーバ]---(インターネット)---(フレッツ系サービス)---[FortiGate]---[複合機]
ハマった内容
[プロバイダのメールサーバ]---(インターネット)---(フレッツ系サービス)---[FortiGate]---[複合機]
あるメーカの複合機からメールを送る機能がある。トナー切れとか、故障とか、多分そんな用途に使うらしい機能だけと、FortiGateに更新した後からそのメールの送信ができない。切り分けしたところ、いくつかの事象が分かった。
- FortiGateのポリシーを複合機からはALL許可としたけどダメ。
- FortiGateのポリシーからUTMを全て外したけどダメ。
- 複合機からPingを打つ機能があるけど、メールサーバまでPingは飛ぶ。
- パソコンに複合機のIPアドレスを設定し、メールソフトで送信するとちゃんと送れる。
- 複合機の送信メールサーバ設定を、プロバイダのメールサーバから内部メールサーバに変更するとちゃんと送れる。
この事象から、メールサーバ側の問題では?と考えてメールサーバを運営しているプロバイダに問合せしたけど、何も設定変更していないとの回答で(当然だけど)した。このまま迷宮入りするところだったけど、環境を変えたのはFortiGateに更新しただけなので、FortiGateに原因があるのではと思い、ネットワークエンジニアに相談したところ「パケットキャプチャしたら?」とアドバイスをもらったので実施してみた。
FortiGateでパケットキャプチャする方法
GUIで取れるとのことなので、その方法で取得してみる。
https://kb.fortinet.com/kb/documentLink.do?externalID=FD45907
パケットキャプチャを解析してみた
FortiGateから複合機に対して、ICMPのタイプOx03(Destination Unreachable Message)のコードOx04(Fragmentation needed)が送られていた。その後、FortiGateからセッションを切っている様子。
さらに調べた
Path MTU Discovery と言う仕組みが関係していそうな気がしてきた。
Path MTU Discovery とは
ルータが持つ回線によっては、より小さいMTUを持つ回線を使ってパケットを転送しようとした時において、「着信パケットが大きい」かつ「DFビットが設定されている場合」、そのパケットを破棄してICMPのタイプ 0x03(Destination Unreachable Message)のコード0x04(Fragmentation needed)を送信元のホストに返すらしい。そのICMPには調整が必要となった回線のMTU値(Next-Hop MTU)が含まれていて、受け取ったホストはそのMTU値に変更して再度パケットを送るため正常に通信できる様になる。
つまり「あなたが送ったパケットサイズが大きすぎて転送出来ないよ、このMTU値(Next-Hop MTU)に変更して送ってもらえませんか?」とお願いするイメージだと思う。
ただし、Path MTU Discoveryを使わず、ルータがフラグメンテーションする場合もある。
フラグメンテーションとは
ルータがパケットを転送しようとした時に、パケットサイズが送信インタフェースのMTU値を超えた場合、そのルータがパケットを分割してMTU値以下にするという機能らしい。ただし、ルータ側でパケットを分割する処理、受け取る側でパケットを再構築する処理の負荷があるし、「フラグメント攻撃(Fragment Attack)」にも利用されるため、最近ではあまり主流では無いらしい。
MTUとMSSについて
仮説
以下いずれか、もしくは全てが成り立つと考えた。
- 更新前のFirewall(J社)はフラグメンテーションしていたが、FortiGateはその機能が無い、もしくはデフォルト無効。
- 複合機が送信するパケットがはDFビットが設定されている。
- 複合機が頑なにMTU値を変更しない、もしくはFortiGateからのICMPが届かない。パソコンには届いているので複合機側で破棄している。
- もしかしたらPath MTU Discovery のブラックホール問題?
【図解】Path MTU DiscoveryブラックホールとPLPMTUD(RFC4821)による自動調整
https://milestone-of-se.nesuke.com/nw-basic/grasp-nw/packetization-layer-path-mtu-discovery/
仮説から取った対策
今回問題が発生しているのは複合機からのメール送信だけなので、FortiGateの対象ポリシーだけMSS値を上書き設定することにした。具体的にはWAN側インタフェースがPPPoEなのでMSS値を1414とした。値の根拠については下記を参照した。
MTU/MSSの変更方法を教えてください
https://csps.hitachi-solutions.co.jp/fortinet/faq/FG-11-0018/index.html
MTU / MSSを最適化する
https://yabe.jp/gadgets/optimizing-mtu-mss/
結果
メールが送信出来る様になったのでとりあえずはOK。
仮説の真偽については時間を作り検証してみたいと思う。
Author And Source
この問題について(FortiGateとMTUでハマった話し), 我々は、より多くの情報をここで見つけました https://qiita.com/katuemon/items/73715073f1711a858969著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .