QA@IT

http/httpsアクセス接続時の不具合

2665 PV

以下構成・情報にて何かわかりますでしょうか・・・?

検証時はLBが調達できなかったのでLBがない環境にて問題なくVPN接続できることを確認しておりますが
実際の環境ですとLBがある為、何か関係しているのではと考えています。
どこらへんが怪しいかだけでも教えてくれると助かります。

■要件
DMZに配置したCisco892にwebVPN(L7)を実装し、外部からhttp/httpsアクセスで
Cisco892jで認証し、VPN接続したい。

■論理構成

PC(外部) --- [Internet] --- LB --- FW --- Cisco892

PC=windowsXP/7 IEver8~10
LB=Link Proof180 ODS (radware) ※ロードバランサ
FW=SSG140
Cisco892j=IOS:15.2(4)M5

■事象
インターネット上のPCからCisco892JのVPN 用 I/Fアドレスにhttp/https接続した際に、WebVPNの認証画面が表示されない

■切分け
・PCのOSやIEverは上記の構成に記載したもので各確認済み。結果変わらず
・インターネット経由のPC→Cisco892Jへのping通信→OK
・インターネット経由のPC→Cisco892Jへのtelnetを使用した443/TCP接続→OK
・WebVPNの管理画面が表示されない場合、 TCP 接続開始直後にPC側からTCP RST が送信され接続が中断する

■Cisco893jでの取得ログ (A.A.A.AはCisco892jに割り当てたグローバルIPアドレスで、PCからアクセスしにいくアドレス。B.B.B.Bはvpnポートに割り当てたプライベートアドレス)
*May 16 21:14:44.647 JST: TCB87C5CBE0 created
*May 16 21:14:44.647 JST: TCP0: state was LISTEN -> SYNRCVD [443 -> A.A.A.A(1494)]
*May 16 21:14:44.651 JST: TCP: tcb 87C5CBE0 connection to A.A.A.A:1494, peer MSS 1024, MSS is 516
*May 16 21:14:44.651 JST: TCP: sending SYN, seq 2151684599, ack 2209800774
*May 16 21:14:44.651 JST: TCP0: Connection to A.A.A.A:1494, advertising MSS 536
*May 16 21:14:44.651 JST: tcp0: O SYNRCVD A.A.A.A:1494 B.B.B.B:443 seq 2151684599 OPTS 4 ACK 2209800774 SYN WIN 4128
*May 16 21:14:44.651 JST: tcp0: I SYNRCVD A.A.A.A:1494 B.B.B.B:443 seq 2209800774 RST WIN 0
*May 16 21:14:44.651 JST: TCP0: RST received, Closing connection
*May 16 21:14:44.651 JST: TCP0: state was SYNRCVD -> CLOSED [443 -> A.A.A.A(1494)]
*May 16 21:14:44.651 JST: TCB 0x87C5CBE0 destroyed

  • NAT, ACLの設定は問題ないですか? -
  • ACLはかけていません
    ping疎通確認もとれているのでNATも問題ない認識です
    -
  • opensslが使える端末があればですが、openssl s_client での接続は試されましたか?GET後同様に切断されるでしょうか。 -
  • opensslを使用する意図はどういった理由でしょうか?勉強不足で申し訳ないのですが、教えてください・・・
    -
  • 遅くなってごめんなさい、気づいていませんでした。opensslのs_clientを提案したのは単純にブラウザよりもクライアントログが参照しやすいという点だけです。telnet通信の場合つないでおしまいでしょうが、openssl s_clientであればヘッダも送ればコンテンツを取得できますので。 -
  • ちなみに最初に NATとACLを聞いたのは https://supportforums.cisco.com/thread/2076605 の内容に近いと感じたためです(残念ながら質問者がどう直したか示してくれてませんが)。当て推量ですが 443には届いているが他(例えば今回のログなら1494、wellknownじゃないので動的と思いますが)への通信ができるかどうかが気になりました。 -
  • 最近 TCP遅延ACKの設定がサーバーとLBで合ってなくて問題が起きるというのを経験しましたがログを見る限りそれではなさそうですね(400ms待ちなどがないので)。 -
ウォッチ

この質問への回答やコメントをメールでお知らせします。