See - https://www.novell.com/documentation/zenworks-23.3/zen_cm_deployment_bp/data/t49ifjlwfu5m.html (DMZ Best Practice Guide)

Your devices being behind a NAT will not matter.

#1 - Your Devices will need to be able to connect to Port 443 on a Primary Server.  Any one of the following is an option...

• Configure your Devices with VPN to connect into the Corporate Network
• Place a Primary Server in the DMZ
• Use a Web Forwarding Proxy Server. (Configure your Primary with a 2nd DNS Entry that is public.  The Web Forwarding Proxy Server will relay that to the internal server.)

#2 - For Remote Control of Home Devices, Setup a Join Proxy Server in the DMZ.  I'm not sure if this would work with a Web Forwarding.  It may but have not seen this done.

When a Device Starts Up.....The "Remote Control Service" will establish a long-lived connection to the Join Proxy Service.  When a device is remote controlled, the existing connection to the Join Proxy server is used so there is not a need to reach into the NAT'd network.

Additionally, when the Device Starts up the "ZEUS" (ZENworks Updater Server) will establish a long-lived connection to the Primary Server.  This will allow for "Quick Tasks" and such to be issued to the device using the existing connection which again avoids the need to reach into the NAT'd network.  Scheduled events such as normal refresh will just reach out normally to 443 on the primary and not need any connection into the NAT'd network.

So no.....A Direct Connection to the clients is never required.  The clients require a connection to the server but not the reverse since the clients establish the connection not the other way around.

• Use a Web Forwarding Proxy Server. (configure your Primary with a 2nd DNS Entry that is public.  The Web Forwarding Proxy Server will relay that to the internal server.)

To Clarify the above....The Additional DNS Entry is not added to the OS Itself.  In the ZCC in the Properties of the Primary Server under  "Infrastructure management" add the "Public DNS" entry under additional DNS Names.  This will add this address to the location rules so devices outside the network can try to hit that address  when necessary.

Ideally, though not necessary, the DNS Resolution when inside the corporate network will resolve this additional DNS name with the internal IP address and with the External Proxy Address when outside.  

Hello everybody, hello Craig,

thank you very much. I will take your information for a test setup. 

i can't estimate yet when we can test it, we are completely busy

Best regards

Andreas

Hi Craig,

now we would like to go foward with this task.

We need a basic understanding which server, server roles and configuration doings
on each part are necessary. I will try to explain in text and post a graphic.

Our setup idea:
Primary ZCM(private IPv4) - ReverseProxy (Public IPv4) - Satellit/Join Proxy(Public IPv4) - ClientSubnet(Public IPv4)
We don't know if this idea is correct and which configuration task on each part are necessary?
Also which ports are involved for deployment, remote management etc.
Which Linux distribution are supported, maybe debian also ubuntu or only suse?

Thanks alot an best regards

Hi, i try to upload a JPG from my windows desktop,but i dont know

I received your email and responded.....

In short....Many customers use a Reverse Proxy to allow home devices to hit the Primary Server on Port 443 and 7019 ( Remote Control JoinProxy).  The home devices will establish a long-lived connections to the primary and joinproxy, so it is not necessary for the ZCM Servers to be able to establish a connection to the home device....If the server needs to reach out, it will consume the long lived connection created by the agent.

https://www.novell.com/documentation/zenworks-23.4/zen_ports/data/zen_ports.html

Preferably there will be a DNS Address for the server that resolves One Way inside and another outside, but that is not a requirement.  But "ZAC ZC -L" will need to include an address the remote devices can resolve or connect to through the reverse proxy.