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
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
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
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
What about a recursive BIND server which will return results from its hosts file but forward other queries to your internal DNS servers? The hosts file would contain your overrides.
-----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Ray Van Dolson Sent: Tuesday, February 03, 2015 12:00 AM To: voiceops at voiceops.org Subject: [VoiceOps] Lync, VPN and DNS?
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
participants (3)
-
LRiemer＠bestline.net -
rvandolson＠esri.com -
ryandelgrosso＠gmail.com