how to split existing JSS install between web-facing & internal clients?

[egjerde]

Hi All,

I just started a few weeks ago at my company, and inherited a JSS deploy that needs a little polishing. It's currently set up in a hosting environment that is connected via a private network, but the JSS server has a FQDN and has web access via the usual port 8443... meaning all my clients are connecting to it via the web at the FQDN, and not via our internal network as they should. However we also have a number of remote workers and a highly-mobile workforce so there's something to be gained by retaining some of that external accessibility; I just want to make sure all our systems in-house are actually visible by me, and not just showing up as the IP of our firewall :)

What's the best way to change this? I was looking at either changing the JSS server address for the clients to an internal FQDN, or doing that & setting up a JSS server in a DMZ as well for the outside clients... is there an easy way to split up your users to assign them to different JSS server addresses? Or is there a better option?

Ultimately I'd love to be able to point them all at one address since we have a wide-ranging mix of mac laptops coming and going from our internal networks to external networks, and requiring VPN connectivity to do management etc means I'll have a lot of machines go dark on me - but I also want internal network visibility to all my systems in-house.

I'm new to all this and doing my best to get up to speed, but words of wisdom from knowledgeable admins are worth their weight in gold, so if you've got helpful advice to share I'm all ears!

[pblake]

We use one address on the internet. Then internally have DNS point all requests to that internet address to our internal server. That way all machines technically use the external address, but internal machines are routed internally.

[rsprik]

Agreed. We use "split DNS" for not just JSS for this. Internally our DHCP will assign an internal DNS server that has manual entries to direct clients to the internal IP addresses for those resources. Our public facing DNS points to the public IP.

[damienbarrett]

We do exactly as @pblake is doing. It's the de facto way of setting up a server available both internally and externally (public-facing). The big hurdle here is that you'll either need to be able to control your own Intranet DNS or be able to work with your NetOps guys who do so they can put in the correct entries.

[egjerde]

I'm in agreement with you all - that is how I would normally do it, too; just have my internal DNS servers give one answer and my public ones another, everyone's happy.

The wrinkle here is that almost everything my company does is hosted "in the cloud", including our DNS management (we're a web dev shop with thousands of domains to manage). We don't even have an internal DNS server! it's a big change for me, coming from an enterprise environment.

I guess I'm just going to have to find a way to convince my company to allow me to set up internal infrastructure :)