キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 
cancel
告知

JTAC-Mid-Career-Recruitment-2021.3

CSC-campaign.JPG

 

ASA: リモートアクセスVPN パフォーマンス最適化のためのベストプラクティス (AnyConnect)

12450
閲覧回数
130
いいね!
0
コメント

 

はじめに

テレワークの推進に伴い、リモートアクセスVPN (RA VPN) の需要は増す一方です。しかし、リモートアクセスVPNの利用者の急増に伴い、そのアクセスを終端するリモートアクセスVPNサーバである、Cisco Adaptive Security Appliance (ASA) や Firepower Threat Defense (FTD) にアクセスが集中し、ASA や FTD の パフォーマンス低下に悩まされるケースも少なくありません。

本ドキュメントでは、ASA のリモートアクセスVPNのパフォーマンスを向上/最適化するためのベストプラクティスや、構成変更例、パフォーマンス低下トラブル時に確認すべきログなどについて紹介します。リモートアクセスVPN用の端末側のソフトウェアは、AnyConnect の利用を前提としております。

なお、本ドキュメントの情報は、一定以上のネットワークや製品の取扱い経験のある方向けに作成しております。本ドキュメントの情報は、ユーザー様ご自身の判断と責任において利用してください。なお、設定や構成変更は、事前に検証をしての、メンテナンスタイムや 通信影響の少ない時間帯に実施をお勧めします。

パフォーマンス最適化について具体的な設計や設定/導入支援が必要の場合は、弊社の 最適化サービス や、Cisco製品販売代理店様の最適化支援サービスなどのご利用を検討ください。 Cisco認定パートナーを探すには、購入案内 をご確認ください。

 

 

ASA データシート

VPNスループットや AnyConnect VPN ユーザセッション最大数はデータシートで確認できます。AnyConnect接続時の DTLSのスループットも、VPNスループットに近い処理性能を期待できます。なお、データシートの記載値は、テスト環境での最小限の設定でテスト時のデータがベースであることに注意してください。利用機能や設定、処理数、通信内容などにより最終的なパフォーマンスは変動します。

 

Cisco ASA 5500 Series Data Sheet
https://www.cisco.com/c/en/us/products/collateral/security/asa-firepower-services/datasheet-c78-742475.html

Cisco ASA 5585-X Stateful Firewall Data Sheet
https://www.cisco.com/c/en/us/products/collateral/security/asa-5500-series-next-generation-firewalls/datasheet-c78-730903.html

Cisco ASA with FirePOWER Services Data Sheet
https://www.cisco.com/c/en/us/products/collateral/security/asa-5500-series-next-generation-firewalls/datasheet-c78-733916.html

Cisco Adaptive Security Virtual Appliance (ASAv) Data Sheet
https://www.cisco.com/c/en/us/products/collateral/security/adaptive-security-virtual-appliance-asav/datasheet-c78-733399.html

Cisco Firepower 1000 Series Data Sheet
https://www.cisco.com/c/en/us/products/collateral/security/firepower-1000-series/datasheet-c78-742469.html

Cisco Firepower 2100 Series Data Sheet
https://www.cisco.com/c/en/us/products/collateral/security/firepower-2100-series/datasheet-c78-742473.html

Cisco Firepower 4100 Series Data Sheet
https://www.cisco.com/c/en/us/products/collateral/security/firepower-4100-series/datas

Cisco Firepower 9300 Series Data Sheet
https://www.cisco.com/c/en/us/products/collateral/security/firepower-9000-series/datasheet-c78-742471.html

   

 

主なボトルネック箇所と対策例

ASAのリモートアクセスVPNのパフォーマンスは様々な要素の影響を受けます。以下は 主なボトルネック箇所と その対策例です。

ボトルネック箇所 説明 対策例
スループット

通信量が多いほど、その通信の処理のため、ASAの負荷はあがります。 そのため、いかに通信量を下げるかが、パフォーマンスを保つうえで重要です。 通信効率の良いDTLSを利用することで スループット向上を期待できます

  • スプリットトンネルの利用
  • DTLSの利用
  • 適切なMTUの利用
  • 回線や経路の速度や品質
  • 通信量の多いユーザの確認や切断
  • AnyConnect 最大接続可能数の変更 
  • 構成変更
セッション数 各モデルには ハードコードの最大接続可能数があり、上限を超えてのAnyConnect接続はできません。また、新規AnyConnect接続のレートが高い場合、セッション確立処理負荷の上昇も伴います
  • 構成変更
利用機能や設定 一般的に機能や設定を使うほど少しずつパフォーマンスは低下します。リモートアクセスVPN終端のパフォーマンスを最大化するのに最も良い対応は、ASAをリモートアクセスVPN終端専用機にすることです
  • 不要な機能や設定の削減
モデル別の最適化 ASAv 仮想Firewallは、導入しているサーバ性能でパフォーマンスが変わります。ASA5585やFPR4100などハイエンドモデルの場合、エンジンのSSL処理の最適化が可能です
  • ASAvのパフォーマンス最適化
  • ハイエンドモデルのパフォーマンス最適化

 

 

 

パフォーマンス最適化のためのベストプラクティス

 

スプリットトンネルの利用

AnyConnectはデフォルトで全てのトラフィックをトンネリングします。インターネット宛通信もトンネリングされるため、社内のProxy経由でWebサイトにアクセスする場合、リモートアクセスVPNやWebサイトアクセス速度の両方のパフォーマンス低下の原因となります。

ASA-AnyConnect-performance-best-practice-diagram01.JPG

端末とASAのパフォーマンスを最大化する 最もシンプルかつ効果的な方法の1つが、"本当に必要なトラフィックのみトンネリング"することです。当対応により、AnyConnect端末とASA間のトラフィックの削減を期待でき、端末とASA 双方のパフォーマンス向上を期待できます。

本項では、特定宛先の通信を Split (分割) する技術である スプリットトンネルの活用例と、当機能を利用時の端末のセキュリティ対策について紹介します。

 

1. 社内宛の通信のみトンネリング (Split Tunneling)

ASA-AnyConnect-performance-best-practice-diagram02.JPG

インターネット宛の通信はクライアントから直接アクセスさせ、社内宛の通信のみトンネリングすることで、クライアントと ASA両方のパフォーマンス向上を期待できます。対象のIPアドレスやセグメントを予め明示指定するため、Static Split Tunneling とも呼ばれます。

社内宛の通信のみトンネリングする設定例は以下ドキュメントを参照してください。

 

2. 特定ドメイン宛の通信のみトンネリング除外 (Dynamic Split Tunneling)

ASA-AnyConnect-performance-best-practice-diagram03.JPG

全通信をトンネリングしつつも、Office 365や Webex、Salesforce などクラウドアプリケーションや、指定ドメインや FQDN宛の通信のみ インターネットにダイレクトアクセスしたいケースもあるかと思います。当ケースの場合、かつ、AnyConnect 4.5以降を利用時は、Dynamic Split Tunneling 機能を用いて、指定のドメインのみ トンネリング対象から除外することも可能です。 Dynamic Split Tunnelingの設定例や動作確認例は以下ドキュメントを参照してください。

なお、Dynamic Split Tunnelingで設定可能なドメイン/FQDNの文字数は 最大5000文字までになり、標準的なドメインだと300個程度が目安となります。それ以上のドメイン/FQDNの設定/制御を行いたい場合は、Dynamic Split Tunnelingではなく、Static Split Tunneling と Umbrellaの併用を検討してください。

 

3. 端末のセキュリティ対策

クラウド利用などインターネットアクセスの多い業務の場合、スプリットトンネルを効果的に活用することで、必要なトラフィックのみトンネル化し、端末とASAのパフォーマンスを大きく上げることができます。しかし、端末からのインターネットダイレクトアクセスは、端末が直接 脅威にさらされることになります。

端末のセキュリティ保護のため、AnyConnectは以下の追加モジュールを利用可能です。

  • Cisco Umbrella ・・・ DNS Web セキュリティ。悪意あるURLや 任意URLやアプリケーションのフィルタリングなど
  • Cisco AMP ・・・・・ 先進的なマルウェア保護。機械学習や統合管理、感染経路可視化にも対応

以下は、Umbrella Dashboardからの、YouTubeアプリケーションのアクセス制御の実施例です。
ASA-AnyConnect-performance-best-practice-umbrella-appli.JPG

 
以下は、Umbrella Dashboardからの、YouTubeドメインのアクセス制御の実施例です。
ASA-AnyConnect-performance-best-practice-umbrella-URL.JPG

 

各モジュールの詳細や導入方法などについては、シスコ製品販売代理店様や シスコアカウントチームまでご相談ください。

Ciscoのテレワークソリューションや、各機能について より詳しくは、以下ガイドなどを参照してください。

 

DTLSの利用

AnyConnectクライアントのASA接続は以下段階で進みます。

  1. SSL(TCP443) () を利用しASAに接続し証明書や認証、プロファイル情報など交換し セッション確立
  2. SSL()でデータ転送をしつつ、UDP443が利用可能な場合は UDP443を利用したDTLS tunnelでのデータ転送に自動切り替えを行う
  3. UDP443が利用できない場合は、TCP443を利用したSSL Tunnel (TLS) でデータ転送を継続する
        ※実際はSSLの代わりに よりセキュアなTLSが利用されていますが、CLI表示上はSSL

UDP443が利用可能な場合にDTLS利用に切り替える理由ですが、UDPはオーバーヘッドの少ない高速なプロトコルのため、データ転送効率化を期待できるためです。AnyConnectクライアントは、UDP443が利用可能な場合は 積極的にDTLS Tunnelでデータ転送を試みます。

TCPベースのTLSによるデータ転送の場合、シーケンスや順番制御などTCP特有の処理が発生し、特に低品質や混雑したネットワークの場合 パケットドロップや順番変更などによる再送や遅延も発生し、これらがパフォーマンスを下げる要因となります。通信環境によっては、TLS利用時のパフォーマンスは、DTLS利用時の半分以下になることもあります。

DTLSによるAnyConnect接続を行いたい場合、経路で SSL(TCP443)とDTLS(UDP443)の両方の通過が許可されている必要があります。例えば在宅勤務者がリモート接続する場合、その在宅者の家のルータで、TCP443のみでなく UDP443が許可されているか確認してください。

接続方式やDTLSでのデータ交換状況は、show vpn-sessiondb detail anyconnect コマンドで確認可能です。以下例の場合、AnyConnectクライアント 1.176.100.101は DTLSv1.2で接続され 暗号化はAES-GCM-256で行われ、400Mbytesほどの送信(Tx)と 6Mbytesほどの受信(Rx)があることがわかります。

ciscoasa(config)# show vpn-sessiondb detail anyconnect
                --- 略 ---
