Split IP Usage

[Marshall]

I would like to see a way to split the IP usage in DA, not from the client standpoint but from DA itself. Right now the only variable you have is ethernet_dev in directadmin.conf to control where the IP is located. It would be nice to split this up into two parts, one for controlling where it looks for the licensed IP and connects to the license server from and one for everything else.

I ask this because of how I have a server running, it is behind a NAT enabled firewall. The server has two ethernet ports which allows me to plug one into the firewall and one directly into the switch. The ideal method would be to have it drop all packets except for those going to the DA servers for license checking BUT DA also uses the same NIC to do its multi server setup and check for new versions in the control panel.

If this could be split into something like

ethernet_dev=eth1
ethernet_use=eth0

such as it will then use eth1 to contact DA and update licensing and use eth0 to check for new versions/software updates and send multi server setup requests through it which would make it more ideal. Then I could just set eth1 to drop all incoming packets and only allow outgoing to DA and make it a bit more secure. I could also put a different hardware firewall in front of it without NAT with those restricting options if need be (or the datacenter/host could make a shared firewall for this purpose and connect multiple DA servers into it so that customers can still have their servers behind a NAT and use this to only send out for license checks on a public IP).

Would anyone else want to see something like this in DA?

 

[Marshall]

It also seems to want to bind to that interface when trying to install plugins as well which makes it more annoying since it means I have to create more holes to allow plugin updates. The ability to move all these other functions to another interface would help immensely in securing the server.

 

[Marshall]

Also, to add on to this, maybe in the IP management area it can have public/internal IP fields. This way, for people that are running it behind a NAT using the workaround I did, they can enter in the Public IP and the Internal IP for their IPs. This way when they select the IP to create a new user, it will put the public IP into the DNS zones and put the private IP into the HTTPD config files so that it works.