キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 
cancel
933
閲覧回数
4
いいね!
5
返信

CiscoASA5506にL2TPoverIPsecでリモートPC接続し、同一ASAのPATを利用した通信がしたい

sp2366518
Level 1
Level 1

はじめまして、keijiともうします。

文章ではなかなか説明が難しいですが、投稿させて頂きます。

わからない説明部分があれば、ご指摘ください。

以下の接続が出来ないため、回避策等が無いかご教授頂きたく投稿いたします。

1.接続したいサーバ--------2.Ciscoルータ----------IPsecVPN-----------3.CiscoASA5506-------社内LAN--------4.社内サーバ等

                    インターネット

                         |

                         |

                    5.リモートPC(Windows)

【前提】

・2.ルータと3.ASAはL2LのIPsecでInternetVPN接続しています。

・4.の社内サーバ等から1.へは、3.ASAのPATを利用して接続ができます。

・5.のリモートPCから3.ASAへはL2TPoverIPsecでリモートPCの接続をし、4.の社内サーバ等への接続ができます。

【要望】

・5.のリモートPCが3.ASAにリモートPC接続している状態(社内PC端末イメージ)で、1.のサーバへの接続が出来るようにしたいです。

【エラー状況】

5.のリモートPCが、1.のサーバに接続できません。

・1.に到達した時のソース側アドレスは3.ASAのPATがかかったアドレスで、返答もそのIPアドレスに返信しています。

 (1.のLAN側にてパケットキャプチャで確認済)

・その1.からの返答パケットを受信した3.のASAが、5.に対してicmpのまま転送するため、破棄されていると考えられます。

 ※3.と5.間はL2TPoverIPsecのため、ESPパケット(IPsec)で転送されると考えますが、icmpのまま転送されています。

 (3.の出口にて、パケットキャプチャで確認済)

・ASAのPacketTracerで内部の試験確認を試みましたが、うまく確認できませんでした。

【想定】

・5のリモートPCは社内サーバなどにはESPパケット(IPsec)接続は出来ていますが、3.ASAがPATの処理で戻ってきた通信を5.へ転送するようにならないか、ご教授いただけたら幸いです。

・また、なにか別の方法がないか、ご教授いただけると幸いです。

【情報】

<ASA5506>

 Hardware: ASA5506, 4096 MB RAM, CPU Atom C2000 series 1250 MHz, 1 CPU (4 cores)

 ASA Version 9.6(1)

<リモートPC>

 Windows 7 Professional ServicePack1 32ビット

 ネットワーク接続のVPN種類は、"IPsecを利用したレイヤー2トンネリングプロトコル(L2TP/IPSec)"を利用しています。

その他、不足な情報があればご指摘ください。

よろしくお願いします。

5件の返信5

サポートコミュニティのご利用ありがとうございます。

 

ご投稿いただきました質問は、「エキスパートに質問」 ではなく、

該当するコミュニティ ファイアウォール へ移動させていただきました。どうぞよろしくお願いいたします。

 

サポートコミュニティ事務局

Akira Muranaka
Level 8
Level 8

keijiさん、こんにちわ。 返信が遅れてすみません。。

恐らく ご利用の構成で想定の通信ができないのは、ASAのセキュリティ上の理由で内部折り返し処理が制限されているせいかと思います。ルーターだと折り返し通信が可能なケースが多いですが、Firewallだと 他社さんFirewallも含め 駄目なケースが多い気がします。

この制限の解除の対応は難しかった気がするので (あとセキュリティやパフォーマンス上も 折り返しはあまり良くないかもです・・)、シンプルに対応する、という意味では、社内LAN側で折り返す何らからの中継機器を用意されるのが良いかと思います。

例えば、「1. 接続したいサーバ」が WEbサーバーなら 社内LANにプロキシサーバーの設置を、それ以外のサーバなら NATルータやNAT用Firewallを設置し、リモートクライアントの送信元IPアドレスを一旦 それら中継装置で別のIPアドレスに変換すれば、ASAはそのL2Lの通信と、中継サーバーからの通信を別々に処理できるため、今回の通信構成の実現が可能かと思います。また、各々を別の通信として扱えるので、ACLでのセキュリティ制御もしやすくなります。

私の知ってる範囲ですが、実際に上記構成例で、今回のような構成の通信を実現されている例を複数見たことがあり、また安定します。

akiraさん

ご回答ありがとうございました。

シンプルな構成にするという点は、まさしくそのとおりだと思います。

しかし、構築経験のあるエンジニアに比べ、一般的なIT知識を持った方が大半であることが現実です。

『FireWallやルータであれば制御出来るはずだ』ということで、いろいろと要件を詰め込んだ結果接続ができないケースが出て、『何故出来ない?という問いにうまく答えられず』難しい制限解除方法の対応へ陥っています。

コミュニティの方々からの、『このような制限の解除の対応は難しく(中継器の設置等を取り入れ)シンプルな通信形態をとる』という意見も非常に重要でして、そういった背景を反映させていただき、ひとまずはお客様に対してシンプルな構成の提案へと進めようと考えます。

対処方法が分かればスッキリしますが、難しいですね。

ありがとうございました。

こんにちわ。

そうですね。 少ないリソースで、全ての機器の動作を把握しようとするのは現実的ではないと思います。

なお、私個人の経験上ですが、機器により得意な処理は違うので、その得意な処理に注目し、各機器に実装する機能・設定を絞ると、トラブルも少なくなると思います。 また実際トラブル発生時に利用できるネット上のトラブルシューティング情報も多くなり、トラブル解決の速度アップや、運用が楽になる効果もあります。

例えば、今回の件にあてはめると、ASAは サイト間VPNやルーティング(折り返し通信含む)は得意ではないですが、アクセス制御やリモートアクセスVPNは得意です。 ルータは アクセス制御やリモートアクセスVPNは得意ではないですが、ルーティングやサイト間VPNは得意です。 ので、できれば、ASAには両方の処理はさせないほうが綺麗に動作します。 そのため、最初から、サイト間VPNはルータで行い、ASAは リモートVPN終端用にする、と分けてたら、今回の件は発生しなかった問題かな、と思います。 

どの機器がどの機能が得意か、などは、公開されているドキュメント量や掲示板の書き込み状況からある程度判断できます。

意外と「その機能が得意な機器に 得意なことのみさせる」は、運用複雑性の回避や、トラブル削減、運用コスト(トラブル時の人件費含む)の削減にもつながるので、長期運用を考えると大事な観点かなぁと思います。 私が担当お客さんに提案時は、このような点も トータルコストを下げるという点で重要なファクターとして説明するようにしてます。(情シスの方が忙しい方が多いので。)

上記は既に実施頂いてるかもですが、1つの参考になれば。

返信ありがとうございました。

本件については、お客様にたいしてシンプル構成での運用で進めます。

自身として今後の事を考え、別途、対処方法を探ってみます。

ありがとうございました。