DTLS-Tunnel:
  Tunnel ID    : 10.3
  Assigned IP  : 1.176.100.101          Public IP    : 100.0.0.1
  Encryption   : AES-GCM-256            Hashing      : SHA384   
  Ciphersuite  : ECDHE-ECDSA-AES256-GCM-SHA384
  Encapsulation: DTLSv1.2               UDP Src Port : 62389
  UDP Dst Port : 443                    Auth Mode    : userPassword
  Idle Time Out: 30 Minutes             Idle TO Left : 30 Minutes
  Client OS    : Windows
  Client Type  : DTLS VPN Client
  Client Ver   : Cisco AnyConnect VPN Agent for Windows 4.7.04056
  Bytes Tx     : 392005089              Bytes Rx     : 5888313   
  Pkts Tx      : 283106                 Pkts Rx      : 142874
  Pkts Tx Drop : 0                      Pkts Rx Drop : 0

 

DTLSとTLSの利用状況は show vpn-sessiondb detail コマンドで確認できます。以下例の場合、DTLS(=DTLS-Tunnel)を利用するクライアントが1台、TLS (=SSL-Tunnel) を利用するクライアントが1台、合計 2台の AnyConnectクライアントが接続していることがわかります。DTLSを利用するクライアントは バックアップ用に SSLトンネルも保持してるため、SSL-Tunnel にはDTLSを利用するクライアントの数も含まれていることに注意してください。 AnyConnect-Parent  は特殊なトンネルで、管理やバックアップ用などに利用されます。

ASA5555# show vpn-session detail
---------------------------------------------------------------------------
VPN Session Summary
---------------------------------------------------------------------------
                               Active : Cumulative : Peak Concur : Inactive
                             ----------------------------------------------
AnyConnect Client            :      2 :          8 :           2 :        0
  SSL/TLS/DTLS               :      2 :          8 :           2 :        0
Clientless VPN               :      0 :          3 :           2
  Browser                    :      0 :          3 :           2
---------------------------------------------------------------------------
Total Active and Inactive    :      2             Total Cumulative :     11
Device Total VPN Capacity    :   5000
Device Load                  :     0%
---------------------------------------------------------------------------

---------------------------------------------------------------------------
Tunnels Summary
---------------------------------------------------------------------------
                               Active : Cumulative : Peak Concurrent
                             ----------------------------------------------
Clientless                   :      0 :          3 :               2
AnyConnect-Parent            :      2 :          8 :               2
SSL-Tunnel                   :      2 :          8 :               2
DTLS-Tunnel                  :      1 :          7 :               1
---------------------------------------------------------------------------
Totals                       :      5 :         26
---------------------------------------------------------------------------
 

AnyConnect端末側で、接続にDTLS/TLSどちらを利用しているかは、Advanced Window の Statisticsタブから確認できます。 端末が TLSで接続している場合、その端末とASA間の経路のどこかで UDP 443 がブロックされてる可能性があります。

[データ転送で DTLS (UDP443) 利用時]

ASA-AnyConnect-performance-best-practice-DTLS.JPG

 

[データ転送で TLS (TCP443) 利用時]

ASA-AnyConnect-performance-best-practice-TLS.JPG

 

なお、特に大企業やISPなど多数ユーザがリモートアクセスする環境の場合、一部のエンドユーザの通信環境ではUDP443が許可されていないケース (もしくは UDPを許可し忘れているケース)もあり、DTLSとTLS接続が混在している事も珍しくありません。 全ての接続を DTLS接続のみにすることは困難ですが、DTLSの接続割合を増やすことでパフォーマンス向上を期待できます。

 

適切なMTUの利用 

基本的にパケットサイズが大きいほど、一度に送信できるデータ量が増えるため、良いパフォーマンを得やすくなります。また、通常 1度に送付できるデータ量が多きいほど 交換に必要なパケット数が減るため、各パケットの暗号や解読回数が減り ASAのパフォーマンスも良くなります。しかし、パケットサイズが経路のMTUを上回ると フラグメント(パケット分割)やリアセンブル(パケット再構築)の手間が発生し パフォーマンスが劣化しやすくなります。そのため、ギリギリ分割されないパケットサイズの利用が高パフォーマンスを得やすくなります。

DTLSを利用時、AnyConnect端末間のMTUは自動チューニングされるため、通常 個別のカスタマイズは不要です。DTLSのカプセル化や暗号化のオーバーヘッドは最大94bytes のため、利用するNICのMTUから 94bytes引いた値をAnyConnect端末は利用し、かつ経路のMTUも問題ないか自動チェックや 必要に応じて更にMTUを下げる自動チューニングが行われます。例えば、端末の物理アダプタのMTUが1300の場合、AnyConnectは (1300 - 94) の MTU 1206 をまずは利用しようとし、仮にMTU1206で経路でフラグメントが検知される場合は さらに低いMTUが使われるよう自動調整されます。

TLSを利用時も、MTUの自動チューニングに対応しています。なお、DTLSで接続ができずTLSにフォールバックした場合、AnyConnect MTUによっては DTLS→TLS切り替え時にリコネクト処理が発生することがあります。TLSにフォールバック時の Reconnectを極力避けたい場合は、AnyConnect の MTU について の、「3-1. 接続して約1分後に Reconnect が発生する」「1.AnyConnect MTU の基本設定」を参考に、適宜AnyConnect MTUを手動調整するのが有効です。しかし、Reconnectを避けるためAnyConnect MTUを低く設定しすぎると、その分 一回の通信で転送できるパケット最大サイズが小さくなることによるパフォーマンス低下の原因となるため注意してください。

AnyConnect接続は IKEv2にも対応してますが、IKEv2をAnyConnect接続で利用時の場合、MTUの自動チューニングに対応してないため、手動設定が必要となることに注意してください。また、基本的にDTLSを利用したAnyConnect接続を、シスコではお勧めしています。

AnyConnectのMTUと、そのチューニング方法について詳しくは、以下ドキュメントを参照してください。

 

不要な機能や設定の削減 

多くのASA機能はソフトウェア処理のため、利用機能や設定量、その利用頻度(=AnyConnectセッションやコネクション数)が増えるほど、少しずつパフォーマンスは低下します。

例えば、ASAを リモートアクセスVPN終端のみでなく、社内通信のインターネットアクセス用のPAT/Firewall装置として兼用している場合、そのNATやFirewall処理にもASAパフォーマンスが利用されるため、リモートアクセスVPN処理のためのパフォーマンス余力が減ります。逆に、ASAをリモートアクセスVPN終端専用機として利用すると、ASAのリモートアクセスVPN処理のパフォーマンスを最大化することができます。

例えば、AnyConnectのアクセス制御にVPN Filterを利用時は、ACLの設定行が多いほど 接続毎のACLの検査負荷があがります。例えば、「可能な限りIP単位の制御はせず セグメント単位で制御する」「宛先ポートの制御は極力しない」など実施しACL設定量を減らすことで、ACL検査負荷を下げることができます。もしくは、ASAでのアクセス制御はしないか最低限にし、払い出されたIPアドレスに対して 経路上の別の機器(スイッチやルータなど)でACLアクセス制御を行うことで、ASAの処理負荷低減が可能です。

例えば、Dynamic Access Policy (DAP) の利用している場合は、レコード数を多くとも20~30内などにするなど 少なくすること(=複雑にしすぎないこと)で、DAP設定によるパフォーマンス減や トラブル防止に役立ちます。

例えば、Syslog機能を多用している環境の場合、膨大なログを出力するSyslog設定が、Syslog生成処理によるパフォーマンス低下や、Syslogメッセージによる帯域圧迫につながるケースもあります。ロギングを適切なレベルに設定することで、ロギング負荷を下げることができます。 ロギングのチューニング例について詳しくは以下ドキュメントを参照してください。

ACLや DAPなど通信制御機能や、Syslogなど管理機能の処理負荷 1つ1つは小さいです。しかし、特にテレワークによる利用者数の急増に伴い 接続量が急激に増えると、それに伴い 各接続毎にACLやDAPなど制御の膨大な実施や、膨大な通信量のロギングなどが発生すると、その負荷は乗算的に増え、無視できない負荷量になることがあります。 特に多数の接続を収容が必要で パフォーマンス余力があまりない場合は、機器や設定はシンプルに、他の機器でも代用できる機能や設定は 他の機器で実施するなどし、ASAはリモートアクセスVPN接続処理に集中できるよう最適化することで、パフォーマンス余力を上げることができます。

 

回線や経路の速度と品質 

VPNパフォーマンスが出ない理由に、AnyConect端末と ASA終端装置間の通信経路上の機器や回線の、最大速度と品質がボトルネックとなっている事があります。例えば、VPN処理性能が 1GbpsのASAを利用しても、通信経路の回線の最大速度が500Mbps程度の場合、ASAも最大500Mbps程度までしか処理できません。また、回線や経路装置の処理混雑などの影響による遅延やドロップも、パケット再送や通信失敗の原因となり、大きなパフォーマンス低下の原因となることもあります。

回線業者(ISP)や集合住宅設備によっては、UDP443(=DTLS)の通過を拒否していたり、TCPやUDPの速度制限をかけているケースがあり、その結果、パフォーマンスの良いDTLSの利用不可や、想定の速度が得れない結果につながる事があります。

回線や経路機器がボトルネックとなっている場合は、その改善には、速度や品質に優れる回線や設備に切り替えが必要です。

在宅勤務者の自宅回線や通信経路がボトルネックになってるかの簡単な切り分けは、AnyConnectの接続を 自宅回線から、スマートフォンのテザリング経由や 公衆WLANなどの、別の回線・設備経由に切り替え、速度や品質が改善するか確認することです。

 

通信量の多いユーザの確認や切断 

トラフィック量の多いセッションがないか確認し、明らかに過剰な利用のあり全体のパフォーマンスを落とす場合は、トラフィック量の多い利用者に 利用を控えるよう促したり、強制切断も可能です。

1. 通信量の多いAnyConnectセッションの確認

ユーザー名ごとのトラフィック量や接続時間の確認は "show vpn-sessiondb anyconnect | in Username|Bytes|Duration"コマンドの実施が便利です。以下出力例の場合、中村(nakamura)さんは 接続時間が10分ほどで 約5GB(≒5,156,556,220)のデータがASAから送信(Tx)されていること、ciscoさんは 接続時間が1分ほどで 約23MB(≒23,545,802)のデータをASAが受信(Rx)していることを確認できます。

ASAv10(config)# show vpn-sessiondb anyconnect | in Username|Bytes|Duration
Username     : nakamura               Index        : 35
Bytes Tx     : 5156556220             Bytes Rx     : 75519009
Duration     : 0h:10m:31s
Username     : cisco                  Index        : 36
Bytes Tx     : 661625                 Bytes Rx     : 23545802
Duration     : 0h:01m:08s
ASAv10(config)#

 
指定ユーザ名のAnyConnectセッションの切断は "vpn-session logoff name <Username>"コマンドで可能です。以下出力例の場合、特に通信量が多い 中村さんを切断しています。

