I will be rebuilding my UCS network in the foreseeable future.
So far I have used a fancy domain like : intern.lan etc. for the installation of the master.
This makes it difficult or costly in some cases to use local services Jitsi, Rocketchat etc from external.
Is it advisable to do the UCS installation with a real domain like ourcompany.com? or create a subdomain externally like intern.ourcompany.com and use that for the UCS installation?
Thanks for the tip. The certificates are not the problem for me. The HA proxy on the pfSense accepts the requests and provides the appropriate LE certificate for the requested subdomain.
I have read the article. One question arises for me.
I have installed the UCS with the subdomain ‘internal’ under my real domain ‘example.de’. The UCS DNS is now responsible for ‘intern.example.de’. The external server for ‘example.de’.
I install my UCS nodes as ‘cloud01.intern.example.de’, for example. On the external DNS, I create the subdomain ‘cloud.example.de’ for this host and set a corresponding record.
so that it can also be directly addressed internally? I always thought that an alias must not be ‘higher’ in the hierarchy than the domain for which the DNS is responsible. So ‘‘internal.example.de’’
Just a simple thing: as soon as you use SSL/HTTPS or similar you can not get what you want. Certificates are bound to hostnames. Trying to access the internal server with it’s external hostname will cause certificates issues (name mismatch). No matter if you use internal certificates or “official” ones. They will always match only one hostname.
Ignoring (or working around with some sort of proxy) certificate issues you can generate “overwrites”. So far as I remember they are called “RPZ” entries in DNS which those you will be able to overwrie public entries with your desired ones. Take a look here.
Ok, then I’ll continue to use the HA proxy. It also listens on the internal interface of the pfSense and delivers the correct certificates. I just thought I could leave that out.