Sign in
Microsoft.com
 
Microsoft
 
 
 
Microsoft >
> 
> 
Strange Problem: (Juniper) VPN + Internal Communication

Locked Strange Problem: (Juniper) VPN + Internal Communication

  • Wednesday, March 05, 2008 10:42 AM
     
     
    Sign In to Vote
    0
    Hey guys,

    we have a strange problem in our OCS-Topology:

    a) Without VPN, inside our intranet everything works just great (Audio/Video, Conferencing, LM, etc)
    b) One client using OpenVPN, one client connecting from the intranet: Works fine!
    c) One client using OpenVPN, one client using our SSL-VPN (Juniper): Works fine!
    d) Both clients using Juniper SSL-VPN: Does NOT work. It is possible to use instant messaging but you can't use PC-to-PC-Calls, neither audio nor video. We have so far not been able to resolve this issue. But we are pretty sure that we can rule out any routing or DNS problems.

    To get around this issue we have set up an Edge Server for testing purposes (and maybe production use later on but not for the moment), which gives us the following scenarios (yes i know, its not the purpose of an edge-server to be used over vpn!!):

    e) Both clients connected to SSL-VPN, edgeserver activated and running: Everything including audio/video conferencing works fine, BUT: "netstat -a" shows that both SSL-VPN clients are connected to the internal edgeserver interface. This is quite strange, isnt't it?
    f) Being connected just through the edgeserver, without VPN also seems to work using a manual configuration in OC as it should, even though we don't have any external DNS-SRV records configured (remember: the edgeserver is not yet for production use)

    So, how do we resolve the issues listed in scenario d) and e) while every other scenario works?

    Any suggestions would be greatly appreciated!


    Kind regards,

    Max Liebkies
       

    All Replies

    • Wednesday, March 05, 2008 5:25 PM
       
       
      Sign In to Vote
      0

      Without logs, network topology diagrams, understanding the OpenVPN config (and possibly packet captures via Netmon, Ethereal, etc) the problems with Scenario d) will be difficult to track down.

       

      Scenario e) is interesting. I would expect a P2P connection between the VPN clients (with no relay through internal edge of A/V edge server), as they are both inside your network via the VPN tunnel. 

       

      However, I am not convinced that the netstat test tells the complete story. I don't have an external user to test with quickly, but it's possible that the connection is simply open due to gathering candidate addresses during the ICE process (see below). 

       

      A packet capture would tell you much more, as that will show the (encrypted) media traffic over UDP. But there will be lots of it, easy to identify from the volume and protocol.

       

      The OC client/OCS servers uses ICE (Interactive Connectivity Establishment, see here for a nice overview from one of the chief architects) to identify the best address connection between endpoints. This is done through gathering a list of IP address candidates, testing connectivity to them, and using the highest priority candidate which passed the connectivity check. P2P connections between the local addresses are higher priority. A relay will only be used if the higher priority candidate addresses (local hosts addresses or addresses on the external side of a local NAT) fails. 

       

      If your clients end up using the internal edge of the Audio/Video Edge Server for media, that means there is some kind of failure in the connectivity check for the local host address' (the VPN provided IP address') between the two clients.

         
      • Thursday, March 06, 2008 9:37 AM
         
         
        Sign In to Vote
        0
        Hello DuncanBloome,

        thank you for your answer. So, what I will be trying next is doing a packet capture to track down the problem in d)

        This is really the scenario we have to solve. Solving scenario e) would be a nice side-effect but isn't necessary.

        After gathering some new information I will post again.

        Thanks again for your help!


        Kind Regards,

        Max
           
        • Friday, March 07, 2008 8:32 AM
           
           
          Sign In to Vote
          0
          Hello again,

          analysing some TCP streams it's clearly visible that the internal communication (both clients in the same subnet) uses P2P for audio/video.
          With edgeservers completely disabled: Having both users connected to the VPN, one client tries to contact the front-end but can't establish a P2P connection with the other client. When the communicator cancels the connection with "Disconnected..." (don't know the english error message, sorry) I get a single TCP out-of-order packet. That's really all I can see.

          Is there any way to circumvent this P2P-behaviour for specific subnets? Or is it just the way the OCS "does it"?

          Kind regards,

          Max