A problem analysis of an office site VPN login TSM

Publication Date:  2012-10-25 Views:  285 Downloads:  0
Issue Description
Some users feedback that after use VPN dialing into the intranet to make TSM Agent authentication, it will be forced to offline in a period of time. In the TSM server check the use's on-line records, find that the users IP is the same as 127.0.0.1. Due to the same IP can only have a user to be online, so the online users will be forced to offline.
Alarm Information
none
Handling Process
3 A.  use Layer 3 VPN access mode

Suggest that on the VPN Server configure VPN policy pointed to TSM Server, to TSM Server enable Layer 3 VPN access mode. That do not use SSL application layer VPN tunnel, but use Layer 3 VPN mode based on virtual network. In the terminal computer, TSM Agent can display that connect to the TSM Server, and get the only network communication IP address.
The specific configuration refer to VPN configuration manual.
4 B.  put the patch in TSM Server
As the IP address are all 127.0.0.1 that TSM Agent report to TSM Server, can in TSM Server end modify this IP to other IP by hand (as long as don't conflict), so it doesn't exist the Session confliction, leading to the user is kicked to offline problem.

Risk:
1. This method need to put patch;
2. As the terminal IP is still not correct, the push service TSM Server to TSM Agent will not become effective, such as involving the patch management service of FTP downloading.
3. This kind of VPN service model decide the server is unable to launch connection to client proactively, so can't support server active push function.
Root Cause
1 A information collection
Analysis the last TSM Agent collection terminal log, observing the network connection of two processes:

      Notice: the VPN client is as ActiveX control way to exist in the browser process.
Use netstat to check the network connection conditions (part) :

Proto    Local Address          Foreign Address        State                PID
  TCP    127.0.0.1:1912         127.0.0.1:4040         ESTABLISHED     1928  
  TCP    127.0.0.1:4040         127.0.0.1:1912         ESTABLISHED     3296

  TCP    127.0.0.1:4040         0.0.0.0:0              LISTENING                  3296

  TCP    192.168.1.2:1914       219.146.0.132:443      ESTABLISHED     3296
  TCP    192.168.1.2:1972       219.146.0.132:443      ESTABLISHED     3296
  TCP    192.168.1.2:2025       219.146.0.132:443      ESTABLISHED     3296
  TCP    192.168.1.2:2028       219.146.0.132:443      ESTABLISHED     3296
  TCP    192.168.1.2:2030       219.146.0.132:443      ESTABLISHED     3296
2 B  network connection analysis
VPN user TSM Agent is not directly connect to TSM Server, but make two routing transition, totally includes the following five steps.
Step 1: the user use VPN dial-up access intranet;
Step 2: TSM Agent send the authentication request message to TSM Server;
Step 3: TSM Agent message is intercepted by the VPN client (127.0.0.1). VPN client do not directly forward message to TSM Server, but encapsulate TSM Agent message into a SSL message again;
Step 4: VPN client send this message to SSL VPN Server (219.146.0.132);
Step 5: VPN Server resolve message, forwarding to TSM Server. TSM Server process the authentication request, reply the corresponding message.
From the above steps we can find that the problem is in Step 3, all the message that terminal computer send to the intranet will be intercepted by the VPN client, the source address is replaced to 127.0.0.1 by VPN. Therefore, as for TSM Agent, the received address is also 127.0.0.1, rather than the actual distribution NAT address 192.168.1.2.
When most of the VPN client set up VPN tunnel, will get the virtual IP address distributed by VPN Server, will not overlap. In this kind of VPN application, TSM Agent does not appear problem that all IP is 127.0.0.1.
Suggestions
none

END