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

2016/03/01 ネットワーク

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

スポンサーリンク

1-2.不具合の発生するタイミング

不具合は、上記ネットワーク環境で、Default Gatewayとは異なるゲートウェイの先にあるサーバへアクセスした場合、通信が時折停止してしまうというもの。
問題の現象は 192.168.1.0/24のN/Wから 172.16.1.10へパケットを送ると途中で、タイムアウトしてしまいます。
ssg-packet-loss
不可解なところは、最初はパケットのやり取りには問題ないところで、ある程度時間が経過すると、現象が発生するところです。

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に以下の記載があります。

本設定が原因だと思われましたので、設定を変更することになりました。

3.tcp-syn-checkの無効化

3.項目で調査したtcp-syn-checkですが、SSGのWeb GUIからは変更ができないため、対象機器にsshでログインして、以下のように設定を変更します。

設定後、パケットのdropが発生しないことを確認しました。

4.まとめ

このようなネットワーク構成は良くありますので、本不具合に合致する可能性も高いと思われます。もし、SSGを使用していて、同様の不具合が発生したら、本設定を確認してみて下さい。解決できるかもしれません。

関連する記事


Facebookでのご購読が便利です。

Twitter・Feedlyでもご購読できます。

Twitterでフォローする Feedlyでフォローする

Message

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

  • スポンサーリンク