2016-03-15 11:07 AM
こんにちは
Cisco ASA 5540 でSSL-VPN機器を構築して、エンドユーザーにサービスを提供しています。
OS: 9.1(6.4) 、ASDM:7.4(2)を使用しています。
クライアントPCのWindows10対応のため、AnyConnectを3.1.08009→3.1.13015にVer.Upして検証をしています。
■クライアント/サーバーの組み合わせ
クライアント側は新しいバージョン、サーバー側(ASA側)は新バージョンと現状バージョンの2パターンで試しています。
クライアントPC: Windows10 (64bit版)+ AnyConnect 3.1.13015
ASA5540(テスト機1):OSとASDMは上記の通り、AnyConnect 3.1.08009
ASA5505(テスト機2):OSとASDMは上記の通り、AnyConnect 3.1.13015
■ネットワークへの接続手段
有線LAN、PC(ノートPC)内蔵の無線LAN、USB接続のLTEデバイスを使っています。
有線LAN、無線LANは問題ないのですが、LTEデバイスでAnyConnectに接続したときのWebアクセスにかなり問題があります。
どなたか、原因と対処の方法についてご教示しただけますでしょうか。
■Webアクセスの環境
AnyConnect接続時に、ASA55xxからプロキシの自動構成スクリプトが配置されているサーバーの情報をクライアントPCに配信します。
(添付の画面キャプチャ参照)
プロキシの自動構成スクリプトが配置されているサーバーは、SSL-VPN接続先の社内NWのセグメントに配置されています。
スプリットトンネルの設定により、一般のWebサーバーへのアクセス(例:http://www.yahoo.co.jp)も全て社内NWを通るという仕様です。
■問題点
LTEデバイスでのインターネット接続+AnyConnectでVPN接続後のWebアクセスにかなり問題があります。
ブラウザ(IE11)では、「このページは表示できません」と表示されることが多いです。
パケットキャプチャをすると、プロキシの自動構成スクリプトが配置されているサーバーの情報(http://proxy/)を使っていないことが多いようです。
パターン1:ASAからPCに配信された情報を無視して、グローバルIP宛てに直接通信を試行して失敗している
パターン2:http://proxy/へのアクセス開始時に、ホスト名proxyの名前解決の際にudp:53ではなく、Link-Local Multicast Name Resolution (LLMNR) を使用して失敗している。
パターン3:LTEデバイスにアサインされているDNSサーバー、または、LTEデバイス接続により有効化された6to4デバイスにアサインされているDNSサーバー(グローバルIP)で名前解決しようとしている。
本来の動作はAnyConnect接続時にPCに配信された接続先社内DNSサーバー(プライベートIP)で名前解決すべきものです。
■テスト的な変更と結果
パターン1への対応
ブラウザ(IE11)のプロキシ設定の画面を開きOKボタンを押す(上書き設定する)
または、
プロキシの自動構成スクリプトが配置されているサーバーをIPアドレス指定する。
これでWebアクセスができるようになることもあるが、できない場合も多い
パターン2への対応
ローカルグループポリシーエディター(gpedit.msc)→管理用テンプレート→ネットワーク→DNSクライアント→マルチキャスト名前解決をオフにする で無効化する
→目立った効果はない気がします。
パターン3への対応
AnyConnect用の仮想NICデバイス(Cisco AnyConnect Secure Mobility Virtual Miniport Adapter for Windows x64)でIPv6を無効化する
→目立った効果はない気がします。
netsh interface 6to4 set state state=disabledコマンドで 6to4を無効化する
→比較的安定してWebアクセスできるようになった気がするが、まだ怪しい気がします。
■使用デバイス
LTEデバイスは、NTT Docomo L-03D, L-03F
・USB接続タイプです。
・ドライバー、接続アプリは、DocomoのサポートサイトからWindows10対応版をダウンロードして使用
・どちらのデバイスも、同じ動作です。
(最初はWebアクセスができない、上記の対応で多少改善がみられるといった振る舞いが同じです)
よろしくお願いします。
解決済! 解決策の投稿を見る。
2016-03-16 01:00 AM
athirano1さん、こんばんわ。
まず プロキシ(特に動的な処理)と リモートVPNですが、相性がかなり悪かったと記憶してます。 過去、何度かプロキシとVPNの相性問題のトラブル遭遇経験があります。 例えば、 VPNアプリケーション側が プロキシの動的な情報を正しく認識できないケース、プロキシの特殊通信(※プロキシは細工された通信を利用する)を上手く処理できないケース、そもそも 良くリリースノートを見るとその構成がサポートされてなかったケース、など様々です。
本件の調査に戻りますが、LTEの問題か、プロキシの問題か、ブラウザの問題か、以下切り分けをされてみると如何でしょうか。
1. iPhoneなどのテザリング機能を利用して公衆網から接続してみる (LTE問題かの切り分け)
2. 自動構成スクリプトを利用せず、手動でプロキシサーバを指定する (自動構成スクリプトの問題かの切り分け)
3. Firefoxなど別ブラウザを利用する (ブラウザ問題かの切り分け)
個人的には 2. の問題の可能性が高いのかなと考えてます。
2016-03-16 01:00 AM
athirano1さん、こんばんわ。
まず プロキシ(特に動的な処理)と リモートVPNですが、相性がかなり悪かったと記憶してます。 過去、何度かプロキシとVPNの相性問題のトラブル遭遇経験があります。 例えば、 VPNアプリケーション側が プロキシの動的な情報を正しく認識できないケース、プロキシの特殊通信(※プロキシは細工された通信を利用する)を上手く処理できないケース、そもそも 良くリリースノートを見るとその構成がサポートされてなかったケース、など様々です。
本件の調査に戻りますが、LTEの問題か、プロキシの問題か、ブラウザの問題か、以下切り分けをされてみると如何でしょうか。
1. iPhoneなどのテザリング機能を利用して公衆網から接続してみる (LTE問題かの切り分け)
2. 自動構成スクリプトを利用せず、手動でプロキシサーバを指定する (自動構成スクリプトの問題かの切り分け)
3. Firefoxなど別ブラウザを利用する (ブラウザ問題かの切り分け)
個人的には 2. の問題の可能性が高いのかなと考えてます。
2016-03-28 10:51 AM
Akira Muranakaさん
athirano1です。いつもお世話になっております。
その後、テストした結果、
2. の「自動構成スクリプトを利用せず、手動でプロキシサーバを指定する 」で対応すると、状況が改善しました。
また、1.の「iPhoneなどのテザリング機能を利用して公衆網から接続してみる」でも、結果良好でした。
サービスを提供するエンドユーザーとも相談して、上記の1か2で対応したいと思います。
ありがとうございました。
2016-03-28 01:55 PM
athirano1さん、こんにちわ!
確認、ご返信有難うございます。 また、無事復旧したとの事で嬉しく思います。
Proxyの自動構成スクリプトの問題かと思っていたのですが、テザリング利用でも治るケースがあるのですね! LTEとプロキシとリモートVPNの3つの相性問題もあるとのことで、とても興味深い情報、ありがとうございます! こちらこそ 勉強になりました。
エキスパートの回答、ステップバイステップガイド、最新のトピックなどお気に入りのアイデアを見つけたら、あとで参照できるように保存しましょう。
コミュニティは初めてですか?これらのヒントを活用してスタートしましょう。 コミュニティの活用方法 新メンバーガイド