ASAv10(config)# vpn-session logoff name nakamura
Do you want to logoff the VPN session(s)? [confirm]
INFO: Number of sessions with name "nakamura" logged off : 1

 
以下は手動切断時のログ抜粋です。なお、切断ログからも送信(xmt)や受信(rcv)のバイト数を確認できます。

Apr 02 2020 13:00:57: %ASA-4-722037: Group <GroupPolicy_AnyConnect-01> User <nakamura> IP <100.0.0.2> SVC closing connection: Administrator Reset.
Apr 02 2020 13:00:57: %ASA-6-716002: Group <GroupPolicy_AnyConnect-01> User <nakamura> IP <100.0.0.2> WebVPN session terminated: Administrator Reset.
Apr 02 2020 13:00:57: %ASA-4-113019: Group = AnyConnect-01, Username = nakamura, IP = 100.0.0.2, Session disconnected. Session Type: AnyConnect-Parent, Duration: 0h:13m:10s, Bytes xmt: 5306488447, Bytes rcv: 77713985, Reason: Administrator Reset

切断されると、AnyConnect端末側では「The secure gateway has terminated the VPN connection. The following message was received from the secure gateway: Administrator Reset」の切断理由のポップアップします。

なお、切断しても、AnyConnectクライアントはASAに再接続が可能です。そのユーザからの接続を常に拒否したい場合は、そのユーザアカウントの削除や停止などの追加対応が必要となります。


ASDMを利用時の場合は、Monitoring > VPN > VPN Statistics > Sessions から 利用ユーザと通信状態や、指定ユーザの切断(Logout) 操作が可能です。

ASA-AnyConnect-performance-best-practice-asdm-session.JPG

 

2. 通信量の多いコネクションとユーザの確認

トラフィック量の多いコネクションを確認したい場合は、以下のドキュメントを参考にしてください。

例えば以下は、トラフィック量が 100Mバイト以上 1Tバイト未満のコネクションの確認例です。1.176.100.101から 1.0.0.1宛に、約500MB (≒532,227,750bytes) ほどの通信が発生中であることを確認できます。

ASAv10(config)# show conn long | in (bytes .........,)|(bytes ..........,)|(bytes ...........,)|(bytes ............,)
TCP outside: 1.176.100.101/12056 (1.176.100.101/12056) dmz: 1.0.0.1/10355 (1.0.0.1/10355), flags UxOB , idle 0s, uptime 1m1s, timeout 1h0m, bytes 532227750, xlate id 0x7f12b410c980

 

アサインされたIPアドレスからユーザー名を探すのは、"show vpn-sessiondb anyconnect filter a-ipaddress <IP Address>"コマンドで可能です。 以下例の場合、通信発生元は 中村さんであり、ASAから総送信バイト数(Tx)は 2.1GBほどであることを確認できます。

ASAv10(config)# show vpn-sessiondb anyconnect filter a-ipaddress 1.176.100.101

Session Type: AnyConnect

Username     : nakamura               Index        : 38
Assigned IP  : 1.176.100.101          Public IP    : 100.0.0.1
Protocol     : AnyConnect-Parent SSL-Tunnel DTLS-Tunnel
License      : AnyConnect Premium
Encryption   : AnyConnect-Parent: (1)none  SSL-Tunnel: (1)AES-GCM-256  DTLS-Tunnel: (1)AES256
Hashing      : AnyConnect-Parent: (1)none  SSL-Tunnel: (1)SHA384  DTLS-Tunnel: (1)SHA1
Bytes Tx     : 2159997739             Bytes Rx     : 31630830
Group Policy : GroupPolicy_AnyConnect-01
Tunnel Group : AnyConnect-01
Login Time   : 13:22:29 UTC Thu Apr 2 2020
Duration     : 0h:06m:15s
Inactivity   : 0h:00m:00s
VLAN Mapping : N/A                    VLAN         : none
Audt Sess ID : 019600a9000260005e85e715
Security Grp : none

   

AnyConnect 最大接続可能数の変更 

ASAはデフォルトで許可されている最大接続数まで RA VPN接続を受け入れます。しかし、アクセス数が集中し全台が同時に通信したり、一部端末でバースト的なトラフィックが発生すると、全体の1台あたりの利用できるスループットが落ち、ご利用のアプリケーションにもよりますが、業務上 実用に耐えれないスループットとなることもあります。また、同時コネクション数や新規接続レートが高いほど、その管理や処理でもASAの負荷が上昇します。

以下のコマンドで最大接続数を下げることで、接続と通信集中による全体のパフォーマンス低下リスクを抑えることができます。

vpn-sessiondb max-anyconnect-premium-or-essentials-limit [number]

 

ASDMの場合、以下メニューから AnyConnectの最大セッション数を設定可能です。

Configuration > Remote Access VPN > Advanced > Maximum VPN Sessions

 
例えばVPNスループット 1Gbpsの製品で、机上で 1台あたり10Mbps程度の通信速度を確保したい場合は、最大接続数を100までにすることで、1台あたりのスループットを確保できます。(ただ実際は、各端末の全員が同時通信するわけではないため、最大接続数はさらに多めで考えてもよいです。)

なお、最大接続可能数を越えた接続は、以下のシスログ出力を伴い拒否されます。 切断されたAnyConnect利用者は、手動で別のリモートアクセスVPNサーバに接続の切り替えが必要です。

Mar 31 2020 13:31:38: %ASA-6-113012: AAA user authentication Successful : local database : user = cisco
Mar 31 2020 13:31:38: %ASA-6-113009: AAA retrieved default group policy (GroupPolicy_AnyConnect-01) for user = cisco
Mar 31 2020 13:31:38: %ASA-6-113008: AAA transaction status ACCEPT : user = cisco
Mar 31 2020 13:31:38: %ASA-4-113029: Group <GroupPolicy_AnyConnect-01> User <cisco> IP <100.0.0.1> Session could not be established: session limit of 1 reached.
Mar 31 2020 13:31:38: %ASA-4-113038: Group <GroupPolicy_AnyConnect-01> User <cisco> IP <100.0.0.1> Unable to create AnyConnect parent session.

 

また、上記の具体的な接続数制限は行わず、まずは SNMPポーリングでVPN接続数の監視を行い、任意の閾値を越えたら ユーザ接続状況の確認や適宜チューニング、増設判断などの対応を検討するのも、有効な運用の1つです。 VPN接続数の SNMPポーリングによる監視方法について詳しくは、ASA/AnyConnect: VPNセッション数の確認と SNMPモニタリング方法 を参照してください。

VPNセッション数のコマンドラインでの確認方法や 評価方法についてより詳しくは、本ドキュメント内の トラブルシューティング - VPNセッション数の確認 も、合わせご確認ください。

  

ASAvのパフォーマンス最適化 

ASAvは仮想アプライアンスであり、ESXiや KVM、AWS、Hyper-vなど仮想基盤の上にデプロイし利用することができます。以下に ASAvのパフォーマンス最適化のためのベストプラクティスと 確認例を紹介します。

 

1. 高性能な新しめのサーバにASAvをデプロイ

ASAvのVPNパフォーマンスは、利用するCPUコアのClockや DRAM処理速度などの影響を受けます。そのため、性能の高い and/or 新しい世代のIntel CPUや、パフォーマンスの良いメモリや NICを搭載した高性能サーバにASAvをデプロイすることで、ASAvの VPNパフォーマンスを高めることが可能です。

 

2. ASAバージョン 9.12以降と AnyConnect 4.7以降を利用

AnyConnect 4.7と ASA 9.10 以降で DTLSv1.2が利用可能になりました。なお、ASA9.10は既にEoLがアナウンスされてるため、後継の安定バージョンである9.12やそれ以降の 2桁目が偶数トレインの利用が推奨されます。AnyConnectは最新バージョンの利用が推奨されます。DTLSv1.2は 暗号方式にデフォルトでAES-GCMを利用し、利用CPUによってはAES-GCMの高速処理に対応しており、パフォーマンス向上を期待できます。

 
3. ASAv10のパフォーマンス比較例

以下は、検証環境での ASAv10のデプロイ先サーバ別の、DTLSv1.0と DTLSv1.2を利用時のパフォーマンス比較です。なお、ASAv10のデータシート上のVPNスループットは 150Mbps です。

以下の試験結果から、CPU世代が新しい場合 (v3は3世代目)、もしくは、CPUコアの周波数が高い場合は、高いパフォーマンスを得やすいことを確認できます。 なお、以下は簡易的な環境・設定での試験結果であり、スループットは設定や機能、環境などによっても変動するまで、あくまで参考レベルで利用ください。

バージョン 利用サーバと
 CPU
トンネル
プロトコル
暗号方式 ダウンロード速度 (実測) ASA CPU
使用率
AnyConnect 4.7
ASAv10 9.12(3)9
C240-M4
E5-2683v3
@2.0GHz
DTLSv1.2 AES-GCM-256
(デフォルト)
77Mbps 22 %
AnyConnect 4.6
ASAv10 9.12(3)9
C240-M4
E5-2683v3
@2.0GHz
DTLSv1.0 AES256
(デフォルト)
70Mbpos 31 %
AnyConnect 4.7
ASAv10 9.12(3)9
C240-M3
E5-2650
@2.0GHz
DTLSv1.2 AES-GCM-256
(デフォルト)
81Mbps 30 %
AnyConnect 4.6
ASAv10 9.12(3)9
C240-M3
E5-2650
@2.0GHz
DTLSv1.0 AES256
(デフォルト)
77Mbps 32 %
AnyConnect 4.7
ASAv10 9.12(3)9
C240-M3
E5-2680
@2.8GHz
DTLSv1.2 AES-GCM-256
(デフォルト)
80Mbps 21 %
AnyConnect 4.6
ASAv10 9.12(3)9
C240-M3
E5-2680
@2.8GHz
DTLSv1.0 AES256
(デフォルト)
77Mbps 27 %

試験方法:

  • AnyConnect端末と ASAv10間で、DTLSセッションを1つ貼り、FTPサーバから大容量ファイルのダウンロード
  • 平均パケットサイズは1,000バイトほど。AnyConnect MTUは 1390バイト
  • DTLSv1.2の接続試験は、AnyConnect バージョン 4.7 と、ASAv 9.12(3)9 を利用。デフォルトでDTLSv1.2で自動接続し、暗号方式は AES-GCM-256 が自動使用される
  • DTLSv1.2の接続試験は、AnyConnect バージョンを 4.6にさげて実施。 AnyConnect 4.6は DTLSv1.2に対応してないため、トンネルプロトコルは DTLSv1.0に代わる。 DTLSv1.0の場合、暗号方式は AES256 が自動使用される
  • 本試験において、AnyConnectのバージョン変更以外は、ASAvや 端末の設定や構成は変えていない
  • AnyConnect接続設定は ASA でのスプリット トンネリングによる AnyConnect セキュア モビリティ クライアントの設定 を元に設定した、最もシンプルなリモートアクセスVPN接続設定。スプリットトンネルは未使用

 

