UTMってもう、ネットワーク機器の主流の一つになってますよね。最近は単純なFireWallを見つけるのが難しいくらい。UTMで以前に良く導入していた機器が Juniper NetworksのSSGシリーズ。既に販売終了しているこのSSGですが、以前にちょっと不可解な現象が発生しました。
結論としてはデフォルトの設定が、ネットワーク構成によって不具合を起こすことがわかりました。その不具合の内容と対応手順を経緯を残しておくことにします。本記事はSSG140で発生した内容を元にしていますが、SSG5などSSGシリーズ全般に該当する内容です。SSGを利用する環境は徐々に少なくなってきていると思いますが、未だに現役で利用している環境も多いはずです。もし以前から原因不明のネットワークに関する不具合がある場合は一度、確認して頂きたい点です。
1. 不可解な現象の内容
1-1. ネットワーク構成
SSGを導入した環境で、Gatewayが二つあったとします。
例えば、default Gatewayが192.168.1.254/24とします。
これがSSGのtrust側（LAN側）インターフェイスのIPアドレス。
不具合が発生するサーバが配置されているセグメントは、172.16.1.0/24だとします。
172.16.1.0/24セグメントへのルーティングは 192.168.1.253のIPを持つルーターが行っているとします。
[構成図]
1-2. 不具合の発生するタイミング
不具合は、上記ネットワーク環境で、Default Gatewayとは異なるゲートウェイの先にあるサーバへアクセスした場合、通信が時折停止してしまうというもの。
問題の現象は 192.168.1.0/24のN/Wから 172.16.1.10へパケットを送ると途中で、タイムアウトしてしまいます。
不可解なところは、最初はパケットのやり取りには問題ないところで、ある程度時間が経過すると、現象が発生するところです。
2. 原因の調査
早速、ネットワークの調査を行いました。
ネットワークのいくつかのゲートウェイや対象機器でパケットキャプチャを実施、その結果、N/W経路のどこかでパケットをDROPしてしまっているように見受けられます。
172.16.1.0/24セグメント経路にあるルーター(192.168.1.253)はパケットフィルタを全く行っていませんので、怪しいのは必然的にUTMに絞られます。
対象をSSGに絞って、このような現象が無いか、ウェブを調査をしてみると、同じような現象が発生したという報告が見つかりました。
SSGのデフォルト設定で、異なるGWへアクセスをした場合、SSGのセキュリティ機能であるtcp-syn-check が有効になっているとパケットをSSG側でDROPしてしまうことがあるとのこと。
(ackだけの非synパケットをDROPする）
早速、SSGのconfigを確認してみると、このチェックがしっかり有効になってます。
有効になっている場合、ssgのconfigに以下の記載があります。
> set flow tcp-syn-check
本設定が原因だと思われましたので、設定を変更することになりました。
3. tcp-syn-checkの無効化
3.項目で調査したtcp-syn-checkですが、SSGのWeb GUIからは変更ができないため、対象機器にsshでログインして、以下のように設定を変更します。
> unset flow tcp-syn-check
> save
設定後、パケットのdropが発生しないことを確認しました。
4. まとめ
このようなネットワーク構成は良くありますので、本不具合に合致する可能性も高いと思われます。もし、SSGを使用していて、同様の不具合が発生したら、本設定を確認してみて下さい。解決できるかもしれません。
