I'm just wondering what the reason is that each server in a multiserver setup needs to have it's own external/public IP address? From a tech standpoint I prefer to have all of the services running on their own separate servers (so that makes 7 servers). From a practicality standpoint, however, some of those services can easily share IP addresses with ports forwarded appropriately so I could run quite well with 3 or possibly 4 IP's. I don't mind using address space if it's truly needed but IPV4 IP's are costly and justification is required upstream when I need to order more so I try not to waste them. IPV6 address space on the other hand, heck I may assign individual IP addresses to the grains of rice in my kitchen cupboard Mike
You can use internal addresses as well if you like. The example setups in the tutorials are just written for servers or virtual servers that are in a data center and therefore have their own public IP anyway. But if you run them in a private network, then use private IP's and forward traffic to them from your router based on the used service. This does not matter for ISPConfig.
Thanks Till, the multiserver setup tutorial makes it sound like it's *really* important to have individual public IP addresses (to the extent that it's actually boldfaced in the tutorial). "Before starting the installation of a server, set up an A and eventual AAAA record that points to the public IP address of your server. For example, if the hostname is panel.example.com and the public IP is 11.22.33.44, you should set up an A record for panel.example.com pointing to 11.22.33.44. Every server should have its own public IP and hostname." Are there any caveats to doing this? IE. are there any services that I should avoid having share an IP address... I'm thinking in terms of maybe issues with Letsencrypt certificates working or renewing, etc?
Because that's how the setup is intended to be used and works well. You can set it up differently, but you will have to find ways to work around the limitations you impose by not being able to reach all nodes from outside. You can not use Let's Encrypt SSL certs when using shared IP addresses as Let's Encrypt must be able to reach the server that requests the cert. You might work around this by writing some scripts that request certs on one system and copy them to the other systems by SSH or by SSL certs from a SSL authority and install them manually or by using DNS auth for LE, which would mean you must set up LE manually then on all non webserver nodes.
The cost of finding a way around and dealing with the bugs and maintain the workarounds is without a doubt higher than the 2-3 more IP Adresses you may need. From expirience especially in a hosting environnement it is a headache to deal with problems that are caused by such setups.
Agreed. Actually, some of mine are setup like this which are behind NAT router with one public IP, and it is even a dynamic IP, so I would say that such setup is possible but may require very good administrator(s). The only limit is that it won't work for email server because of port 25, and may be public IP DNS server (although private IP DNS server may be possible), if the IP is a dynamic public IP because of its constant changing. The setup could work if the IP is a fixed public IP with opened port 25. The secondary (backup) DNS server can be placed on another free server like at freedns.afraid.org which offers that service. For web service, though one is normally enough (with best specs), if one want multiple web servers to work behind that one public, be it dynamic or fixed, one might want to consider proxy. This is absolutely true and that is why I am using DNS challenge or authorization for LE SSL certs and I shared most of the in this forum already, even latest approach as well. You can even share your web server LE directory, if you only prefer to use ISPConfig default webroot challenge, with other servers especially if you cannot fully comprehend on how to work around the DNS method.
The DNS option is something that I'd certainly investigate if nothing else. In the interim, however, would ISPConfig's default LE setup be "happy" if the non-webserver nodes were only exposed over IPV6?
I've been running several generations of servers behind NAT for years without an issue. I was also running servers before NAT was even a thing and now have looped back to IPV6 where many things are done much like the pre-NAT IPV4 days... so it's all good I think it's important to acknowledge that ISPConfig, like anything, is a tool and while some may want to use that tool directly out of the box following the manufacturer's instructions and others may have additional requirements/preferences/policies that lead them to have to do certain things differently. I'm grateful for Till's work on ISPConfig as it's made life easier in so many ways, but at the same time there have been a relatively consistent set of manual tweaks that I've applied to each generation of ISPConfig servers I've deployed to bring them into line with either our network policies or what I consider best practice. Those tweaks will almost all carry forward to this latest generation which I'm building and will be supplemented by new tweaks as required. I will certainly be seeking out your notes on this matter as (to my mind) it just makes sense to avoid running/exposing a webserver on a machine that isn't a webserver.
I have not tested dit, but its LE over http-auth. So you might do some research on the net if LE with http cert authentication on IPv6 only works, if thst#s the case, it should work with ISPConfig as well. ISPConfig nodes without a web server do not permanently run a web server for LE auth, the le client temporarily binds itself to port 80 for auth and shuts down right afterwards, this is named standalone mode, if I remember correctly.
This is correct. Servers with each is having its own public IP may use this ISPConfig readily available feature. However, if the servers are behind NAT router without each having own public IP, i.e. with only one lublic IP, port 80 from the router may normally be forwarded to one server only. I mentioned proxy as a possible solution for this but I didn't use it since I personally prefer dns authorization as the advantage of not needing that port 80 is clear.
