locked
Can 'external' lync 2013 clients connected to an 'internal' VPN maintain an 'external' connection? RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    I have a split DNS;  'internal' and 'external'

    I want the 'external' lync 2013 clients to stay connected externally while connected to the 'internal' network.

    When the 'external' laptops and desktops connect to the VPN we provide DNS services from our 'internal' DNS servers.

    Can I simply remove the IP address range of my VPN network from the Lync 2013 server so that VPN 'subnets' are not listed in my Office Site 'subnet'?, this would hopefully force the 'external' Lync client connected to the VPN to be connected as 'external' users.

    OR will the 'internal' DNS prevent the VPN users from connecting to the Lync 2013 'externally'?

    Thanks


    • Edited by chrisw-0079 Tuesday, September 23, 2014 3:17 AM
    Tuesday, September 23, 2014 3:17 AM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    When Connected to the PN if the DNS Records required for SIP and AV traffic point to the Lync edge server instead of the Lync front-end or director Server 

    And on the internal firewall for the VPN Subnet if you block The port for SIP communication 5061 this will work 

    Something similar what is being done for AV traffic in this article 

    http://blogs.technet.com/b/nexthop/archive/2011/11/15/enabling-lync-media-to-bypass-a-vpn-tunnel.aspx

    Please remember, if you see a post that helped you please click ;Vote As Helpful" and if it answered your question please click "Mark As Answer" Regards Edwin Anthony Joseph

    Tuesday, September 23, 2014 5:04 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Agree that this is possible, though a lot of it depends upon how your VPN setup acts.  If all traffic is forced through the VPN tunnel, even Internet traffic, and your firewall does not allow hairpinning, you might have some trouble.  If Internet traffic does not tunnel through the VPN, you might be OK.

    If you must present internal DNS to VPN users, it can get tricky.  If you can restrict access to the front end from the VPN subnet, and the internal DNS also returns external lookup records such as lyncdiscover and your external web services FQDN, you might be OK.  But the client if it has the ability to connect internally typically, and it's offered internal DNS records with full access to the front ends, it's going to connect internally. 

    Please remember, if you see a post that helped you please click "Vote As Helpful" and if it answered your question please click "Mark As Answer". SWC Unified Communications

    Tuesday, September 23, 2014 3:02 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi chrisw-0079,

    As other people have said, it is a complex project.

    And there’s an another solution for your reference.

    1. Don’t provide the DNS services for the VPN clients.

    2. In the Host file of client, add the entries of internal servers (except the Lync Servers) that you want to access.

    After doing this , the Lync client will always use the local internet connection.

    Best regards

    Wednesday, September 24, 2014 3:02 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Anthony is correct on this. If your VPN at present does not have split tunnel and you serve with internal DNS your actions should be something along these lines:

    • Start by ensuring you have your Lync solution setup for QOS, this allows you to block not only access to your front ends but access to your clients. Lync by nature will always start with P2P first. If you do not have QOS ports setup you will have to block too wide of a range. 
    • Next Block all access to the front-end servers, web servers and the newly created port ranges from your VPN ranges to all client ranges (blocks point to point).
    • In your Internal DNS create an external zone with the IP's of your Edge servers. this will allow them to get the IP of the external edge interfaces.
    • Put exclusions in place to allow that traffic out of your VPN.

    Some of this can be done with GP but I have been in many environments that a good amount of users are non-joined machines. Doing it at the VPN concentrator allows you to change the flow for all. Some time and wire shark you will be able to see the traffic coming in from edge vs. direct and point to point. 

    On a side note, it is typical that using this method creates longer login times. I notice this much more on Mac machines. One work around is some firewall tcp reset settings or statically setting clients and pointing them to a blocked web URI LB. Then it tries the one name and fails over to external. Since it can resolve the records via internal DNS it will try all. 

    YMMV

    MCSE:Communications | MCTS:OCS | MCTS: Exchange 2010 | MCSE: Messaging | MCITP:Enterprise Administrator,Enterprise Messaging, Server Administration | Avaya ACA | Aruba ACMP | Convergence+

    Wednesday, October 15, 2014 3:03 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    When Connected to the PN if the DNS Records required for SIP and AV traffic point to the Lync edge server instead of the Lync front-end or director Server 

    And on the internal firewall for the VPN Subnet if you block The port for SIP communication 5061 this will work 

    Something similar what is being done for AV traffic in this article 

    http://blogs.technet.com/b/nexthop/archive/2011/11/15/enabling-lync-media-to-bypass-a-vpn-tunnel.aspx

    Please remember, if you see a post that helped you please click ;Vote As Helpful" and if it answered your question please click "Mark As Answer" Regards Edwin Anthony Joseph

    Tuesday, September 23, 2014 5:04 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Agree that this is possible, though a lot of it depends upon how your VPN setup acts.  If all traffic is forced through the VPN tunnel, even Internet traffic, and your firewall does not allow hairpinning, you might have some trouble.  If Internet traffic does not tunnel through the VPN, you might be OK.

    If you must present internal DNS to VPN users, it can get tricky.  If you can restrict access to the front end from the VPN subnet, and the internal DNS also returns external lookup records such as lyncdiscover and your external web services FQDN, you might be OK.  But the client if it has the ability to connect internally typically, and it's offered internal DNS records with full access to the front ends, it's going to connect internally. 

    Please remember, if you see a post that helped you please click "Vote As Helpful" and if it answered your question please click "Mark As Answer". SWC Unified Communications

    Tuesday, September 23, 2014 3:02 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi chrisw-0079,

    As other people have said, it is a complex project.

    And there’s an another solution for your reference.

    1. Don’t provide the DNS services for the VPN clients.

    2. In the Host file of client, add the entries of internal servers (except the Lync Servers) that you want to access.

    After doing this , the Lync client will always use the local internet connection.

    Best regards

    Wednesday, September 24, 2014 3:02 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Was your question answered?

    Please remember, if you see a post that helped you please click "Vote As Helpful" and if it answered your question please click "Mark As Answer". SWC Unified Communications

    This forum post is based upon my personal experience and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Tuesday, October 14, 2014 8:41 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Anthony is correct on this. If your VPN at present does not have split tunnel and you serve with internal DNS your actions should be something along these lines:

    • Start by ensuring you have your Lync solution setup for QOS, this allows you to block not only access to your front ends but access to your clients. Lync by nature will always start with P2P first. If you do not have QOS ports setup you will have to block too wide of a range. 
    • Next Block all access to the front-end servers, web servers and the newly created port ranges from your VPN ranges to all client ranges (blocks point to point).
    • In your Internal DNS create an external zone with the IP's of your Edge servers. this will allow them to get the IP of the external edge interfaces.
    • Put exclusions in place to allow that traffic out of your VPN.

    Some of this can be done with GP but I have been in many environments that a good amount of users are non-joined machines. Doing it at the VPN concentrator allows you to change the flow for all. Some time and wire shark you will be able to see the traffic coming in from edge vs. direct and point to point. 

    On a side note, it is typical that using this method creates longer login times. I notice this much more on Mac machines. One work around is some firewall tcp reset settings or statically setting clients and pointing them to a blocked web URI LB. Then it tries the one name and fails over to external. Since it can resolve the records via internal DNS it will try all. 

    YMMV

    MCSE:Communications | MCTS:OCS | MCTS: Exchange 2010 | MCSE: Messaging | MCITP:Enterprise Administrator,Enterprise Messaging, Server Administration | Avaya ACA | Aruba ACMP | Convergence+

    Wednesday, October 15, 2014 3:03 PM