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

Windows10+LTEデバイスでのAnyConnect接続の問題について

athirano1
Level 1
Level 1

こんにちは

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アクセスができない、上記の対応で多少改善がみられるといった振る舞いが同じです)
 
 
よろしくお願いします。

1 件の受理された解決策

受理された解決策

Akira Muranaka
Level 8
Level 8

athirano1さん、こんばんわ。

まず プロキシ(特に動的な処理)と リモートVPNですが、相性がかなり悪かったと記憶してます。 過去、何度かプロキシとVPNの相性問題のトラブル遭遇経験があります。 例えば、 VPNアプリケーション側が プロキシの動的な情報を正しく認識できないケース、プロキシの特殊通信(※プロキシは細工された通信を利用する)を上手く処理できないケース、そもそも 良くリリースノートを見るとその構成がサポートされてなかったケース、など様々です。 

本件の調査に戻りますが、LTEの問題か、プロキシの問題か、ブラウザの問題か、以下切り分けをされてみると如何でしょうか。

1. iPhoneなどのテザリング機能を利用して公衆網から接続してみる (LTE問題かの切り分け)

2. 自動構成スクリプトを利用せず、手動でプロキシサーバを指定する (自動構成スクリプトの問題かの切り分け)

3. Firefoxなど別ブラウザを利用する (ブラウザ問題かの切り分け)


個人的には 2. の問題の可能性が高いのかなと考えてます。

元の投稿で解決策を見る

3件の返信3

Akira Muranaka
Level 8
Level 8

athirano1さん、こんばんわ。

まず プロキシ(特に動的な処理)と リモートVPNですが、相性がかなり悪かったと記憶してます。 過去、何度かプロキシとVPNの相性問題のトラブル遭遇経験があります。 例えば、 VPNアプリケーション側が プロキシの動的な情報を正しく認識できないケース、プロキシの特殊通信(※プロキシは細工された通信を利用する)を上手く処理できないケース、そもそも 良くリリースノートを見るとその構成がサポートされてなかったケース、など様々です。 

本件の調査に戻りますが、LTEの問題か、プロキシの問題か、ブラウザの問題か、以下切り分けをされてみると如何でしょうか。

1. iPhoneなどのテザリング機能を利用して公衆網から接続してみる (LTE問題かの切り分け)

2. 自動構成スクリプトを利用せず、手動でプロキシサーバを指定する (自動構成スクリプトの問題かの切り分け)

3. Firefoxなど別ブラウザを利用する (ブラウザ問題かの切り分け)


個人的には 2. の問題の可能性が高いのかなと考えてます。

Akira Muranakaさん

athirano1です。いつもお世話になっております。

その後、テストした結果、
2. の「自動構成スクリプトを利用せず、手動でプロキシサーバを指定する 」で対応すると、状況が改善しました。
また、1.の「iPhoneなどのテザリング機能を利用して公衆網から接続してみる」でも、結果良好でした。

サービスを提供するエンドユーザーとも相談して、上記の1か2で対応したいと思います。

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

athirano1さん、こんにちわ!

確認、ご返信有難うございます。 また、無事復旧したとの事で嬉しく思います。

Proxyの自動構成スクリプトの問題かと思っていたのですが、テザリング利用でも治るケースがあるのですね! LTEとプロキシとリモートVPNの3つの相性問題もあるとのことで、とても興味深い情報、ありがとうございます! こちらこそ 勉強になりました。