4. ASAvのスループット上限

なお、高性能サーバを利用しても、ASAvは予め指定されたスループット以上のパフォーマンスは出ないことに注意してください。スループットの上限を超えた場合、若干の猶予をもって レートリミット (速度制限) が適用されます。

モデル vCPU/RAM 最大スループット
ASAv5(100 M) 1 vCPU / 1 GB 100 Mbps
ASAv10(1 GB) 1 vCPU / 2 GB 1 Gbps
ASAv30(2 GB) 4 vCPU / 8 GB 2 Gbps
ASAv50(10 GB)  8 vCPU / 16 GB 10 Gbps

 

 

5. ASAvのネットワークアダプタ

VMwareの場合、割り当てるネットワークアダプタの アダプタタイプが VMXNET3や IXGBE-VFの場合 良好なパフォーマンスを期待できます。利用してるネットワークアダプタは、仮想マシンの設定の編集から確認ができます。以下例の場合、VMXNET3を利用していることがわかります。

AdapterType.JPG

 

もしくは、show interface コマンドでも確認可能です。以下例の場合、E1000を利用していることがわかります。

ciscoasa# show interface m0/0 
Interface Management0/0 "management", is up, line protocol is up
  Hardware is net_e1000_em, BW 1000 Mbps, DLY 1000 usec 
タイプ 表示例 備考
E1000 net_e1000_em 旧VMware デフォルト (非推奨)
ASAv 9.2(1)以降でサポート
VMXnet3 net_vmxnet3 VMware デフォルト
ASAv 9.9(2)以降でサポート
(※利用時はLRO無効化を)
IXGBE-VF net_ixgbe_vf AWS デフォルト
SR-IOVのサポートに必要
ASAv 9.8(1)以降でサポート
Virtio net_virtio KVM デフォルト
ASAv 9.3(2.200)以降でサポート

 

 なお、VMware版で VMXnet3を利用する場合は、パフォーマンスの最適化のためには LROの無効化が必要です。VMware社のガイドか、ASAvの利用バージョンの設定ガイドを参照してください。以下はASAv 9.14を利用時の設定ガイドのURLとその抜粋です。

 https://www.cisco.com/c/en/us/td/docs/security/asa/asa914/asav/getting-started/asav-914-gsg/asav_intro.html#id_45636

Disable LRO for VMware and VMXNET3
Large Receive Offload (LRO) is a technique for increasing inbound throughput of high-bandwidth network connections by reducing CPU overhead. It works by aggregating multiple incoming packets from a single stream into a larger buffer before they are passed higher up the networking stack, thus reducing the number of packets that have to be processed. However, LRO can lead to TCP perfomance problems where network packet delivery may not flow consistently and could be "bursty" in congested networks.

Important	
VMware enables LRO by default to increase overall throughput. It is therefore a requirement to disable LRO for ASAv deployments on this platform.

  

ハイエンドモデルのパフォーマンス最適化 

Note: ハイエンドモデルで AnyConnectの SSL接続を多用する場合は チューニングを検討してください 

ASA5545/5555/5585や、FPR4100/9300シリーズ()などハイエンドモデルでは、専用の高速処理用の暗号処理エンジンを搭載しており、暗号処理エンジンの処理優先度を、IPsec もしくはSSL もしくは Balancedの何れかに変更が可能です。ASA5545/5555/5585は IPsecがデフォルト、FPR4100/9300シリーズは Balanced がデフォルト値です。
(※FPR4100シリーズの最新モデルである FPR4115/4125/4145と FPR9300モジュールのSM-40/48/56は 当チューニング機能に対応しておらず、サポート予定も御座いません。)

例えば、SSL利用が殆どの環境の場合、"crypto engine accelerator-bias ssl"コマンドを実行することで、暗号処理エンジン内のコアが SSL処理優先の割当に切り替わり、AnyConnectのSSL接続時のパフォーマンスを最大化できます。

例えば、SSLと IPsecの処理負荷が同程度の環境の場合は、"crypto engine accelerator-bias balanced"コマンドを実行することで、暗号処理エンジン内のコアが IPsec処理と SSL処理用で半々となり、バランスよく両方の暗号処理が可能になります。

ご利用の環境で、SSLと IPsec どちらが多く利用されているかは、"show vpn-sessiondb detail" コマンドで確認できます。例えば、以下出力例の場合、全体のVPNセッションの中で、ほぼ100%をSSLが占めており、IKEv1やIPsecは極わずかのため、当利用状態が続く場合は、"crypto engine accelerator-bias ssl"コマンドでSSL処理を優先することが最適であることがわかります。

---------------------------------------------------------------------------
VPN Session Summary
---------------------------------------------------------------------------
                               Active : Cumulative : Peak Concur : Inactive
                             ----------------------------------------------
AnyConnect Client            :   2121 :      12111 :        3086 :        8
  SSL/TLS/DTLS               :   2121 :      12111 :        3086 :        8
Load Balancing(Encryption)   :      1 :         50 :           2
---------------------------------------------------------------------------
Total Active and Inactive    :   2130             Total Cumulative :  12151
Device Total VPN Capacity    :  10000
Device Load                  :    21%
---------------------------------------------------------------------------

---------------------------------------------------------------------------
Tunnels Summary
---------------------------------------------------------------------------
                               Active : Cumulative : Peak Concurrent
                             ----------------------------------------------
IKEv1                        :      1 :         10 :               2
IPsec                        :      1 :          3 :               2
AnyConnect-Parent            :   2109 :      12111 :            3086
SSL-Tunnel                   :   2034 :      25859 :            3055
DTLS-Tunnel                  :   1496 :      13451 :            2279
---------------------------------------------------------------------------
Totals                       :   5651 :      51434
---------------------------------------------------------------------------

 

なお、"crypto engine accelerator-bias [IPsec|balanced|ssl]"コマンドの実行は 通信影響を伴う恐れがあるため、メンテナンス時間か、通信影響の少ない時間帯に実施してください。

コアの割当割合や処理状況は"show crypto accelerator load-balance"コマンドで確認できます。

例えば以下はASA5555でのコマンド実行と確認例です。デフォルトの IPsec優先の場合は コア利用割合が"IPSEC 5, SSL 3"であること、Balancedに変更後は"IPSEC 4, SSL 4"であること、SSLに変更後は"IPSEC 1, SSL 7"である事を確認できます。 

ASA5555(config)# show crypto accelerator load-balance ssl

                  Crypto SSL Load Balancing Stats:
                  ==================================

Engine      Crypto Cores             SSL Sessions            Active Session
                                                             Distribution (%)
======     ==============      ===========================   ================
  0        IPSEC 5, SSL 3      Total:  2422  Active:     3         100.0%

                          --- 略 ---
ASA5555(config)# 
ASA5555(config)# crypto engine accelerator-bias ?

configure mode commands/options:
  balanced  Equally distribute crypto hardware resources
  ipsec     Allocate crypto hardware resources to favor IPsec/Encrypted Voice (SRTP)
  ssl       Allocate crypto hardware resources to favor SSL
ASA5555(config)#
ASA5555(config)# crypto engine accelerator-bias ssl
ASA5555(config)#
ASA5555(config)# show crypto accelerator load ssl


                  Crypto SSL Load Balancing Stats:
                  ==================================

Engine      Crypto Cores             SSL Sessions            Active Session
                                                             Distribution (%)
======     ==============      ===========================   ================
  0        IPSEC 4, SSL 4      Total:  2423  Active:     2         100.0%

                          --- 略 ---
ASA5555(config)#
ASA5555(config)# crypto engine accelerator-bias ssl
ASA5555(config)#
ASA5555(config)# show crypto accelerator load ssl


                  Crypto SSL Load Balancing Stats:
                  ==================================

Engine      Crypto Cores             SSL Sessions            Active Session
                                                             Distribution (%)
======     ==============      ===========================   ================
  0        IPSEC 1, SSL 7      Total:  2426  Active:     4         100.0%

 

以下は FPR4100シリーズの FPR4150でのコマンド実行と確認例です。FPR4150は暗号処理用のエンジンが2つあり、デフォルトの Balancedの場合は IPSEC 28 : SSL 28、SSL優先処理に切り替えた場合は IPSEC 4 : SSL 52 となることがわかります。 モデルにより暗号処理用のエンジンやコア数が異なり、割り当てられるコア数も異なります。

FPR4150(config)# show crypto accelerator load

                  Crypto IPSEC Load Balancing Stats:
                  ==================================

Engine      Crypto Cores             IPSEC Sessions          Active Session
                                                             Distribution (%)
======     ==============      ===========================   ================
  0        IPSEC 28, SSL 28      Total:     0  Active:     0         0.0%
  1        IPSEC 28, SSL 28      Total:     0  Active:     0         0.0%

            ----- 略 -----
FPR4150(config)# 
FPR4150(config)# crypto engine accelerator-bias ssl
FPR4150(config)#
FPR4150(config)# show crypto accelerator load


                  Crypto IPSEC Load Balancing Stats:
                  ==================================

Engine      Crypto Cores             IPSEC Sessions          Active Session
                                                             Distribution (%)
======     ==============      ===========================   ================
  0        IPSEC 4, SSL 52      Total:     0  Active:     0         0.0%
  1        IPSEC 4, SSL 52      Total:     0  Active:     0         0.0%

 

 

構成変更 

既存ASAで、スループットや同時接続数の増大などにより、最適化を実施しても パフォーマンスや処理能力が足りない場合、上位機器へのリプレースや ASA増設などの対応も必要となってきます。以下に構成変更による対応例を紹介します。

 

1. 上位モデルにアップグレード

既存機器から上位モデルにリプレース・設定を移行することで、設定や構成を大きく変えずに パフォーマンスや最大接続可能数の向上が可能です。最もシンプルで確実な方法です。


2. 複数ASAの運用と サーバリスト機能の利用

ASAを増設し、地域や人数などで接続先を分けることで、簡易的なActive/Active構成として各ASAを運用可能です。

例えば以下の構成のように、関東地区のユーザーは TOKYO-ASA-01を、東海地区のユーザは TOKYO-ASA-02を、関西地区のユーザは OSAKA-ASA を 各プライマリサーバとして利用し、他ASAをバックアップサーバとして指定することで、各ASAで負荷分散と、万が一障害時の冗長性を確保できます。各ASAには パブリックIPアドレスが必要です。

Client-Profile-Diagram-03.JPG

 

各ASAが独立して動作するため、ASA間の設定やステート同期は行われません。そのため、各ASAは個別管理が必要です。

特に、既に複数ASAをインターネットファイアウォールとして利用している環境の場合、各ASAにリモートアクセスVPNサーバ設定を行えば、比較的楽に当構成を利用できるのがメリットです。

