[VoiceOps] Lync, VPN and DNS?

[Ryan Delgrosso]

Well as I see it you have 2 ways to solve this problem:

1: Introduce some kind of split-horizon DNS which then adds multiple 
layers of complexity unnecessarily and ultimately puts another yoke on 
the neck of the DNS admin. This may or may not actually solve your 
problem as the SDP in the signaling generally uses IP address literals 
not FQDN's

2: Let the signaling and media take the same path, whether that be 
tunnel the media, or put the signaling over the public internet. Both 
have their merits depending on your requirements and infrastructure. If 
this is for lots of single remote users using softclients, and you have 
a relatively robust VPN head end, then tunnel everything. Solves for NAT 
and can even pave over jitter and MTU issues. If this is hardphones or 
the VPN head end is of questionable beefiness, then work out the NAT 
traversal and pass it all public (can use TLS for signaling here for 
security)


On 2/2/2015 10:50 PM, Ray Van Dolson wrote:
> Possibly.  Am not the VOIP admin here (DNS & Network), so am getting up
> to speed on the architecture.
>
> What I know is that when a user VPN's in, they're pointed to internal
> DNS servers which return internal (RFC1918) addresses addresses for the
> Lync infrastructure.
>
> Are you suggesting having the default be to point users to the
> "external", Internet-accessible addresses?
>
> Ray
>
> On Mon, Feb 02, 2015 at 10:23:19PM -0800, Ryan Delgrosso wrote:
>> Ray,
>> Is there a reason you're tunneling the signaling at all? Seems like
>> the path of least resistance would be to let the signaling and media
>> take the same path. You're obviously already handling NAT traversal
>> if you have the media going public.
>>
>> On 2/2/2015 10:00 PM, Ray Van Dolson wrote:
>>> We have a corporate Lync environment with a large # of users hitting it
>>> via their VPN tunnels.  We've set up routing on the VPN client side to
>>> allow VOIP traffic to be routed over the public network rather than
>>> through the tunnel -- if we can just get the DNS lookups to return the
>>> public IP's instead of the internal IP's.
>>>
>>> We run BIND and I'm struggling to see a solution short of creating a
>>> special view or separate BIND server just for VPN clients in which I
>>> need to create many zone files to override the relevant Lync DNS
>>> records (one zone per record since unfortunately all of our
>>> Lync-related records live within our primary domain).
>>>
>>> Seems ugly and error prone.  Maybe BIND's RPZ could help?  Or maybe
>>> there's some simpler solution I'm missing.
>>>
>>> We also have F5 w/ GTM -- maybe some magic could be done there.
>>>
>>> Any thoughts/advice?
>>>
>>> Ray
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops