中古のFortigateについて その1(2023/05/23) [ネットワーク機器]
ファイアウォールアプライアンスとして、Juniper SSGにはお世話になったものですが、最近はすっかりFortigate一色ですね。他の選択肢をとるならPaloaltoなんてものもあるようですが。
個人的にFortigateは接点があまりなかったのですが、いざ実際に使ってみたところなかなか面白いですね。基本的に必要とされる機能が、一通り文句ないぐらいの作り込み度合いで実装されています。
Fortigateの便利さに慣れてしまうと、CISCOルータが随分とショボく見えてしまいます。
Fortigateの機能でよく分からなかったもの一つに、ライセンスの定期アクティベーションがあります。一般にUTM機能を利用する場合はシグネチャの「更新」は必要ですが、Fortigateは基本のファイアウォール機能の使用だけでも、定期的にアクティベーションを行うようです。
ファイアウォール機能は基本機能ですし、特別な追加ライセンスを必要とするものではありません。通信環境によっては、インターネットに接続できない完全オフラインで使う場合もありますので、オンラインの定期アクティベーション行為は必須なのか?と疑問に思ってしまいます。
裏を返せば、保守・ライセンス切れの中古Fortigateを買ってまともに使えるのか?ということですね。
私の個人的な調査の結果、結論から言えば
私の調べた限り、UTM系のシグネチャ更新を除けば、オンラインのアクティベーション通信で以下を更新しているようです。
①ISDB(Internet Service Data Base)
②Geo-IP
その2へ続く。
個人的にFortigateは接点があまりなかったのですが、いざ実際に使ってみたところなかなか面白いですね。基本的に必要とされる機能が、一通り文句ないぐらいの作り込み度合いで実装されています。
Fortigateの便利さに慣れてしまうと、CISCOルータが随分とショボく見えてしまいます。
Fortigateの機能でよく分からなかったもの一つに、ライセンスの定期アクティベーションがあります。一般にUTM機能を利用する場合はシグネチャの「更新」は必要ですが、Fortigateは基本のファイアウォール機能の使用だけでも、定期的にアクティベーションを行うようです。
ファイアウォール機能は基本機能ですし、特別な追加ライセンスを必要とするものではありません。通信環境によっては、インターネットに接続できない完全オフラインで使う場合もありますので、オンラインの定期アクティベーション行為は必須なのか?と疑問に思ってしまいます。
裏を返せば、保守・ライセンス切れの中古Fortigateを買ってまともに使えるのか?ということですね。
私の個人的な調査の結果、結論から言えば
問題なく使えるようです
私の調べた限り、UTM系のシグネチャ更新を除けば、オンラインのアクティベーション通信で以下を更新しているようです。
①ISDB(Internet Service Data Base)
②Geo-IP
その2へ続く。
タグ:fortigate
自宅無線APのリプレイス(2023/01/01) [ネットワーク機器]
うちの無線APは、Buffalo WSR-1166DHPを使ってます。
11ac対応だし、ちゃんと繋がるし何の不満もありません。ただ先日、駿河屋で中古のCDを買おうとしたら、「パソコン周辺機器」みたいなカテゴリーがあった訳です。興味本位で「ルーター」と検索してみたら、ブロードバンドルーターがいくつもヒットしました。
中古なのでちょっと怖い気持ちもありましたが、比較的新しいモデルがあるのと、さすがに駿河屋さんはちゃんとした会社なので、壊れていたり、そもそもパスワード紛失でログインできないようなガラクタはないだろうと思って、探してみました。
まあ、言ってWSR-1166DHPは2014年のモデルですからね。
壊れてはいませんが、さすがにレガシーに分類してもよい機器ですね。
調べてみると「WSR-2533DHP3-BK」が3500円ぐらいでありました。これは2020年の現行モデルで、新品の実売も8000円ぐらいです。もともとCDを買うのに一定金額以上買わないと送料を請求されますので、ちょうどいいやと思って買ってみました。
…と、届いたのが年末。
ちゃんと使えました。中古でもなんの問題もありません。
ただ、WSR-1166DHPもそうですが、CISCOルータでDHCPでIPアドレスを払い出そうとすると固定IPアドレスが払い出せない問題があります。これはWSR-2533DHP3-BKでも一緒でしたね。
PCなど一般端末はClient-IDの頭に「01」が付くのですが、Buffaloの無線APに関しては頭の「01」が付きません。これが原因で、一般端末と同じように固定IPアドレスを払い出そうとしてもうまくいきません。
答えを言ってしまうと、client-identifier指定ではなく、hardware-address指定でうまくいきます。
11ac対応だし、ちゃんと繋がるし何の不満もありません。ただ先日、駿河屋で中古のCDを買おうとしたら、「パソコン周辺機器」みたいなカテゴリーがあった訳です。興味本位で「ルーター」と検索してみたら、ブロードバンドルーターがいくつもヒットしました。
中古なのでちょっと怖い気持ちもありましたが、比較的新しいモデルがあるのと、さすがに駿河屋さんはちゃんとした会社なので、壊れていたり、そもそもパスワード紛失でログインできないようなガラクタはないだろうと思って、探してみました。
まあ、言ってWSR-1166DHPは2014年のモデルですからね。
壊れてはいませんが、さすがにレガシーに分類してもよい機器ですね。
調べてみると「WSR-2533DHP3-BK」が3500円ぐらいでありました。これは2020年の現行モデルで、新品の実売も8000円ぐらいです。もともとCDを買うのに一定金額以上買わないと送料を請求されますので、ちょうどいいやと思って買ってみました。
…と、届いたのが年末。
ちゃんと使えました。中古でもなんの問題もありません。
ただ、WSR-1166DHPもそうですが、CISCOルータでDHCPでIPアドレスを払い出そうとすると固定IPアドレスが払い出せない問題があります。これはWSR-2533DHP3-BKでも一緒でしたね。
PCなど一般端末はClient-IDの頭に「01」が付くのですが、Buffaloの無線APに関しては頭の「01」が付きません。これが原因で、一般端末と同じように固定IPアドレスを払い出そうとしてもうまくいきません。
Router#show ip dhcp binding Bindings from all pools not associated with VRF: IP address Client-ID/ Lease expiration Type Hardware address/ User name 192.168.1.209 01aa.aaaa.aaaa.aa Jan 01 2023 09:48 PM Automatic 192.168.1.210 01bb.bbbb.bbbb.bb Jan 01 2023 10:24 PM Automatic 192.168.1.221 cccc.cccc.cccc Jan 01 2023 09:39 PM Automatic // Buffalo APエントリ
答えを言ってしまうと、client-identifier指定ではなく、hardware-address指定でうまくいきます。
CISCO 既知バグ検索方法 [ネットワーク機器]
今回はこっちにまとめました。
https://www.eimelle.net/js-cms/html/NetworkEngineer/CISCO_bug.html
https://www.eimelle.net/js-cms/html/NetworkEngineer/CISCO_bug.html
実家の無線ルータをリプレイス(2020/2/10) [ネットワーク機器]
実家の無線ルータの調子が悪いらしいということで、リプレイスすることにしました。今使っているのは、BuffaloのWSR-1166DHPです。リプレイス機種は迷いましたが、Amazonやら価格.comのレビューを参考にしながら、WSR-1166DHP4にしました。結局、後継機に落ち着くのですね。
今のざっとしたネットワーク構成は以下のようになっています。ちなみにこの図は花子2020で作っています。なかなかの使い勝手ですよ。
実家をリモート操作する手段はフリーソフトのBrynhildrに依存しており、しかもその操作をできるのが無線LANで接続している母パソコンなんですよね。このまま何も考えずに古い無線ルータを交換・撤去してしまうと、母パソコンがLANから切り離されてしまい、リモート操作もできなくなってしまいます。
ここで目指したのは、
・何よりもまずきちんと移行できること
・リプレイス後のWSR-1166DHP4は最新ファームにすること
ですね。手順や順番を間違えてしまったり、完全通信断といった不測の事態に陥ってしまうと、私が新幹線で実家に行くことになる訳です。まあ、緊急時のリカバリ策は、電話で親本体をリモート操作することや、LANケーブルを買ってきてもらって有線LAN接続をすることなど、頭の片隅程度に考えてありましたが。
やはり気をつけるのは、Brynhildrへの動線を常に確保しておくことですね。あと、自分が今やろうとしている作業が、どういった影響をもたらすのかちゃんと頭でシミュレーションしておくことです。
■実践編
細かい説明は抜きにして、以下の順序で無事終えることができました。
1)購入したばかりのWSR-1166DHP4(以後、新ルータ)を起動させ、WANインタフェースを付属のLANケーブルでWSR-1166DHP(以後、旧ルータ)の空きポートに接続
2)Brynhildr経由で母パソコンからフレッツルータにログインし、新ルータ向けのDHCPの払い出しIPアドレスを確認
3)母パソコンから新ルータにログインし、新ルータのファームウェアアップデートを実施
4)新ルータの動作モード(ディップスイッチ)を、ルータ→無線APに切り替え再起動
5)新ルータに新しいSSIDの設定を行う
6)母パソコンに新しいSSIDを追加&切り替え。新SSID経由で母パソコンを操作する
7)実家の父&母に、LAN配線状態を引き継いで旧ルータを新ルータに交換するよう依頼(ドキドキの瞬間)
8)母パソコンの通信復旧
9)スマホなどその他の機器のSSIDを変更
今のざっとしたネットワーク構成は以下のようになっています。ちなみにこの図は花子2020で作っています。なかなかの使い勝手ですよ。
実家をリモート操作する手段はフリーソフトのBrynhildrに依存しており、しかもその操作をできるのが無線LANで接続している母パソコンなんですよね。このまま何も考えずに古い無線ルータを交換・撤去してしまうと、母パソコンがLANから切り離されてしまい、リモート操作もできなくなってしまいます。
ここで目指したのは、
・何よりもまずきちんと移行できること
・リプレイス後のWSR-1166DHP4は最新ファームにすること
ですね。手順や順番を間違えてしまったり、完全通信断といった不測の事態に陥ってしまうと、私が新幹線で実家に行くことになる訳です。まあ、緊急時のリカバリ策は、電話で親本体をリモート操作することや、LANケーブルを買ってきてもらって有線LAN接続をすることなど、頭の片隅程度に考えてありましたが。
やはり気をつけるのは、Brynhildrへの動線を常に確保しておくことですね。あと、自分が今やろうとしている作業が、どういった影響をもたらすのかちゃんと頭でシミュレーションしておくことです。
■実践編
細かい説明は抜きにして、以下の順序で無事終えることができました。
1)購入したばかりのWSR-1166DHP4(以後、新ルータ)を起動させ、WANインタフェースを付属のLANケーブルでWSR-1166DHP(以後、旧ルータ)の空きポートに接続
2)Brynhildr経由で母パソコンからフレッツルータにログインし、新ルータ向けのDHCPの払い出しIPアドレスを確認
3)母パソコンから新ルータにログインし、新ルータのファームウェアアップデートを実施
4)新ルータの動作モード(ディップスイッチ)を、ルータ→無線APに切り替え再起動
5)新ルータに新しいSSIDの設定を行う
6)母パソコンに新しいSSIDを追加&切り替え。新SSID経由で母パソコンを操作する
7)実家の父&母に、LAN配線状態を引き継いで旧ルータを新ルータに交換するよう依頼(ドキドキの瞬間)
8)母パソコンの通信復旧
9)スマホなどその他の機器のSSIDを変更
タグ:無線LAN
BUFFALO 無線ルータ WSR-1166DHPをバージョンアップする (2019/09/29) [ネットワーク機器]
実家の無線ルータはBUFFALOのWSR-1166DHPを使っているのですが、最近無線が途切れることがあるという話を親から聞くので、買い換えを検討しています。(製品としては2014年、2015年頃のモデルで、すでに販売終了)
とりあえず設定を事前チェックしていると、ファームウェアがVer.1.09[2016/01/07]であることが分かり、最新はVer.1.15[2019/04/24]が出ていることが分かりました。意外と最近までメンテナンスされているのですね。こういった手厚いサポートは好感触です。
バージョンアップはボタン一つで無事終了しました。大昔、ファームウェアのバージョンアップで失敗して壊れてしまったコレガとは大違いですね。
が、全体的に動きがおかしい。
APブリッジモードで動かしたいのですが、APブリッジモードで動かすとWeb管理画面に入れなくなり・・・というか、DHCP設定にもかかわらず管理インタフェースのIPアドレスが取得できていない。ディップスイッチでルータモードにすると管理インタフェースに入れるようになりますが、使いたいネットワークアドレス体系でない上、上位にいるフレッツのホームゲートウェイにアクセスできなくなる。
まあ、これでは駄目だなと思って新しい機種を買いに行こうとした訳ですが、設定の初期化(設定クリア)を実施していないこと思いだし、管理画面に入れるルータモードで設定初期化を実施しました。
と、途端に素直になり、前述の不具合はすべて解消しました。分かってはいましたが、この手の製品は、バージョンアップと共に設定の初期化は行った方が良いですね。
とりあえず設定を事前チェックしていると、ファームウェアがVer.1.09[2016/01/07]であることが分かり、最新はVer.1.15[2019/04/24]が出ていることが分かりました。意外と最近までメンテナンスされているのですね。こういった手厚いサポートは好感触です。
バージョンアップはボタン一つで無事終了しました。大昔、ファームウェアのバージョンアップで失敗して壊れてしまったコレガとは大違いですね。
が、全体的に動きがおかしい。
APブリッジモードで動かしたいのですが、APブリッジモードで動かすとWeb管理画面に入れなくなり・・・というか、DHCP設定にもかかわらず管理インタフェースのIPアドレスが取得できていない。ディップスイッチでルータモードにすると管理インタフェースに入れるようになりますが、使いたいネットワークアドレス体系でない上、上位にいるフレッツのホームゲートウェイにアクセスできなくなる。
まあ、これでは駄目だなと思って新しい機種を買いに行こうとした訳ですが、設定の初期化(設定クリア)を実施していないこと思いだし、管理画面に入れるルータモードで設定初期化を実施しました。
と、途端に素直になり、前述の不具合はすべて解消しました。分かってはいましたが、この手の製品は、バージョンアップと共に設定の初期化は行った方が良いですね。
タグ:無線LAN
CISCO841MJのCPU負荷が高い (2019/01/27) [ネットワーク機器]
CISCO841MJのCPU負荷を見たらこんなことになってました。DNS関係のプロセスが怪しそうですが、やっぱり負荷が高いものなんですかねぇ。
再起動しても変わらなかったので、コンフィグに問題があるのでしょうね。って、terminal monitorを有効にしたらDNS Viewに関する大量のログが表示され続けたので、たぶんこれが原因かと。ささっとnoで消しておきました。
Router-C841MJ#show processes cpu history Router-C841MJ 12:27:48 AM Sunday Jan 27 2019 JST 666666666666666666666666666666666666666666666666666666666666 888888888888888888888888888999998888888888888888888899999888 100 90 80 70 ************************************************************ 60 ************************************************************ 50 ************************************************************ 40 ************************************************************ 30 ************************************************************ 20 ************************************************************ 10 ************************************************************ 0....5....1....1....2....2....3....3....4....4....5....5....6 0 5 0 5 0 5 0 5 0 5 0 CPU% per second (last 60 seconds) .... Router-C841MJ#show processes cpu sorted CPU utilization for five seconds: 75%/17%; one minute: 75%; five minutes: 74% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 395 756114068 1517751050 498 40.31% 39.44% 39.83% 0 DNS Server Input 108 663439424 68437407 9694 6.31% 6.27% 6.29% 0 COLLECT STAT COU 384 787227732 1618078382 486 6.31% 6.22% 6.24% 0 DNS Server 147 343162308 1528572073 224 2.79% 2.68% 2.68% 0 IP Input 359 136968964 199177295 687 1.03% 1.04% 1.04% 0 Syslog 371 5205516 11360767 458 0.31% 0.31% 0.31% 0 FNF Cache Ager P 316 26815116 758993866 35 0.15% 0.19% 0.21% 0 EEM ED Syslog
再起動しても変わらなかったので、コンフィグに問題があるのでしょうね。って、terminal monitorを有効にしたらDNS Viewに関する大量のログが表示され続けたので、たぶんこれが原因かと。ささっとnoで消しておきました。
ip dns view default logging
タグ:cisco
CISCOルータをDNSフォワーダーとして機能させる (2018/09/17) [ネットワーク機器]
CISCOルータをDNSフォワーダーとして使用する方法です。CISCOルータを小規模オフィス向けブランチルータとしてばらまくような場合に有効な機能です。内部キャッシュも持つようですが、同様の大量のDNSクエリを削減するような性質のキャッシュ(いわゆるDNSキャッシュサーバ)なのかは分かりませんでした。
ちなみに従来のip name-server x.x.x.xの形式でも同様のことができますが、Firewall機能等を有効にしない限り、WANからもLANからもDNSクエリを受け付けてしまうため、クローズドな環境でない場合は非常に危険です。
マニュアルは下記にありますが、若干分かりにくいかと。
https://www.cisco.com/c/dam/global/ja_jp/td/docs/ios-xml/ios/ipaddr_dns/configuration/xe-16/dns-xe-16-book.pdf
ざっとこんな感じです。loggingは好みに応じて。
ちなみに従来のip name-server x.x.x.xの形式でも同様のことができますが、Firewall機能等を有効にしない限り、WANからもLANからもDNSクエリを受け付けてしまうため、クローズドな環境でない場合は非常に危険です。
マニュアルは下記にありますが、若干分かりにくいかと。
https://www.cisco.com/c/dam/global/ja_jp/td/docs/ios-xml/ios/ipaddr_dns/configuration/xe-16/dns-xe-16-book.pdf
ざっとこんな感じです。loggingは好みに応じて。
ip dns view default logging dns forwarder a.b.c.d dns forwarder e.f.g.h ip dns view-list dns-view view default 10 restrict source access-group 99 ip dns server view-group dns-view ip dns server access-list 99 permit 192.168.0.0 0.0.0.255
タグ:cisco
AndroidでCISCO 841MJにIPSec接続してみる その6 (2017/11/26) [ネットワーク機器]
機器のコンフィグ構造はざっとこんな感じです。同じようなことをやってみたい人がいれば、参考にしてください。こうやってみるとなかなかの壮大なコンフィグ構造ですね。C-MAPとD-MAP、I-PROFILEなどのネーミングは私が適当に付けているので、好みの文字列に変えてもらって大丈夫です。
また、細部のコンフィグは煮詰めていませんので、特にclient configuration groupあたりの中身はちゃんと考えた方が良いです。ACLやDNSなどいろいろと指定できるようです。
また、細部のコンフィグは煮詰めていませんので、特にclient configuration groupあたりの中身はちゃんと考えた方が良いです。ACLやDNSなどいろいろと指定できるようです。
AndroidでCISCO 841MJにIPSec接続してみる その5 (2017/11/05) [ネットワーク機器]
というわけで、MODE_CFGセクションまで無事にクリアした訳ですが、ここまでの設定がちゃんとできていると、AndroidからのIPSec接続が確立成功&安定化するようになります。が、まだ終わりではありません。IPSec接続は安定するのですが、クライアントから一切の通信ができないのです。Androidにping・tracerouteのツールを導入して接続確認をしてみても、応答が全くありません。
その答えはshow ip routeの結果を見れば分かるのですが、ルータにクライアント(poolアドレス)へのルーティング情報がないためです。これに関しては、答えから言ってしまうとReverse Route Injection(RRI)機能を使って、ルーティング情報を追加する必要があります。
ただ、ルータのコンフィグとしては単純で、下記の通りにreverse-routeコンフィグを追加するだけです。
そうすると、クライアントからのIPSec接続時、ルーティングテーブルに下記エントリが追加され、Android上でIPSec経由の通信が通るようになります。
いかがでしたでしょうか。無事、Androidから通信が通るようになり、基本的に当初やろうとしていたことは実現できました。小規模なオフィス環境であれば、下手にVPN装置などを買わずともCISCO841MJにこれらのコンフィグを投入すれば、外部からリモートアクセスできるようになります。
接続を試してはいませんが、WindowsやMacからも同じように外部からリモートアクセスできるのではないかと思っています。
なお、一連の機器コンフィグについては、非常に複雑なため、別途整理して記事にしたいと思います。
その6へ続く。
その答えはshow ip routeの結果を見れば分かるのですが、ルータにクライアント(poolアドレス)へのルーティング情報がないためです。これに関しては、答えから言ってしまうとReverse Route Injection(RRI)機能を使って、ルーティング情報を追加する必要があります。
ただ、ルータのコンフィグとしては単純で、下記の通りにreverse-routeコンフィグを追加するだけです。
Router#show running-config crypto dynamic-map D-MAP 1 set transform-set T-SET set isakmp-profile I-PROFILE reverse-route
そうすると、クライアントからのIPSec接続時、ルーティングテーブルに下記エントリが追加され、Android上でIPSec経由の通信が通るようになります。
Router#show ip route Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP a - application route + - replicated route, % - next hop override, p - overrides from PfR Gateway of last resort is 192.168.1.1 to network 0.0.0.0 S* 0.0.0.0/0 [1/0] via 192.168.1.1, GigabitEthernet0/4 ... 192.168.2.0/24 is variably subnetted, 5 subnets, 2 masks C 192.168.2.0/24 is directly connected, Vlan10 S 192.168.2.241/32 [1/0] via A.B.C.D(=Android Client IP Address)
いかがでしたでしょうか。無事、Androidから通信が通るようになり、基本的に当初やろうとしていたことは実現できました。小規模なオフィス環境であれば、下手にVPN装置などを買わずともCISCO841MJにこれらのコンフィグを投入すれば、外部からリモートアクセスできるようになります。
接続を試してはいませんが、WindowsやMacからも同じように外部からリモートアクセスできるのではないかと思っています。
なお、一連の機器コンフィグについては、非常に複雑なため、別途整理して記事にしたいと思います。
その6へ続く。
AndroidでCISCO 841MJにIPSec接続してみる その4 (2017/11/04) [ネットワーク機器]
MODE_CFGセクションに到達していることは分かったので、コンフィグを煮詰め直します。このあたりのコンフィグについては、「正」となる情報がないため、本当に手探り状態です。ネット上に、細切れ情報が散らばっていますが、
・AnyConnect接続用のコンフィグ
・CISCO ASA向けコンフィグ
・古いIOS向けのコンフィグ
・その他、ちょっと何か違うコンフィグ
だったりして、私の手元でそれっぽいコンフィグを作ることはできるのですが、正にカットアンドトライ状態です。私が大いに悩んだように、ここからの記述はすごく分かりにくくなっているので、ご注意ください。
現状のisakmpプロファイルはざっと下記の通りなのですが、
じゃあどこにあるかと言うと、
ここで私を大いに悩ませました。Webにあるの参考コンフィグ(http://www.infraexpert.com/study/ipsec18.html)には、下記のように
いろいろ試していると、isakmpプロファイル内のclient configuration group~コンフィグによって、グループプロファイルを紐けることができました。ざっとまとめると、
・グループ認証使用有無にかかわらず、クライアントに払い出すIPアドレスはグループプロファイルで設定する
・isakmpプロファイルに、グループプロファイルを紐付ける方法は下記2つのうちのいずれか
(1)match identity group~コンフィグによって、グループ認証を有効にする
(2)グループ認証を行いたくない場合は、client configuration group~コンフィグによって、グループプロファイルを紐付ける
ということでした。
ちなみに最初に取得したデバッグログと睨めっこすると、ISAKMP-AAA-ERROR: (0):group does not existというメッセージが表示されており、グループプロファイルが正常に読み出せてないことが暗に示されていましたね。
その5へ続く。
・AnyConnect接続用のコンフィグ
・CISCO ASA向けコンフィグ
・古いIOS向けのコンフィグ
・その他、ちょっと何か違うコンフィグ
だったりして、私の手元でそれっぽいコンフィグを作ることはできるのですが、正にカットアンドトライ状態です。私が大いに悩んだように、ここからの記述はすごく分かりにくくなっているので、ご注意ください。
現状のisakmpプロファイルはざっと下記の通りなのですが、
Router#show running-config crypto isakmp profile I-PROFILE keyring K-RING match identity address 0.0.0.0 client authentication list AAA-AUTHE isakmp authorization list AAA-AUTHO client configuration address respond Router#configure terminal Router(config)#crypto isakmp profile I-PROFILE Router(conf-isa-prof)#? Crypto ISAKMP Profile Commands are: accounting Enable AAA Accounting for IPSec Sessions ca Specify certificate authorities to trust client Specify client configuration settings default Set a command to its defaults description Specify a description of this profile exit Exit from crypto isakmp profile sub mode initiate Initiator property isakmp ISAKMP Authorization command keepalive Set a keepalive interval for use with IOS peers keyring Specify keyring to use local-address Interface to use for local address for this isakmp profile match Match values of peer no Negate a command or set its defaults qos-group Apply a Qos policy class map for this profile self-identity Specify Identity to use virtual-template Specify the virtual-template for dynamic interface creation. vrf Specify the VRF it is related toこのコンフィグ階層の中には、クライアントに払い出すIPアドレスを設定する場所(pool)がないのです。
じゃあどこにあるかと言うと、
Router#configure terminal Router(config)#crypto isakmp client configuration group C-GROUP Router(config-isakmp-group)#? ISAKMP group policy config commands: access-restrict Restrict clients in this group to an interface acl Specify split tunneling inclusion access-list number auto-update Configure auto-upgrade backup-gateway Specify backup gateway banner Specify mode config banner browser-proxy Configure browser-proxy configuration Push configuration to the client crypto Client group crypto aaa attribute list dhcp Configure DHCP parameters dns Specify DNS Addresses domain Set default domain name to send to client exit Exit from ISAKMP client group policy configuration mode firewall Enforce group firewall feature group-lock Enforce group lock feature include-local-lan Enable Local LAN Access with no split tunnel key pre-shared key/IKE password max-logins Set maximum simultaneous logins for users in this group max-users Set maximum number of users for this group netmask netmask used by the client for local connectivity no Negate a command or set its defaults pfs The client should propose PFS pool Set name of address pool save-password Allows remote client to save XAUTH password smartcard-removal-disconnect Enables smartcard-removal-disconnect split-dns DNS name to append for resolution wins Specify WINS Addressesというグループプロファイルの中にあるpoolコンフィグがそれに該当します。つまりは独立した両者のコンフィグを結びつける必要があるのです。
ここで私を大いに悩ませました。Webにあるの参考コンフィグ(http://www.infraexpert.com/study/ipsec18.html)には、下記のように
Cisco(config)#show running-config crypto isakmp profile VPN-PROFILE match identity group VPNCLIENT client authentication list VPNAUTHE isakmp authorization list VPNAUTHO Cisco(config-isa-prof)# client configuration address respondmatch identity group~コンフィグによって、isakmpプロファイルとグループプロファイルをうまく結びつけているのですが、これを設定してしまうと、グループ認証が有効になってしまうため、汎用性が失われてしまいます。私はmatch identity group~コンフィグを設定したくないのです。(だからmatch identity address 0.0.0.0を設定している)
いろいろ試していると、isakmpプロファイル内のclient configuration group~コンフィグによって、グループプロファイルを紐けることができました。ざっとまとめると、
・グループ認証使用有無にかかわらず、クライアントに払い出すIPアドレスはグループプロファイルで設定する
・isakmpプロファイルに、グループプロファイルを紐付ける方法は下記2つのうちのいずれか
(1)match identity group~コンフィグによって、グループ認証を有効にする
(2)グループ認証を行いたくない場合は、client configuration group~コンフィグによって、グループプロファイルを紐付ける
ということでした。
ちなみに最初に取得したデバッグログと睨めっこすると、ISAKMP-AAA-ERROR: (0):group does not existというメッセージが表示されており、グループプロファイルが正常に読み出せてないことが暗に示されていましたね。
その5へ続く。