バックアップサーバの指定は AnyConnect Client Profileを用いて可能です。詳しくは以下ドキュメントを参照してください。

  

3. 複数ASAの運用と VPNロードバランシング機能の利用

ASAを増設し、各ASAでVPNロードバランシングを組むことで、AnyConnect端末は 最も負荷の低いASAに自動接続が可能です。

VPN-load-balancing.JPG


VPNロードバランシングは以下の特徴があります。

  • 2台から最大10台までのASAで組める、VPNアクセス専用の負荷分散用構成
  • 異なるモデルも利用可。各機器で同じバージョン利用が推奨
  • 1台がMaster機となり、他のBackup機のVPN接続状況を管理
  • AnyConnectはまずMaster機の共有仮想IPアドレスに接続する。Master機は 負荷の少ないASAのパブリックIPアドレスを応答する
  • 共有仮想IPアドレスと 各ASAのパブリックIPアドレスの、台数分+1のパブリックIPアドレスが必要 。例えば、ASA 4台でVPNロードバランシングを組む場合、5つのパブリックIPアドレスが必要
  • 各機器で設定やステートの同期は行われない

例えば、1台で最大500のVPN終端が可能なASA 2台で VPN Load Balancingを組んだ場合、最大 1000までの終端が可能になります。各機器でリモートアクセスVPN処理負荷が分散されるため、1台に接続が集中しボトルネックになることも回避できます。

なお、各機器で設定やステートの同期は行われないため、仮に1台のASAが故障時は、そのASAが終端していたリモートアクセスVPN接続は最初からやり直す必要があります。そのため、VPN load balancing は、ASAやパブリックIPアドレスに余裕があり、パフォーマンスや同時接続数を特に重視したい環境に向いてます。

VPNロードバランシングについて詳しくは利用バージョンの設定ガイドなどを参照してください。例えば以下は、ASAバージョン9.12の設定ガイド例です。
https://www.cisco.com/c/ja_jp/td/docs/security/asa/asa912/configuration/vpn/asa-912-vpn-config/asa-912-vpn-config_chapter_011.html#ID-2186-000003f0

VPNロードバランシングの機能や導入構成例は以下ドキュメントも参考にしてください。
https://www.cisco.com/c/en/us/td/docs/security/asa/misc/anyconnect-faq/anyconnect-faq.html#Cisco_Reference.dita_41edac65-48a1-4dec-ba68-edcd55629af3

   

4. 構成変更例の比較

各構成毎にメリット・デメリットが異なります。以下は その比較表です。

構成変更例 最小Public IPアドレス 最大同時接続数 障害時 切り替え 負荷分散

上位モデルに

アップグレード

1つ
(既存機から流用)
1台分のみ

Failover機能利用時は、
高速な自動切り替え

セッション保護あり

1台分のみ

複数ASAと

サーバリスト

台数分必要 各台の総和

自動切り替え

セッション保護なし

手動
(端末側で接続先分散)

複数ASAと

VPNロードバランシング

台数分 + 1つ* 必要
  * 仮想IP用
各台の総和

自動切り替え

セッション保護なし

自動
(ASA側で接続先分散)

  

 

トラブルシューティング

CPU使用状況の確認 

CPU使用率はダイレクトにVPNパフォーマンスに影響を与えます。 CPU使用率は 暗号化や解読処理が増えるほど増加するため、VPNスループットが限界に近い場合、殆どの場合() 高いCPU使用率を確認できます。(※ハイエンドモデルの場合は、SSLとIPsecと利用状況に合わせて暗号エンジンの最適化を実施しないと、VPNスループットが低速化し、CPU使用率が期待通りに出ないことがあるので、ハイエンドモデル利用時は注意してください。) 

また、同じVPNスループットを発生させても、利用する製品や機能、設定量、同時接続数、トラフィックパターン、利用バージョン、環境など様々な要素の影響を受けCPU使用率は変わります。

 

CPU使用状況と負荷を確認するのに特に有用なコマンドは以下3つです。なお、以下コマンドは show tech コマンドを取得した場合も含まれてます。

  • show cpu usage
  • show process cpu-usage non
  • show cpu detail

 

当コマンドを利用してCPU高負荷問題のトラブルシューティング手法について詳しくは以下ドキュメントを参照してください。

 
CPU全体と各コアの負荷状況は SNMPポーリングで監視も可能です。 SNMPポーリングでの監視方法は 以下ドキュメントを参照してください。なお、各プロセス負荷やCP負荷など細かな確認はコマンドラインから確認する必要があります。

 

ケーススタディ1: 通信量や接続量が多く過負荷の場合

最も一般的な過負荷ケースです。

以下例の場合、CPU使用率が88%で明らかに過負荷な状態です。CPU 使用率 88%の内訳は、DATAPATHが各 44%と、他に Loggerや ARP、CP Processingなどの処理で僅かにCPU負荷が発生している事を確認できます。DATAPATHは、VPN (SSLやIPsec) や Firewall (ACL/NAT/Routing/Session管理など) などの 比較的 単純な処理をマルチコアで分散し高速で行うプロセスです。つまり、以下例の場合、VPN/Firewallの基本処理で88%のCPU使用があり、過負荷である事を確認できます。

ASA# show cpu usage 
CPU utilization for 5 seconds = 88%; 1 minute: 88%; 5 minutes: 82%

ASA# show processes cpu-usage non-zero 
PC         Thread       5Sec     1Min     5Min   Process
0x00000000019da592   0x00007fffd808b040     0.0%     0.0%     0.5%   Logger
0x0000000000844596   0x00007fffd807bd60     0.0%     0.0%     0.1%   CP Processing
0x0000000000c0dc8c   0x00007fffd8074960     0.1%     0.1%     0.1%   ARP Thread
   -          -        43.8%    43.8%    40.3%   DATAPATH-0-2209
   -          -        43.9%    43.8%    40.3%   DATAPATH-1-2210

一般的に ASAのCPU使用率が80%以上の場合、通信ドロップや不安定化の原因となり、過負荷といえます。本ドキュメントのチューニングを実施しても、CPU高負荷の改善が難しい場合、機器のアップグレードや増設など構成変更の検討が必要です。上位機種ほど、通常 コア数やCPU数が増加し、より高性能な暗号処理エンジンを搭載しているため、多数コアのデータパスの分散処理によりパフォーマンスが向上します。

 

ケーススタディ2: CP機能の過剰利用による過負荷の場合

ASAのプロセスは、マルチコア分散処理に対応した VPN/Firewall処理に最適化されたDATAPATHの処理と、"それ以外の処理"(Failover管理や ロギング、SNMP、SSH/Telnet/Console、WebVPNの細かな制御など)に分かれます。 "それ以外の処理"は通常 Control Point (CP) 領域で処理されます。 Control Point の 処理能力は最大1コア分しかありません。なお、CP処理について詳しくは、ASA: show processes cpu-usage を用いた CPU負荷の調査 の "コントロールポイントとは"項を参照してください。

以下例の場合、CPU使用率は9%ですが、CPの処理能力がほぼ限界であり、CPがボトルネックとなり過負荷となっているケースです。show cpu detail コマンドの 括弧内の右の数値を足すことでCP負荷状況は確認でき、以下例の場合 24.4 + 22.6 + 21.0 + 24.8 で、CP負荷が 92%で過負荷である事を確認できます。もしくは、show process cpu-usage コマンドの DATAPATH以外のプロセス負荷の合計を コア数で乗算することでも 求められます。例えば、以下出力例の場合は、(5.3% + 0.2%) x 16 = 約88% のCP負荷である事が分かります。

以下例の場合、WebVPN関係の細かな制御を行う Unicorn Proxy Thread で CP処理能力の 85% (=5.3% x 16)ほど使っている事が分かり、ボトルネックとなっている事が分かります。CPが過負荷になると、CP機能である AnyConnectの接続管理の他、Failoverや VPNロードバランシング管理、SSH/Telnet/Console操作、ロギングやSNMP処理など、広範な機能の遅延や処理失敗、不安定化といった深刻な問題の原因につながります。

CP処理は、ASAの頭脳部にあたるため、ASAの安定性を高く保つには、CP負荷は低く抑えることが重要です。CP処理負荷は、高くとも 30~40%以下に抑えることをお勧めします。

ASA# show cpu usage
CPU utilization for 5 seconds = 9%; 1 minute: 7%; 5 minutes: 6%

ASA# show cpu detail

Break down of per-core data path versus control point cpu usage:
Core         5 sec              1 min              5 min
Core 0       27.1 (2.6 + 24.4)  16.7 (2.6 + 14.1)  14.9 (2.5 + 12.5)
Core 1        3.2 (3.2 +  0.0)   3.3 (3.3 +  0.0)   3.1 (3.1 +  0.0)
Core 2        4.0 (4.0 +  0.0)   3.5 (3.5 +  0.0)   3.2 (3.2 +  0.0)
Core 3        3.0 (3.0 +  0.0)   3.3 (3.3 +  0.0)   3.2 (3.2 +  0.0)
Core 4       25.5 (2.8 + 22.6)  16.3 (2.7 + 13.6)  14.5 (2.5 + 12.0)
Core 5        3.2 (3.2 +  0.0)   3.2 (3.2 +  0.0)   3.0 (3.0 +  0.0)
Core 6        3.6 (3.6 +  0.0)   3.4 (3.4 +  0.0)   3.2 (3.2 +  0.0)
Core 7        3.0 (3.0 +  0.0)   3.2 (3.2 +  0.0)   3.1 (3.1 +  0.0)
Core 8       24.0 (3.0 + 21.0)  16.3 (2.7 + 13.6)  14.7 (2.6 + 12.2)
Core 9        3.8 (3.8 +  0.0)   3.2 (3.2 +  0.0)   3.1 (3.1 +  0.0)
Core 10       3.6 (3.6 +  0.0)   3.3 (3.3 +  0.0)   3.1 (3.1 +  0.0)
Core 11       2.8 (2.8 +  0.0)   3.2 (3.2 +  0.0)   3.0 (3.0 +  0.0)
Core 12      27.3 (2.4 + 24.8)  16.2 (2.5 + 13.7)  14.7 (2.5 + 12.3)
Core 13       3.6 (3.6 +  0.0)   3.3 (3.3 +  0.0)   3.1 (3.1 +  0.0)
Core 14       4.0 (4.0 +  0.0)   3.3 (3.3 +  0.0)   3.2 (3.2 +  0.0)
Core 15       3.2 (3.2 +  0.0)   3.4 (3.4 +  0.0)   3.2 (3.2 +  0.0)

ASA# show process cpu-usage sorted non-zero

