In short yes. You have to do channel security, and many other secruity features. You might want consider reverse proxy instead to deliver software for user's on the internet.
Done a lot of this we always require at lease SSL pick your own port if you like (not using 443 helps).
As young said you might want to consider both server and client side certs, as well as channel signing.
Reverse proxy is also good to have.
Thanks for the reply.
Please have look at the attached snap. The BBCA server will be deploy in cloud as others are running. Then how tuner will connect with server as there is no directly connectivity between server and tuner. The remote user’s are accessing the application over port 80 (like accessing the google /gmail /yahoo from any where)
There are a few customers that have BCA in a "cloud" environment. Actually the product is a natural fit for such a goal be/c
1) ALL communication is via HTTP(S)
2) Majority of the well known web hosting methodologies can apply (DNS tricks, load balancing, redirects, etc)
3) The client/tuners were designed from day one to be able to fend for themselves in harsh conditions (slow and un-reliable network connections, random reboots, etc) by supporting check point restarts on downloads, byte-level and file-level differencing, signed content, everything is md5check summed, etc)
4) The clients/tuners/agents PULL the data therefore are firewall and proxy friendly. The tuners have built in schedules and can detect when they are connected to a network therefore prompting them to conduct HTTP POSTs and GETs to the outside servers
To answer your question, you would create tuner profile with have proxy server setting that point to the proxy server and the proxy server out in the DMZ would have access to the Master transmitter. Does that answer your question?
This seems to be a very hot topic at the moment, our company is very much moving towards making internal services available outside meaning more and more of our mobile clients never connect to the internal network or certainly not for longer periods than before making patching and obtaining inventory of these machines impossible.
Is it therefore possible to have the environment set up to fail over to a repeater/proxy in the DMZ if no internal connections are available?
We wouldn't be able to specify any particual clients which are either always inside or always outside of our private network so this is very important to us.
The catch here is that the repeater redirection is available on the master transmitter and hence the master transmitter has to be made available outside as well.
You can probably mirror the essential content of your master transmiter in the DMZ for the clients not connected to the internal network. This mirror would act as an external transmitter and would make the service available outside your organisational network to the mobile clients.
Your setup in your DMZ will have to be based on your security requirements. Keep in mind that TXs have plugins that execute and query/insert information into AD and a database.
Often what we see are Reverse Proxies setup in the DMZ that point back to an internal TX that has proper access to AD and the DB. External tuners then connect to the Reverse Proxy which in turn connects to the internal TX.
Often customers will use a DNS trick.
On the internal network the TX farm is referenced by tx.example.com but the internal DNS server returns an IP of 192.168.3.145. Externally the customer setups up the same domain as tx.example.com but it has a public IP of say 220.127.116.11
Therefore when an endpoint connects to the internal network the tuner is routed to the internal IP and when connected to the hotel's network they are directed to the external IP. Of course there are a few tuner properties that have to be tweaked due to IP Address caching but its doable.
to answer your specific question...the only way i can see achieving what you are looking for is if you can have a separate mirror farm in your DMZ and those mirrors can connect to AD and the DB. Then you would want to focus on methods that allow you to redirect IP traffic from 192.168.2.145 to 18.104.22.168. Maybe your internal LB has the capability to detect that your internal TXs are down so re-direct traffic to the public IP. I'm not a Microsoft DNS expert but I know it's been heavily enhanced so admins have better control over resolving hostnames to different IPs. Then there are things like global load balancers that have the ability to directly modify routing tables at the router/switch.
"Is it therefore possible to have the environment set up to fail over to a repeater/proxy in the DMZ if no internal connections are available?"
Yes. The failover should be another repeater/proxy. If you use windows clusting or some kind of clusting on the repeater/proxy in the DMZ is the simplest way. (Use VMs)