SSG5/140での不具合 tcp-syn-check

2015/06/23 2016/03/01 ネットワーク

UTMってもう、ネットワーク機器の主流の一つになってますよね。最近は単純なFireWallを見つけるのが難しいくらい。UTMで以前に良く導入していた機器が Juniper NetworksのSSGシリーズ。
既に販売終了しているこのSSGですが、以前にちょっと不可解な現象が発生しました。

結論としてはデフォルトの設定が、ネットワーク構成によって不具合を起こすことがわかりました。その不具合の内容と対応手順を経緯を残しておくことにします。
本記事はSSG140で発生した内容を元にしていますが、SSG5などSSGシリーズ全般に該当する内容です。

SSGを利用する環境は徐々に少なくなってきていると思いますが、未だに現役で利用している環境も多いはずです。もし、以前から原因不明のネットワークに関する不具合がある場合は、一度、確認して頂きたい点です。

１．不可解な現象の内容
- １－１．ネットワーク構成
- １－２．不具合の発生するタイミング
２．原因の調査
３．tcp-syn-checkの無効化
４．まとめ

１．不可解な現象の内容

１－１．ネットワーク構成

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を持つルーターが行っているとします。
[構成図]

１－２．不具合の発生するタイミング

不具合は、上記ネットワーク環境で、Default Gatewayとは異なるゲートウェイの先にあるサーバへアクセスした場合、通信が時折停止してしまうというもの。
問題の現象は 192.168.1.0/24のN/Wから 172.16.1.10へパケットを送ると途中で、タイムアウトしてしまいます。

不可解なところは、最初はパケットのやり取りには問題ないところで、ある程度時間が経過すると、現象が発生するところです。

２．原因の調査

早速、ネットワークの調査を行いました。
ネットワークのいくつかのゲートウェイや対象機器でパケットキャプチャを実施、その結果、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に以下の記載があります。