Hardware:   ASA5585-SSP-40   
Cisco Adaptive Security Appliance Software Version 9.x(x)x
ASLR enabled, text region xxxxxxxxx-xxxxxxxxxx
PC         Thread       5Sec     1Min     5Min   Process
0x00007f5a311dfd8c   0x00007f59f813e640     5.3%     3.2%     2.8%   Unicorn Proxy Thread  <---
   -          -         0.3%     0.2%     0.2%   DATAPATH-2-2622
   -          -         0.3%     0.2%     0.2%   DATAPATH-14-2634
   -          -         0.2%     0.2%     0.2%   DATAPATH-9-2629
0x00007f5a30bc780d   0x00007f59f8166440     0.2%     0.0%     0.0%   ssh    <---
   -          -         0.2%     0.2%     0.2%   DATAPATH-6-2626
   -          -         0.2%     0.2%     0.2%   DATAPATH-10-2630
   -          -         0.2%     0.2%     0.2%   DATAPATH-13-2633
   -          -         0.2%     0.2%     0.2%   DATAPATH-1-2621
   -          -         0.2%     0.2%     0.2%   DATAPATH-5-2625
   -          -         0.2%     0.2%     0.2%   DATAPATH-15-2635
   -          -         0.2%     0.2%     0.2%   DATAPATH-7-2627
   -          -         0.2%     0.2%     0.2%   DATAPATH-8-2628
   -          -         0.2%     0.2%     0.2%   DATAPATH-3-2623
   -          -         0.2%     0.2%     0.2%   DATAPATH-4-2624
   -          -         0.2%     0.2%     0.2%   DATAPATH-0-2620
   -          -         0.2%     0.2%     0.2%   DATAPATH-11-2631
   -          -         0.2%     0.2%     0.2%   DATAPATH-12-2632

CP処理の過負荷、多くの場合、誤設定や、セッション数が膨大な状態で 過剰な機能や設定の利用が原因です。利用機能や設定見直しと、適宜機能や設定の削減や無効化で改善できるケースが多いです。

見直しをしても、セキュリティポリシー上 必要な機能や設定で削減が難しいなどの理由により、CP負荷が下がらず CP過負荷により問題が引き起こされる場合は、機器の増設を行い、通信や処理を分散し、CP処理負荷を分散する検討が必要です。 例えば、1台でAnyConect終端をしていたのを、2台で分散しAnyConnect終端にすることで 実質 CP処理能力は約2倍になります。

なお、CP過負荷のシナリオの場合、上位機種へのアップグレードでの CPパフォーマンス改善効果は限定的です。どのモデルもその筐体あたりのCP処理能力は1コアに限られるためです。

 

VPNセッション数の確認

VPNセッション数の確認と 適正なセッション数の維持が重要である理由は幾つかありますが、最も重要なことは、VPNセッション数が増えればふえるほど、接続ユーザ間でVPNスループットは共用されるため、1ユーザあたりの利用可能なスループットが低下することです。業務にストレスのないスループットを提供できるのが好ましいのですが、VPNアクセスが集中し利用者が増えた場合、その分 1ユーザあたりの利用できるスループットは低下します。しかし、通常、アクセスが極度に集中する条件下でも、各接続ユーザに、遅延やストレスは感じても、業務を遂行するうえで最低限必要なスループットを提供する必要があります。

例えば、VPNスループットが 1Gbpsの製品を利用時、"ストレスなく業務ができる快適なスループットが 10 Mbps以上"、"何とか業務ができる最低限必要なスループットが1 Mbps以上"の場合、同時接続数は 前者が100名まで、後者は1000名までに抑えたほうがいいと考えることができます。(実際は、多数の接続を収容すると、その処理のオーバーヘッドがASAに追加発生するため、数割はASAのパフォーマンス余力を残しておくと良いです。)

また、VPNセッション数が増えるほど、その新規VPNセッション処理負荷や 同時VPNセッション数の管理処理が必要となり、ASAのCPU負荷増加要因となります。

また、同時接続数が増えると、その利用モデルのVPN接続数の上限に達してしまう可能性があります。最大VPN接続可能数に到達した場合、それ以降の新規接続は拒否されます。想定以上の接続数がある場合は、どこから接続があるのか調査と、適宜接続の切断や分散、ASA増設が必要になるかもしれません。
 

現在のVPNセッション数や ピーク時のセッション数、利用機器のキャパシティなどの確認は、show vpn-sessiondb summary コマンド で可能です。以下例の場合、VPNセッション数(Total Active and Inactive)が4つ、利用機器の最大アクセス可能数(Device Total VPN Capacity)が 250 であるため、VPNセッション数の使用率(Device Load)は 2% であることがわかります。

ASAv10(config)# show vpn-sessiondb summary
---------------------------------------------------------------------------
VPN Session Summary
---------------------------------------------------------------------------
                               Active : Cumulative : Peak Concur : Inactive
                             ----------------------------------------------
AnyConnect Client            :      3 :         36 :           4 :        1
  SSL/TLS/DTLS               :      3 :         36 :           4 :        1
Clientless VPN               :      0 :          2 :           2
  Browser                    :      0 :          2 :           2
---------------------------------------------------------------------------
Total Active and Inactive    :      4             Total Cumulative :     38
Device Total VPN Capacity    :    250
Device Load                  :     2%
---------------------------------------------------------------------------

 

Active データを交換中のアクティブセッションの接続数
Cumulative 過去含めたアクティブセッションの総和 (切断済み含む)
Peak Concur アクティブセッションのピーク時の接続数
Inactive データ交換できない非アクティブなセッション数
Total Active and Inactive トータルのVPN接続数
Device Total VPN Capacity 利用デバイスのVPN接続の最大収納可能数

 
Active数を確認することで、データ交換中のセッションがどの程度 現在あるか確認できます。 Peak Concurを確認することで、ピーク時の AnyConnect 接続数を確認できます。

VPNセッション数のより詳しい確認の仕方や、SNMPポーリングでの監視方法については、以下ドキュメントを参照してください。

   

トラフィック量と平均パケットサイズの確認 

ASAの各インターフェイスのスループットや 平均パケットサイズは、show traffic コマンドで確認できます。

例えば、以下は、AnyConnect端末から ASA経由でファイルサーバーに、UDPで100バイトのデータを 23Mbps程の速度でアップロード時の show traffic コマンドの出力例です。データ転送に DTLS (デフォルト) を利用しています。

ASA-AnyConnect-performance-best-practice-show-traffic.JPG

ASAv10# show traffic
outside:
        received (in 764949.640 secs):
                58046368 packets        8402724238 bytes
                2 pkts/sec      10002 bytes/sec
        transmitted (in 764949.640 secs):
                37863434 packets        46137328134 bytes
                4 pkts/sec      60005 bytes/sec
      1 minute input rate 23069 pkts/sec,  5005932 bytes/sec
      1 minute output rate 2 pkts/sec,  1349 bytes/sec
      1 minute drop rate, 0 pkts/sec
      5 minute input rate 100 pkts/sec,  111376 bytes/sec
      5 minute output rate 1 pkts/sec,  1307 bytes/sec
      5 minute drop rate, 0 pkts/sec
dmz:
        received (in 764949.640 secs):
                42560852 packets        43254954890 bytes
                5 pkts/sec      56001 bytes/sec
        transmitted (in 764949.640 secs):
                57972736 packets        3845145682 bytes
                2 pkts/sec      5004 bytes/sec
      1 minute input rate 16 pkts/sec,  2092 bytes/sec
      1 minute output rate 23075 pkts/sec,  2953414 bytes/sec
      1 minute drop rate, 0 pkts/sec
      5 minute input rate 7 pkts/sec,  1545 bytes/sec
      5 minute output rate 100 pkts/sec,  102823 bytes/sec
      5 minute drop rate, 0 pkts/sec
  平均スループット (bps) 平均パケットサイズ (bytes)
計算式 ( [input bytes/sec] + [output bytes/sec] ) x 8 ( [input bytes/sec] + [output bytes/sec] )
  ÷ ( [input pkts/sec] + [output pkts/sec] )
Outside側
(DTLS暗号通信)
(5005932+1349) x 8 = 40,058,248
 = 約40Mbps
(5005932+1349) ÷ (23069+2 )
 = 217 bytes
DMZ側
(実通信)
(2092+2953414) x 8 = 23,644,048
 = 約23Mbps
( 2092 + 2953414 ) ÷ ( 16 + 23075 )
 = 127 bytes

上記例の場合、DMZ側 (ファイルサーバー側) は、約23Mbps のトラフィックがあり、平均パケットサイズが 127 bytes であることが、show traffic コマンドからもわかります。また、やり取りする平均パケットサイズが小さい場合、23Mbpsのスループットを得るのに、毎秒 2万3000近くの膨大なパケット交換が必要になることがわかります。処理パケット数が多いほど、ASAとAnyConnect端末 双方に、DTLS暗号化や複合化や処理の手間がかかり、各機器のCPU負荷アップとパフォーマンス低下の原因となります。

Outside側 (インターネット側) は、DTLS暗号化のオーバーヘッドにより、トラフィックが約17Mbps増えており、平均パケットサイズも90バイト 増えていることがわかります。特にやり取りするパケット数が増え、かつ 各パケットサイズが小さくなるほど、回線帯域に占めるDTLSのオーバーヘッド分が増加し、回線帯域を圧迫することになります。

なお、上記はデータ転送に、軽快な「DTLS」を利用時のデータとなります。 仮に経路でUDP443の通過が許可されておらずデータ転送に「TLS」(=TCP443)が利用された場合は、「TLS」はTCPベースのため確認応答やフロー制御などの処理と追加パケットがAnyConnect端末とASA間で増えます。つまり、「TLS」を利用した場合は、回線のオーバーヘッドや AnyConnect端末とASA間のパケット数とその処理負荷がさらに増え、回線や ASA/AnyConnect端末の各パフォーマンス低下の原因となります。「TLS」は低速なため、リモートアクセスVPNのパフォーマンスを最大化するには、「DTLS」をメイン利用し、「TLS」利用するAnyConnect端末は必要最小限にするのがお勧めです。

     

暗号処理エンジンの負荷確認 (ハイエンドモデルのみ)

暗号処理エンジンのチューニングに対応したハイエンド機を利用時、"show crypto accelerator load-balance ssl"コマンドで、暗号処理用の各エンジンや そのコアの処理負荷バランシング状況を確認できます。各エンジンやコアが分散し処理することで、暗号処理性能を高めています。上位モデルほど暗号処理用のエンジンやコア数が増えます。

例えば以下は、ASA5555とAnyConnect端末間で DTLSセッションを1つ貼り、高負荷通信を発生時のログ例です。ASA5555は暗号処理エンジン (Engine 0)を1つ持ち、暗号コア (Crypto Cores) は 8個あり、そのうち 1個が IPsec用に、7個がSSL処理用に割り当てられていることがわかります。また、SSL処理用に割り当てられた中の Core 7が、そのDTLSセッションの暗号関連の処理を実施中である事を確認できます。

