Posted on 03-18-2017 02:05 PM
Hi everyone!
Building out a new JAMF Pro environment - I'm in the testing phase. The new environment will have an application server and a distribution point in the DMZ. Internally we have a JSS running JAMF Pro and SQL on the same server, and the primary distribution point.
Right now during testing I'm seeing the following issue - if I create a new policy, internally the clients I'm testing see it right away. However, externally, when they check in with the JSS they don't see the the new policy. Externally I can connect to the JSS without issue, and run a recon, with no errors. If I restart the JSS on the DMZ, it then grabs the "updates" from the internal server, and I can then force the policies to run via command line or self service.
This new environment is much different than our existing. I'm moving from running JAMF Pro on XServes that are internal only to new application servers running on Linux (Cent OS) VM's and distribution servers running virtualized Windows Server 2012 R2 VM's. Plus the DMZ, plus everything having "certificates". Lot's of new stuff where I'm thinking I may have missed a step. Before contacting support just was hoping for some hints on where to look for this issue. I followed the admin and setup guides in setting up the environment, but maybe I missed something causing the two application servers to be out of sync?
Thanks!
-Ted
Solved! Go to Solution.
Posted on 03-18-2017 05:59 PM
can the child server communicate to the master server over 8443?
Posted on 03-18-2017 08:40 PM
@taugust04 A few thoughts:
Communication from the JSS in the DMZ to the master JSS/MySQL database should only be on port 3306.
Access to the Master JSS MySQL database must be granted to the user and IP address of your DMZ JSS.
Is clustering properly configured in both your Master and DMZ JSS?
Posted on 03-18-2017 05:59 PM
can the child server communicate to the master server over 8443?
Posted on 03-18-2017 07:26 PM
@Sonic84 I will verify that - perhaps a firewall rule is in the way. Thanks for the tip!
Posted on 03-18-2017 08:40 PM
@taugust04 A few thoughts:
Communication from the JSS in the DMZ to the master JSS/MySQL database should only be on port 3306.
Access to the Master JSS MySQL database must be granted to the user and IP address of your DMZ JSS.
Is clustering properly configured in both your Master and DMZ JSS?
Posted on 03-18-2017 09:26 PM
@Sonic84 Checked my firewall rules and I was missing one from the DMZ to the master server on 8443. 3306 was already setup correctly.
@sdagley Clustering was not configured correctly - enabled and configured and it seems to be pushing changes now. Will monitor and test more when I'm back in the office on Monday.
Thanks to you both for both pointing out possible configuration issues. I think these two items were the missing pieces to the puzzle!
-Ted
Posted on 03-18-2017 09:26 PM
I'd recommend putting a proxy or appliance in the DMZ and not an app server. Then either terminate at your appliance or allow a reverse proxy in and terminate at Tomcat. That way you don't have to deal with the headaches of putting an app in the DMZ or the risks.
I guess I will say if your Org has a process to harden a box for DMZ use I would definitely have that team do that, if that is applicable at your Org.
-Tom
Posted on 03-18-2017 09:26 PM
Posted on 03-19-2017 08:17 PM
@taugust04 In a clustered environment there is no communication between JSSs on port 8443 (it's the MySQL server they all need to talk to on port 3306) so so your DMZ and master JSS apps don't need that port open between them. And don't forget to put the JSS in your DMZ into limited access mode as well as eliminating access to the API and device enrollment depending on what you're intending external users to be allowed to do.