Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 3 subscribers
  • Views 1625 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Give a public address to private subnet via a VPN tunnel

AlatarK

Customer has site A with a public IP range and several spare public addresses. They also have, in a different city, a domain on a small subnet (site B) which has tons of bandwidth but is behind two NAT layers and no chance of getting routing through from the outside. There are UTMs at each site.

We've set up a site-to-site VPN which works fine for (nearly) all their purposes. Remote users can happily VPN into site A and access site B resources.

A problem has arisen trying to domain-join a remote home user to the site B domain. My belief is that this because the server records necessary to join domain B are in site B's DNS servers, and the home user is getting his DNS from site A.

I have considered things like A) manually adding the site B SRV records to the site A DNS, B) setting up a trust relationship (which I have no experience with), and C) tweaking the remote user's VPN to use the site B DNS -- but they all seem likely to cause more problems than they solve.

So I'm looking into whether D) "bridging one of the public IP's through the site-to-site VPN so that it appears and functions as a public address for site B" might work. This would let the home user VPN into site B directly (from his point of view), and the domain join should work.

Essentially, a tunnel from the externally facing NIC at one site, through the site-to-site tunnel, and appearing as an interface on the UTM at a second site.

Any ideas?

Paul

 

PS: it occurs to me that I could unmap the relevant public IPaddress from the site A UTM box, and pipe it through any random third-party VPN setup, so it must be possible. But can I do it within the existing pair of UTM boxes?



This thread was automatically locked due to age.
Parents
  • 0

    Hi Paul,

    If Site B is unable to resolve the domain, you need to make sure any DNS requests for the domain as a whole get routed to the relevant domain controller.

    This is done via Network Services > DNS > Request Routing.

    So if the UTM at site B was the Primary DNS resolver via DHCP, or however else you distribute it, you set the UTM to route all DNS requests for the (sub)domains of your domain.dns to your DCs at Site A.

    I suspect that is your issue.

    Emile

  • 0 in reply to Emile Belcourt

    Thanks for your very quick reply.

    The problem is that only these domain join requests aren't getting resolved (at least that's what it seems at the moment).

    Normally, the remote user will have DNS set to his ISP's servers, and then when he VPNs into site A, he will be assigned the site A DNS servers. The site A servers have the correct DNS stub zones for the site B domain, and (as mentioned above), requests for domain B resources are being correctly found.

    But the SRV records required for domain joins (weird DNS records with lots of underscores) don't seem to be found*.

    Regarding DNS Request Routing, don't those only apply when when using the UTM's DNS server (all the DNS Servers are AD-integrated Windows ones, which, as far as I know, are pretty much de rigueur for this scale of domain)? If not, how can I tell it to use DNS Request Routing for just one Remote Access profile? Everyone else should be getting their DNS from site A servers.

     

    *the more I think about it, the more I think I'm wrong: the records are weird, but they still end in .siteB.com , so they should be being resolved through the normal stub zone mechanism like all the other site B requests. Perhaps there's something else going wrong.

    Nevertheless, the question still stands: it would be great to "donate" one of site A's public addresses to site B, which has no way to obtain one, via a tunnel from the the site A outside interface to the site B UTM.

     

     

  • 0 in reply to AlatarK

    Just to clarify further, I am not too worried about the immediate domain join issue. If worst comes to worst, I will tell him to bring his home computer into the site B office and do the domain join locally. We know, from other examples, that once it's domain joined, it will work properly using a VPN, even though that VPN is actually going to site A, then routed through a site-to-site tunnel to site B.

    My interest in posting is about the general concept of donating spare public IP addresses to sites that aren't able to get them using VPN tunnels (be they UTM site-to-site tunnels or otherwise).

Reply
  • 0 in reply to AlatarK

    Just to clarify further, I am not too worried about the immediate domain join issue. If worst comes to worst, I will tell him to bring his home computer into the site B office and do the domain join locally. We know, from other examples, that once it's domain joined, it will work properly using a VPN, even though that VPN is actually going to site A, then routed through a site-to-site tunnel to site B.

    My interest in posting is about the general concept of donating spare public IP addresses to sites that aren't able to get them using VPN tunnels (be they UTM site-to-site tunnels or otherwise).

Children
No Data
Unfiltered HTML