ASA5555(config)# show crypto accelerator load-balance ssl


                  Crypto SSL Load Balancing Stats:
                  ==================================

Engine      Crypto Cores             SSL Sessions            Active Session
                                                             Distribution (%)
======     ==============      ===========================   ================
  0        IPSEC 1, SSL 7      Total:   182  Active:     6         100.0%

    --- 略 ---

Encrypted Data           1 second         5 second         60 second
==================       ========         ========         =========
 Core 1   (load)            0.0%             0.0%             0.0%
 Core 2   (load)            0.0%             0.0%             0.0%
 Core 3   (load)            0.0%             0.0%             0.0%
 Core 4   (load)            0.0%             0.0%             0.0%
 Core 5   (load)            0.0%             0.0%             0.0%
 Core 6   (load)            0.0%             0.0%             0.0%
 Core 7   (load)          100.0%           100.0%            99.9%  <--- This

通常、"crypto engine accelerator-bias ssl" コマンドで 暗号エンジンのSSL処理最適化を実施すると、IPSEC : SSL のコア割当比率が 1 : 7 になります。 コアの割当割合が 当比率でない場合、"crypto engine accelerator-bias ssl" コマンドが有効でない可能性があります。 SSL/DTLSでのAnyConnect終端が殆どの場合の環境の場合、"crypto engine accelerator-bias ssl" コマンドを有効化しないと、暗号エンジンの処理能力不足がボトルネックとなり、SSL/DTLSのASAの暗号処理の最大パフォーマンスが出ませんので注意してください。

crypto engineの最適化コマンドの設定状況は"show run crypto engine"コマンドでも確認でき、当コマンドの出力がない場合は、暗号処理エンジンのコア割当てがデフォルト値 (つまり、ASA5500/5585系の場合はIPsec優先、FPR4100/9300系の場合はBalanced)の可能性があります。

ASA5555# show run crypto engine
crypto engine accelerator-bias ssl

 

 

よくある質問

AnyConnectソフトウェアのダウンロード方法を教えてください

以下URLよりダウンロード可能です。
https://software.cisco.com/download/home/286281283/type/282364313/release/4.8.03036

AnyConnectソフトウェアのバージョンアップ方法は以下ドキュメントも参考にしてください。

なお、ソフトウェアのダウンロードには、利用のアカウントが適切な契約に紐づいている必要があります。アカウントの作成や契約紐づけ方法については以下ドキュメントを参照してください。

    
 

AnyConnectを利用したいが、手持ちのASAは 2つしかVPN終端できません

ASA5505やASA5500-Xシリーズの場合、AnyConnectライセンスのActivation-keyをハードウェアに有効にしてない場合、リモートアクセスVPN終端可能数は、シングル構成の場合は最大2つまで、冗長構成の場合は最大4つまでに制限されます。

AnyConnectライセンスを購入しているのに当制限がある場合は、以下ドキュメントを参考に対象機のアクティベーションキーの発行と有効化をしてください。 4週間のトライアルライセンスの申請も以下ドキュメントを参考に可能です。

AnyConnectライセンスをお持ちでない場合で 、コロナウィルス (COVID-19) の対策の一環で 急ぎAnyConnectの利用が必要時は、以下ドキュメントを参考に、デフォルトの接続数制限を 最大13週間 解除できます。当申請は2020年7月1日まで可能です (2020年4月現在)。なお、13週間を越えて継続利用を希望時は、AnyConnectライセンスの購入と再適用が必要です。

緊急ライセンス発行時も同様に発行したActivation Keyの機器への適用手順は以下ガイドを参考ください。

制限が解除されると、show versionで確認できるリモートアクセスVPNの終端可能数が その利用ハードウェアの最大値まで解放されます。以下は AnyConnect Plus/Apex(ASA) Demo License and Emergency COVID-19 License を実際に適用後の出力例です。

ASA5516# show version

Cisco Adaptive Security Appliance Software Version 9.12(3)9
SSP Operating System Version 2.6(1.192)
   --- 略 ---
Licensed features for this platform:
Maximum Physical Interfaces       : Unlimited      perpetual
Maximum VLANs                     : 150            perpetual
Inside Hosts                      : Unlimited      perpetual
Failover                          : Active/Active  perpetual
Encryption-DES                    : Enabled        perpetual
Encryption-3DES-AES               : Disabled       perpetual
Security Contexts                 : 2              perpetual
Carrier                           : Disabled       perpetual
AnyConnect Premium Peers          : 300            91 days
AnyConnect Essentials             : Disabled       perpetual
Other VPN Peers                   : 300            perpetual
Total VPN Peers                   : 300            perpetual
AnyConnect for Mobile             : Enabled        91 days
AnyConnect for Cisco VPN Phone    : Enabled        91 days
Advanced Endpoint Assessment      : Enabled        91 days
Shared License                    : Disabled       perpetual
Total TLS Proxy Sessions          : 1000           perpetual
Botnet Traffic Filter             : Disabled       perpetual
Cluster                           : Disabled       perpetual
VPN Load Balancing                : Enabled        perpetual

なお、上記例のように Encryption-3DES-AES がDisableの場合だと、AnyConnectで利用するAESが使えないため、別途 Product License Registration の、Licenses > Get Licenses > IPS, Crypto, other.. から Cisco ASA 3DES/AES Licensesを検索・選択してアクティベーションキーを発行した後、同様の手順でデバイスに そのキーを適用すれば、Encryption-3DES-AESの制限解除が可能です。

緊急ライセンスはタイムベースライセンスとなります。AnyConnectライセンスを購入し適用するライセンスは永続有効です。 2つ同時に適用した場合は、タイムベースライセンスの期限が消えた後に、永続ライセンス利用に自動で切り替わります。

 

購入しているAnyConnectライセンス ユーザ数以上 接続すると切断されますか

いえ、その終端しているASAの最大接続数までAnyConnect接続は可能です。ただし、契約ユーザ数以上の利用はライセンス違反となりますため、お持ちのAnyConnectライセンス ユーザ数以上の利用が見込まれる場合は、ライセンスの追加購入をお願いいたします。 

  

各モデルの最大接続可能数を超える接続は可能ですか

上限を超える接続は拒否されます。そのため、同時接続可能数は余裕をもった機器の選定が推奨されます。リモートアクセスVPNを利用する端末に比べ同時接続可能数が足りない場合は、アップグレードや ASA増設といった構成変更を検討してください。

 

多数の同時接続が発生し、アドレスプールの割当IPが不足した場合 どうなりますか

AnyConnect接続後の Address Poolの IPアドレスが足りない場合、以下のようなシスログメッセージがASA側で出力され、AnyConnect接続は失敗します。アドレスプールは余裕をもって設定するようにしてください。

%ASA-3-722020: TunnelGroup tunnel_group GroupPolicy group_policy User user-name IP IP_addressNo address available for SVC connection

 
 

show vpn-sessiondb detail コマンドで確認できる Parent-Tunnel とはなんでしょうか

Parent-Tunnelは特殊なトンネルで、初回接続時の情報交換や、Reconnectのための制御、AnyConnectイメージのアップグレードなどの用途で利用されます。

 

AnyConnectの終端に FTDも利用可能ですか

はい、FTDでも AnyConnectのリモートアクセスVPNの終端は可能であり、本ドキュメント情報の一部もパフォーマンス最適化に活用可能です。 しかし、FTDは利用可能なAnyConnect 機能は制限されています。例えば、FTDの場合 ローカルユーザデータベースによる認証に対応していないため、外部の認証サーバが必要です。また、FTDの場合、SplitTunnelやHostscan、DAP、VPNロードバランシング機能に対応してません。FTD利用時の制限について詳しくは以下ガイドも参照してください。

逆に、ASAを利用時の場合は、AnyConncetのフル機能をサポートし、本ドキュメントに記載の様々なチューニングやパフォーマンス最適化が可能です。

なお、FTDも 2021年春にリリース予定の FTD バージョン 7.0から、ASAとほぼ同等のAnyConnect機能が利用可能となる予定です。

 

AnyConnect端末のVPN速度を上げるにはどうすればよいですか

CPUやメモリ、NIC I/Oなどのパフォーマンスに優れる端末を利用、かつ その端末が利用する回線や通信経路の伝送速度や品質が良いこと、かつ DTLSを利用時に、良好なパフォーマンスを得やすくなります。

また、無線経由でインターネット接続よりも、有線LAN経由でのインターネット接続の方が、AnyConnect端末のVPN速度は良好の結果を得やすくなります。

 

AnyConnect端末のスループットが 最大100Mbps程度しか出ません

ASA側で十分なVPN処理性能があるのに 端末側でスループットが出ないのは、多くの場合、端末性能や、通信経路の速度や品質、通信方式(TLSを利用してる、など)の影響です。端末のコアのCPU使用率が高くないか確認してください。

なお、各AnyConnect端末の最大速度が低い方が、AnyConnect端末が同時接続したときの合計スループットが下がるため、ASA側の負荷は低くなります。

また、通常、テレワークの場合、"各端末の速度を最大限あげる"よりも、"各端末が業務を遂行する上で (最低限 必要な) 問題ないスループットを確保する"ことのほうが、より重要です。

 

AnyConnectの Compression機能の利用でパフォーマンスは向上しますか

Compression機能はとても古い機能となり、低速なWAN回線での利用を想定した技術です。2020年 現在、主流な高速なインターネット回線の利用下では、当機能は利用しません。高速な回線でCompressionを利用すると、圧縮処理により遅延発生や速度低下など トラブルの原因となります。そのため、エンジニアからの指示やサポートなしに、Compression機能の有効化はしないでください。及び、当機能はデフォルト無効です。

 

ASAv以外でもDTLSv1.2利用でパフォーマンスは向上しますか

期待は可能ですが、物理アプライアンスは通常 独自の暗号エンジンを搭載しており ASAvとはアーキテクチャが異なります。そのため、ASAvほど大きなパフォーマンス向上は期待できない可能性もあります。また、ASA5506/5508/5516の場合、プラットフォームの制限により DTLSv1.2には対応してません (機能拡張要求: CSCvn63389)。また、パフォーマンスやご利用のモデルや利用設定/機能などによっても変動しますので、必要に応じて、ご利用環境に応じた事前の検証をお勧めします。

 

AnyConnectの自動調整されたMTUの確認方法を教えてください

debug webvpn anyconnect を有効にした状態で AnyConnect接続することで確認が可能です。以下はデバッグ出力例の抜粋です。

ASA5555# show run logging
logging enable
logging timestamp
logging buffer-size 100000
logging buffered errors
logging debug-trace
logging message 711001 level alerts
ASA5555#
ASA5555# debug webvpn anyconnect
INFO: 'logging debug-trace' is enabled. All debug messages are currently being redirected to syslog:711001 and will not appear in any monitor session
INFO: debug webvpn anyconnect enabled at level 1.
ASA5555#
   --- AnyConnect接続 開始 ---
