locked
Office Communicator unable to connect through CISCO VPN

    Question

  • Hello, 

    Newly installed OCS 2007 server.  Works fine in the office but will not connect through Cisco VPN.  It times out and says the server is not available.  I removed the "fixup protocol sip 5060" line from the ASA as noted in a KB article to resolve this issue. No luck.  I am using TCP not TLS.  I can ping all DNS entries when connected to the VPN.  sip.domainname.com, sipinternal.domainname.com, and sipexternal.dmainname.com.  Does anyone have any idea what else I can look at.  I enabled the advanced logging for the Office Communicator client and I will try it out tonight to see if I can generate some more usefull information. 

    Thanks.
    Monday, September 15, 2008 8:53 PM

All replies

  • Communicator is not designed to work over VPN

    You should use an EDGE Server if you want users to connect via Internet

     

    Monday, September 22, 2008 4:21 PM
  • Try hardcoding your client to use the same name and port for both internal and external servers:

     

    go to tools->options->advanced

     

    select "manual configuration"

     

    Internal: sipinternal.domainname.com:5060

    External: sipinternal.domainname.com:5060

    Connect using: TCP

     

    By the way - why are you using TCP rather than TLS? It's not recommended or secure. If this is a production deployment, I'd look into getting the correct certs and using TLS.

     

    Regards,

    Matt

     

    Monday, September 22, 2008 4:40 PM
  • Deli's statement is misleading.  There is no inherent design aspect of Communicator that would cause it fail over a VPN.  Many customers do not allow applications to be accessible from the internet and therefore require VPN to access Communicator.  I could list a number of customers that are successfully using Communicator over various types of VPNs, and I have personally tested Communicator over a customer's Cisco VPN as recently as last month.

     

    Ping is a good first step but you should also test port connectivity.  Try telnet poolname.domain.com 5060.  If you get a blank screen then it was succesful.  Posting your Communicator log would also be helpful.

    Monday, September 22, 2008 4:43 PM
  • I have had others tell me OCS was not designed to work over VPN.  If that is the case why did MS write KB911786.  I have no need to open up my internal OCS to the world, just my laptop fleet when they are out of the office.  They already connect thrugh a VPN so why should I purchase another server and server license to alow this?  Doesn't matter.

    I am using TCP simply because I'm not familiar with TLS.  Can anyone recommend any documentation for deploying OCS with TLS?  I've read everythgin MS has to offer as far as documentation goes and in my opinion it leaves alot to be desired. 

    To answer some questions, I can ping everything by name when cnnected to the VPN.  Poolname.domainname.com and .local.  I have not yet tried to telnet to 5060 but I will try that tonight. 

    Thanks,
    Monday, September 22, 2008 7:39 PM
  • Hi,

    I echo Mike's message: OCS works with VPN for sure, end of story. However, the important point is that OCS was designed to be able to work without a VPN as well; that appeals to a lot of people. So if you already require a VPN, then fine and dandy, OCS will still work. However, many people would rather avoid having to use a VPN because it can be a costly solution. OCS gives you the flexibility to either use or not use a VPN.

     

    Now I will say that putting voice and video over a VPN connection does tend to decrease performance because the VPN connection has some network overhead and uses TCP, which is slower than UDP (OCS uses UDP for voice and video). So voice and video will probably perform slightly better without the VPN connection. But it will still work with it.

     

    As for TLS vs. TCP - TLS just is encrypted (Transport Layer Security) using SSL certificates. It still uses TCP, just with added security of SSL. All of the OCS 2007 deployment documentation refers to using TLS rather than just TCP. It does take extra effor to set up, but I think most people feel the extra time is worth it for the added security of having all traffic encrypted.

     

    Regards,

    Matt

     

    Monday, September 22, 2008 7:57 PM
  •  Bguilliams1000 wrote:
    I have had others tell me OCS was not designed to work over VPN.  If that is the case why did MS write KB911786.  I have no need to open up my internal OCS to the world, just my laptop fleet when they are out of the office.  They already connect thrugh a VPN so why should I purchase another server and server license to alow this?  Doesn't matter.

    I am using TCP simply because I'm not familiar with TLS.  Can anyone recommend any documentation for deploying OCS with TLS?  I've read everythgin MS has to offer as far as documentation goes and in my opinion it leaves alot to be desired. 

     

    That KB article specifically references an issue with some PIX firewalls and how they handle SIP over TLS.  Microsoft did not 'design' the TLS protocol, so publishing a technical bullentin is not confirmation of an inherent lack of design on their part.

     

    Also the Edge Server is used for more than just external client connections, without it you won't be able to take advantage of Federation or Public IM connecitivty either.  If those features are not required, and you don't have one of the 'bad' PIX firewalls then you can certain get some functionailty for remote users via VPN.

    Monday, September 22, 2008 8:42 PM
  • Just to be clear, I did not state that it would not work over VPN

    It is just that you might experience problems because of the VPN / Firewall stuff

    Monday, September 22, 2008 9:37 PM
  • Thanks Matt & Jeff.  I couldn't have said it better myself. 

    Monday, September 22, 2008 11:41 PM
  • I think we've gotten a little side tracked.  I'm not arguing against the use of an Edge server in every scenario just in mine.  I have no need for one as I'm not planning to have any public IM connectivity at this time, etc, etc.  I simply need to be able to connect to an internal OCS server through a VPN.  I've gotten TLS working internally now so I'm going to try again through the VPN to see if it will function.  I may later decide an Edge server is the way to go if I start using more features if OCS.  I'm planning to test this afternoon so I will post the results.

    Thanks,

    Tuesday, September 23, 2008 3:48 PM
  • One thing to keep in mind on this topic is if one is using Automatic Configuration and where DNS lookups are directed during the VPN session.  Things like split-tunneling might impact what records are resolvable and could cause unwanted connections as the 'wrong' records are resolved by the client.  Just something to think about...

     

    Tuesday, September 23, 2008 9:35 PM
  • Can you try something for me the next time you VPN in... can you manually configure the Communicator client to point to the Pool FQDN (Or std edition FQDN if appropriate).  Then test connection.

     

    If that fails, then manually configure pointing to the IP address of the OCS server.  (TCP obviously until you get TLS setup)

     

    What will this do??  Point us to a DNS issue and narrow down the scope for sure.  Also any additional logging you can do would help.

     

    Wednesday, September 24, 2008 3:20 AM
  • Thanks for all the comments.  I resolved this last night.  The fix was to use the FQDN instead of the IP adress when setting the manual configuration.  I think it was tied to the certificate not having the IP address but only the FQDN.   Who knows.  In any case as soon as I changed this it started working. 
    Wednesday, September 24, 2008 12:59 PM
  • That would do it; the FQDN that the client uses must match the Subject Name of the attached certificate.  Using any different CNAME record or IP address would technically resolve and connect, but a certificate error would appear in client's the Application Event Log reflecting that.

     

    Wednesday, September 24, 2008 1:26 PM
  • So you were using TLS and not TCP?  Sorry I misunderstood then, I thought you were only using TCP.

     

    So next step is you will need to get automatic configuration working... manual config sucks and doe not allow you to be flexible.

     

    -Jay

     

    Friday, September 26, 2008 6:11 AM
  •  Deathjester wrote:

    So next step is you will need to get automatic configuration working... manual config sucks and doe not allow you to be flexible.

     

    -Jay

     

     

     

    Ok, I have to address this quite misleading statement.  Manual configuration does not 'suck' and there is nothing inherently wrong with it.  I see plenty of scenarios where Automatic Configuration cannot be leveraged due to either lack of DNS SRV support, LCS to OCS upgrades where both configuration types can be used to an advantage for migration group staging, or in environments that extensively use GPOs or third-party registry configuration solutions.  In fact it can be MORE flexible as SRV lookup records only allow for the use of a single pool per SIP domain, but a GPO could be used to assign seperate front-end pools for sign-in for users in different OUs in some non-standard scenarios.
    Friday, September 26, 2008 12:59 PM
  •  Jeff Schertz wrote:

    Ok, I have to address this quite misleading statement.  Manual configuration does not 'suck' and there is nothing inherently wrong with it.  I see plenty of scenarios where Automatic Configuration cannot be leveraged due to either lack of DNS SRV support, LCS to OCS upgrades where both configuration types can be used to an advantage for migration group staging, or in environments that extensively use GPOs or third-party registry configuration solutions.  In fact it can be MORE flexible as SRV lookup records only allow for the use of a single pool per SIP domain, but a GPO could be used to assign seperate front-end pools for sign-in for users in different OUs in some non-standard scenarios.

     

     

    Okay, my turn Smile

     

    So first off as it relates to the original poster's scenario, it absolutely would have prevented the issue he ran into by putting an IP address in the manual configuration.  And this was a mistake from someone fairly knowledgeable with OCS.  Now multiply that potential risk times X number of users who have a fraction of the OP's skills.

     

    While you are correct that there is a small portion of DNS scenarios that support SRV records, that scenario is getting smaller and smaller.  Again as it relates to the original poster's scenario, it would not apply as I assume they are using MS DNS.  Een if using a 3rd party DNS such as QIP, it is supported.

     

    In regards to LCS to OCS migrations... to me that is an even better scenario to use SRV records for auto-configuration.  First, if they are doing a rip and replace, then the FQDN would most likely be different.. from LCS01.company.com to OCS01.company.com for example.  Second, in an integration/migration scenario, you would want the automatic configuration mechanism to point users to OCS instead of LCS.

     

    In staging environments, not sure why that would matter as no matter which server you try to connect to, it will direct the user to the server they are homed on.  This "Director" function is inherent in every Std/EE pool, whether or not it is deployed as a dedicated "Director".

     

    While you are correct about a single SRV record per SIP namespace, again that has no relevance IMO, because again, if the SRV record points the user to LCS for example, and the user is homes on OCS, then the client will get redirected automatically to the correct server.

     

    Excellent point on GPO's, but to be honest, most administrators I deal with have ZERO control of GPO's or logon scripts.  In either script or GPO scenario, it usually takes much longer than putting in a request for a single DNS change.

     

    Assigning users to different pools based on OU is a rare occurance, but again, by rt clicking on the OU or multi-selecting all of the users in the OU, you can use the OCS user wiz to provision all the users to a particular pool with a few mouse clicks.  But honestly, what does that have to do with DNS resolution of a preferred OCS server?  No matter where they get sent initially on sign in, they will get routed to the correct server.

     

    So in summary, from my perspective it is much easier to change a single DNS entry, that it is to write/modify a script, get permissions for GPO additions, etc.  Keep it simple, and let OCS and DNS do it's thing.  Do you prefer to type in IP addresses into a web browser to get to your favorite webpage?  Not me, call me lazy, but I prefer to let DNS do it's thing Smile

     

    Thank you for the discussion!

    Jay

    Friday, September 26, 2008 7:02 PM
  • That is a MUCH better post and I cannot disagree with any of your points.  I simply balked at the previous "manual config sucks" statement with no details behind it as posts like that could potentially scare readers away from a possible solution, not to mention posts like that are not really a good contribution to the discussion and solutions.  Examples like above are much more welcome.

     

    And FWIW, I make the same recommendations to cleint regarding Automatic Configuration, as it's what Microsoft intended to be used in deployments and is the best solution for 90% of environments.  But manually controlling those settings has it's advantage as well in certain scenarios. For example it's handy to use for migrating pilot groups from LCS to OCS while not affecting the mass majority of users and then when a tipping point is reached in the migration process the SRV records and manual settings can be flip-flopped.

    Friday, September 26, 2008 7:35 PM