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