ASA5555# show log
   --- 略 ---
Apr 05 2020 18:23:17: %ASA-1-711001: Iphdr=20 base-mtu=1500 def-mtu=1500 conf-mtu=1406
Apr 05 2020 18:23:17: %ASA-1-711001: tcp-mss = 1460
Apr 05 2020 18:23:17: %ASA-1-711001: path-mtu = 1460(mss)
Apr 05 2020 18:23:17: %ASA-1-711001: TLS Block size = 16, version = 0x303
Apr 05 2020 18:23:17: %ASA-1-711001: mtu = 1460(path-mtu) - 0(opts) - 5(ssl) - 16(iv) = 1439
Apr 05 2020 18:23:17: %ASA-1-711001: mod-mtu = 1439(mtu) & 0xfff0(complement) = 1424
Apr 05 2020 18:23:17: %ASA-1-711001: tls-mtu = 1424(mod-mtu) - 8(cstp) - 48(mac) - 1(pad) = 1367
Apr 05 2020 18:23:17: %ASA-1-711001: DTLS Block size = 16
Apr 05 2020 18:23:17: %ASA-1-711001: mtu = 1500(base-mtu) - 20(ip) - 8(udp) - 13(dtlshdr) - 16(dtlsiv) = 1443
Apr 05 2020 18:23:17: %ASA-1-711001: mod-mtu = 1443(mtu) & 0xfff0(complement) = 1440
Apr 05 2020 18:23:17: %ASA-1-711001: dtls-mtu = 1440(mod-mtu) - 1(cdtp) - 48(mac) - 1(pad) = 1390
Apr 05 2020 18:23:17: %ASA-1-711001: computed tls-mtu=1367 dtls-mtu=1390 conf-mtu=1406
Apr 05 2020 18:23:17: %ASA-1-711001: DTLS enabled for intf=2 (outside)
Apr 05 2020 18:23:17: %ASA-1-711001: tls-mtu=1367 dtls-mtu=1390
Apr 05 2020 18:23:17: %ASA-1-711001: SVC: adding to sessmgmt
Apr 05 2020 18:23:17: %ASA-1-711001: Sending X-CSTP-DNS: xx.xx.xx.xx
Apr 05 2020 18:23:17: %ASA-1-711001: Sending X-CSTP-DNS: xx.xx.xx.xx
Apr 05 2020 18:23:17: %ASA-1-711001: Sending X-CSTP-Split-Include msgs: for ACL - TEST-split-tunnel-acl: Start
Apr 05 2020 18:23:17: %ASA-1-711001:     Sending X-CSTP-Split-Include: 1.0.0.0/255.0.0.0
Apr 05 2020 18:23:17: %ASA-1-711001: Sending X-CSTP-MTU: 1367
Apr 05 2020 18:23:17: %ASA-1-711001: Sending X-DTLS-MTU: 1390
Apr 05 2020 18:23:17: %ASA-1-711001: Sending X-DTLS12-CipherSuite: ECDHE-ECDSA-AES256-GCM-SHA384

    

ASAのVPNスループットがデータシート通りに出ません

2020年現在リリースのASAは殆どがマルチコアモデルとなり、複数のコアで分散し処理することで処理能力向上を行っています。シングルフローで試験している場合、一部のコアしか使われないため、処理速度は制限されます。特に上位のモデルになるほど搭載コア数も増えるため、そのASAの処理性能を最大限引き出すには、数十~数百のAnyConnect接続が必要です。しかし、最大のVPNパフォーマンスを期待可能な数十~数百の接続数を越え、さらに同時接続数が増えればふえるほど、ASAはその多数VPNセッションの管理処理にもCPU処理能力を使う必要がでてくるため、ASAの総VPNスループットは非常に緩やかにはですが低下していく傾向にあります。

また、VPNスループットは、送信(tx)と受信(Rx)の和となります。例えば、TCP通信の場合、端末がASA経由でファイルをダウンロード(=Rx)中も、端末からASAに受信の確認応答(ACK)の通信(=Tx)も ある程度発生します。送信と受信の両方とも100MbpsのPerformance を得たい場合は、VPNスループットが200Mbps以上のモデルの選定が必要です。

トンネルプロトコルは、DTLS Tunnel (=UDP 443) を極力 利用するようにしてください。DTLS v1.2を利用することで、パフォーマンスの最大化が可能です。TLS Tunnel (=TCP 443)はフロー制御や確認応答の追加処理が発生するため、TLS Tunnelの多用は ASA自身とAnyConnect端末双方のパフォーマンス低下の原因になります。例えば、AnyConnectのリモートアクセスVPN接続を全てTLSで終端した場合、全てDTLSで終端する場合に比べ、ASAのVPNパフォーマンスが 3割ほど落ちる可能性があります。また、TLSを多用した場合、TCPの特性上 WAN側に確認応答のための多数パケットが追加発生するため、WANの経路装置のパケット転送処理負荷の増大の原因となります。

ハイエンドモデルで AnyConnectの DTLS/TLS 接続のみを行う場合は、crypto engine accelerator-bias ssl コマンドの事前有効化を行ってください。当コマンドを有効化しないと、暗号エンジンの処理能力不足がボトルネックとなり、SSL処理の最大Performance は出ません。暗号エンジンの処理能力不足が発生すると、CPU負荷は高くないのに 一定以上 暗号スループットが出ない問題が発生する原因となります。

ASAvを利用時は、ASAバージョン 9.12以降 と AnyConnect バージョン 4.7以降、かつ 性能の高い新しいサーバやCPUにASAvをデプロイし、DTLSトンネルを利用することで、良好な結果を期待できます。また、ASAvを利用時は ASAvがCPUやメモリのリソースをほぼ占有できる状態である事を確認してください。また、VMwareの場合、割り当てるネットワークアダプタの アダプタタイプが VMXNET3や IXGBE-VFの場合 良好なパフォーマンスを期待できます。ネットワークアダプタタイプがE1000の場合、パフォーマンスが十分にでないケースがあります。

また、データシートに記載のデータは、最低限のシンプルな設定での試験結果がベースです。機器の機能や設定がシンプル(ほぼデフォルト状態で最低限な設定)な場合に比べ、機能や設定を有効化後の Performance に差分がある場合は、その差分は利用機能や設定・環境などの影響により Performance が低下したと考えることができます。

また、データシートに記載の VPN throughput は、多くの場合、UDP 450 bytes利用の通信時が目安です。利用のネットワークで平均パケットサイズが450 bytesより小さい場合、データシートよりも VPN throughput が下がる可能性があります。各インターフェイスの平均パケットサイズは show traffic コマンドから確認できます。ショートパケットが多いネットワークの場合、よくある問題としては、利用しているアプリケーションの通信方式や挙動が原因のケースです。例えば、NFS、SMB、仮想デスクトップ (VDI) などのアプリケーションは、ショートパケットや確認応答が比較的多く、多数のパケットが発生するため経路の通信機器パフォーマンスを下げることがあります。対策としては、アプリケーション側で一度に送付するパケットデータサイズを増やしたり、確認応答の頻度を少なくするなど改善すること (もしくは そのような通信効率の良いアプリケーション利用に切り替えること) ですが、一般的に、アプリケーションの通信方式をすぐに改修(もしくは機能拡張)や切り替えることは難しいことが多いです。なお、Office 365 など クラウド型のアプリケーションの場合は、スプリットトンネルで直接クライアントからクラウドにアクセスさせ、ショートパケットをVPNに流さない方法も、VPNパフォーマンスを高く保つために有効な方法の1つです。

特にビジネスクリティカルな環境の場合や、多数機能や設定の利用を想定されている場合、TLSトンネルのみしか利用できない場合、ショートパケットの多い社内アプリケーションを多用してる環境などでは、机上の必要なVPNスループットよりも 更にVPNスループットの処理能力の高い、十分な処理能力の余力のある ASAの選定と導入をお勧めします。

 

AnyConnectの各セッションのQoSは可能ですか

残念ながら対応してません。Tunnel-groupのQoSを設定しようとした場合、以下のようにエラーとなり設定できません。

ASAv10# show ver | in Ver
Cisco Adaptive Security Appliance Software Version 9.12(3)9
SSP Operating System Version 2.6(1.192)
Device Manager Version 7.13(1)
ASAv10(config)#
ASAv10(config)# tunnel-group a1 type webvpn
ASAv10(config)# tunnel-group a1 webvpn-attributes
ASAv10(config-tunnel-webvpn)#  class-map c1
ASAv10(config-cmap)#  match tunnel-group a1
ASAv10(config-cmap)# match flow ip destination-address
ASAv10(config-cmap)# policy-map p1
ASAv10(config-pmap)# class c1
ASAv10(config-pmap-c)#  police output 100000

ERROR: tunnel with WEBVPN attributes doesn't support police!
ASAv10(config-pmap-c)#

また、QoSの利用は 機器の負荷につながります。 そのため、何等か理由でAnyConnect端末のトンネル経由でのダウンロード速度を制限したい場合は、接続先のファイルサーバでダウンロード速度や同時ダウンロード数の制限や、AnyConnect端末に割り当てられたIPアドレスやセグメントに対するQoSを経路の機器 (例えばASAを収容しているL3スイッチや経路の別機器) で行い、処理負荷を分散することが、システム全体のパフォーマンスを保つうえで有効です。

  

ASAでリモートアクセスVPN利用のための構成や設定例があれば教えてください

ご利用バージョンの設定ガイドの他、Secure Remote Worker SAFE Design Guide や、設定例ドキュメントの「リモートアクセスVPNサーバ 設定例 with AnyConnect」項などが参考になります。

 

パフォーマンス最適化のため推奨のAnyConnectバージョンはありますか

パフォーマンスやセキュリティ上、不具合修正や新機能追加の進んだ 最新のAnyConnectバージョンの利用が推奨されます。なお、AnyConnect バージョン 4.6以降を利用することで、高速なAES-GCMに対応した DTLS v1.2や、Dynamic Split Tunneling によるダイレクトクラウドアクセスが可能のため、ASAや端末のパフォーマンス改善に寄与します。

  

 

参考情報

COVID-19 準備のための AnyConnect 実装およびパフォーマンス/スケーリング参照
https://www.cisco.com/c/ja_jp/support/docs/security/anyconnect-secure-mobility-client/215331-anyconnect-implementation-and-performanc.html

AnyConnect ライセンスに関するよく寄せられる質問(FAQ)
https://www.cisco.com/c/ja_jp/support/docs/security/anyconnect-secure-mobility-client/200191-AnyConnect-Licensing-Frequently-Asked-Qu.html

AnyConnect VPN, ASA, and FTD FAQ for Secure Remote Workers
https://www.cisco.com/c/en/us/td/docs/security/asa/misc/anyconnect-faq/anyconnect-faq.html

VPN トラブルシューティング
https://community.cisco.com/t5/-/-/ta-p/3161734