> FITELnetトップ > 製品ラインナップ > FITELnet-F120 > FITELnet-F120ファームウェア
> FITELnet-F120 firm V02.02(00) 05/12/22 release
> FITELnet-F120 firm V02.02(00) 05/12/22 release
下記の新規機能を追加いたしました |
(1) | IPsec通信において、受信したESPパケットのシーケンス番号をチェックする機能(Replay Attack防御機能)を無効にすることができるようになりました。 中継経路内において、ESPパケットの順序入れ替えが発生する可能性がある場合や、FITELnet装置においてESP送信側でポリシーベースIPsecとQoSを併用する場合、受信側においてESPパケットの順序が大幅に入れ替わって受信される可能性がありますが、この場合、Replay Attack と判定されてESPパケットが廃棄されます。Replay Attack 防御機能を無効とすることで、順序入れ替えによるパケット廃棄を行わない動作が可能となります。 ---設定例 Router(config)#crypto map Tokyo 1 Router(config-crypto-map)#anti-replay disable --- FITELnet製品において、IPsecとQoSを併用する場合、送信側におけるパケットの順序入れ替えの発生状況は以下のようになります。
|
下記の変更を実施いたしました |
(1) | IKE SAのlifetime満了30秒前から、該当するIKE SAを使用したパケット送信を停止する仕様になっていますが、他装置との接続性を考慮して、lifetime満了前の30秒間であっても、keepaliveの応答については送信できるようにしました。 |
(2) | IKEでのkeepalive(DPDおよびDPD-prop)がfail した場合に、vpnlogに記録するようにしました。 |
(3) | InformationalパケットでのInitial-contactを受信するケースにおいて、従来は旧IPsec SAのみを削除していましたが、旧IKE SAの削除も行うようにしました。 |
(4) | crypto isakmp policy設定モードのkeepaliveコマンドに、response-only パラメータを追加しました。これにより、対向装置からのkeepaliveには応答するが、自装置からのkeepalive監視は行わない運用が可能となります。 |
(5) | show report-all に show vrrp の内容を含めるようにしました。 |
下記の問題点を改修いたしました |
(1) | コンソール上にデバッグ文が誤って出力されていました。 出力条件および内容は以下の通りです。 発生条件 IPsec負荷分散設定においてEWAN2の回線を切断(リンクダウン) 出力内容 vi2: warning: unable to delete rtentry 発生条件 EWAN1とEWAN2に同じIPアドレスを設定しリンクアップ 出力内容 rtinit: wrong ifa (129f820) was (129fb40)" |
(2) | IPsec冗長機能を使用する構成において、センター側VPN装置のLAN側インターフェースがダウンしてバックアップ経路通信に切り替わった場合に、センター側VPN装置のLAN側インターフェースがアップしてもメイン経路通信に戻らないことがありました。 |
(3) | SA確立状態で keepalive-icmp source-interface 設定を削除しrefreshしても、keepalive-icmpパケットの送信元アドレスが設定削除前のsource-interfaceで指定されたものになっていました。 |
(4) | AggressiveモードのResponder側となった場合に、keepalive always-sendの設定をしても、keepaliveのパケットが送信されなくなってしまうことがありました。 |
(5) | AggressiveモードのResponder側でXAUTH(拡張認証)設定を併用した場合に、InitiatorからのIKE SA再確立が行われると、旧IKE SAを削除せずに、新旧2つのIKE SAが存在する状態となっていました。旧IKE SAはlifetime満了まで内部的に保持されていました。 |
(6) | DPD の keepalive が Fail して SA を消す場合に、deleteメッセージを送信していませんでした。 |
(7) | crypto isakmp policyモードの keepalive のヘルプ文字列を修正しました。 |
(8) | 予期せぬ事態において装置が自律リセットを行う場合に、次の問題がありました。
|
(9) | ip route A.B.C.D E.F.G.H I.J.K.L のようにnexthopがアドレスで設定されている状態で、ip route A.B.C.D E.F.G.H pppoe 1 のようにnexthopだけをインターフェース指定に変えたものを追加設定した場合に、!EXCEPTION! Data TLB Error の文字列がコンソール上に記録されて、装置の自律リセットが発生することがありました。 |
(10) | INBOUND SAが256個、OUTBOUND SAが0個となっている状態で IKE keepalive 動作を行うと、SAがないと誤判断して keepalive パケットを送信しない可能性がありました。 |
(11) | Quick Mode の Responderで QM-3rd パケット受信前に EWAN インターフェースがダウン(ケーブルを抜く等)した場合に、Quick Modeネゴシエーションのタイムアウトを迎えても、QM-1st受信時に作成したSAを削除することができませんでした。 |
(12) | keepalive(DPD)動作において、DPDリクエストパケットの送信が1回抜ける等の動作が発生することがあり、VPNピアのダウンを検出するタイミングが遅れる可能性がありました。 |
(13) | nullインターフェース宛の中継パケットを連続的に送信すると、slogに下記のログが記録されることがありました。 ”unable to enter address for IPアドレス (could not allocate llinfo) ” |
(14) | 同一ホスト間でたくさんの種類の通信を継続的に行った場合に、中継性能が劣化する場合がありました。 |
(15) | VRRPの仮想IPアドレスでSA確立を行う構成(crypto isakmp policy モードで source-interface 指定あり)において、暗号化対象パケットを連続送信すると、送信インタフェースの実IPアドレスをソースアドレスとしたESPパケットを送信してしまうことがありました。 |
(16) | VRRPの仮想IPアドレスでSA確立を行う構成(crypto isakmp policy モードで source-interface 指定あり)において、送信IFの実IPアドレスをソースアドレスとした notify メッセージを送信してしまうことがありました。 |
(17) | VRRPの仮想IPアドレスでSA確立を行う構成(crypto isakmp policy モードで source-interface 指定あり)において Nat-Traversal を併用した場合に、送信IFの実IPアドレスをソースアドレスとしたNAT Keepaliveパケットを送信していました。 |
(18) | Phase 2 SA において esp-null 暗号化設定を行った場合に、ESP パケットを受信すると、装置が再起動する現象が発生していました。 |
(19) | tasktrace 設定を複数種類登録してある状態で、任意の登録を削除する場合に、既に削除されているかのようなエラーメッセージ(xxx is already off)が表示されていました。削除指定した tasktrace の登録は正しく削除されていました。 |
(20) | IKE-SA は確立されるが IPsec-SA の確立に失敗(設定間違い等)する状態において、レスポンダ側では IKE-SA が show コマンドにて表示されるが、イニシエータ側では表示されない問題に対応しました。 |
(21) | reset default コマンド実行後は、現在の boot firmware、boot configuration 設定に依らず SIDE-A.frm、SIDE-A.cfg で起動する仕様ですが、boot firmware コマンドで SIDE-B.frm から起動される設定になっている状態で、reset default を実行すると、Next rebooting firmware SIDE-B.frm is fine. のように、SIDE-B.frm が起動されるメッセージがコンソールに表示されていました。 |