Support for 1:1 NAT installation (and thus VMWare vCloud deployments)

[Frank Broughton]

cPanel being the best Web Hosting control panel on the market and having a great record of making awesome updates over the years should finally consider making this great app work seamlessly in a 1:1 NAT environment.

Please consider officially supporting 1:1 NAT installations.

Thank You Team!

[JawadArshad]

+1 for this one.

[cPanelDavidG]

It seems NAT has graduated from the realm of "basement datacenters" to quality production environments. Are there any particular practices used in data center NAT environments that you feel we should be mindful of when implementing this capability?

[Frank Broughton]

really is needed for a legitimate data center use...

[gruvin]

A number of vendors are coming online with vCloud server solutions, which they are providing with VMWare vSphere technology, etc.

Most of these (if not all) implement local networking for the virtual server using NAT to map public IPs one-to-one onto local private IPs. This allows for maximum flexibility as well as load balancing and fail-over technologies to be employed.

Currently, cPanel's account creation and DNS functions alongside virtual Ethernet port addresses etc. cannot cope with the mode of operation, since they all require direct public IP addresses only.

To allow for cPanel operation under these NAT'd circumstances, a feature would need to be added to cPanel that allows mapping of public IP addresses to internal private IPs.

Example:

Local network ports:

eth0:0 = 192.168.1.1
eth0:1 = 192.168.1.2
eth0:2 = 192.168.1.3

Public address mapping:

1.2.3.4 --> 192.168.1.1
100.200.111.222 --> 192.168.1.2
100.200.111.223 --> 192.168.1.2
etc.

httpd.conf:
<VirtualHost * 192.168.1.1:443 192.168.1.1:80 ... etc>

WHM Welcome Email:

IP Address: 1.2.3.4 (public)
etc

Adding this support will enable cPanel to be installed and operate correctly on a large number of vCloud vendor solutions we expect to see appearing in the market in the very near future.

[cPanelDavidG]

Most of these (if not all) implement local networking for the virtual server using NAT to map public IPs one-to-one onto local private IPs. This allows for maximum flexibility as well as load balancing and fail-over technologies to be employed.

I have merged your new feature request into the existing thread on 1:1 NAT support.

[gruvin]

It seems NAT has graduated from the realm of "basement datacenters" to quality production environments.

Indeed! I was pretty shocked when I first encountered this, too. But I now understand this specific practice to be actually quite intelligent. "Welcome to The Cloud, baby."

Perhaps the core difference between "basement" situations and this is that the latter gives each IP its own complete virtual network interface, with full, unfiltered connectivity. That is, there are no "pin-hole routes" involved as there would be in most "basement" situations. Often though, an upstream Firewall is inserted where the basement DSL/Cable modem might have otherwise been.

The advantage of this system becomes clear when one considers the likes of load balancing. Where as internal proxy servers for specific jobs -- like HTTP for example -- might have been required before, this NAT'd virtual environment now allows for load switching right at the (virtual) physical layer -- for any and all network traffic, however the administrator so desires. Pretty cool. Similar benefits exist for fail-over implementations too, of course.

Menial tasks such as migrating a virtual machine to a new physical node (processor core(s) and RAM) without down time remains effortless, as it in fact already was without NAT. But with NAT-mapping of this type, switching over any separate upstream firewalls or load balancing systems is presumably also made much easier -- especially if only a portion of a server cluster is involved, for example. (I am working more on assumption than any specific, known practice in these latter comments! :P)

Are there any particular practices used in data center NAT environments that you feel we should be mindful of when implementing this capability?

I cannot think of anything in particular. I should think that most of the fancy stuff that one could do in their own virtual LAN using features made available by the NAT'd environment will not apply to typical cPanel installations. Further, the smaller (cheaper) public offerings using this technology do not typically give the end client access to much of (or any of) that stuff anyway.

So, beyond the public-to-private IP one-to-one mapping issue itself, I personally don't think there's anything to be concerned with. cPanel will "simply" need to become aware of the public versus internal IP situation and adjust its internal management and user communications accordingly.

Anyone else?

@cPanelDavidG: If you'd like to experiment with a live example of a server of this nature, please PM me. I have a CA based, VMWare vSphere (NAT'd) server online at present. cPanel is fully installed and running on a valid license. But the server is not in production and I was about to take it down. Now though, I'll leave it up for another week or so or until I hear back. (I can effortlessly clone a copy of the thing too, if needed. Indeed, the ability to do such things is a major motivation for using these new offerings for our cPanel installations in the first place.)

[cPanelDavidG]

@cPanelDavidG: If you'd like to experiment with a live example of a server of this nature, please PM me. I have a CA based, VMWare vSphere (NAT'd) server online at present. cPanel is fully installed and running on a valid license. But the server is not in production and I was about to take it down. Now though, I'll leave it up for another week or so or until I hear back. (I can effortlessly clone a copy of the thing too, if needed. Indeed, the ability to do such things is a major motivation for using these new offerings for our cPanel installations in the first place.)

Thanks. I think that's a really cool setup you have. I always find it interesting when people use our software in unanticipated ways. Unfortunately, I'll be busy at Internet World in London this coming week so I wont have time to play with things myself, but I will take your word for it . Thanks for the input!

[cPanelDavidG]

I just wanted to add to the discourse about this functionality something that was stated in gruvin's post but not something I had noticed till discussions with a Partner NOC today. This NAT support would need to accommodate NAT while maintaining the ease of use of all cPanel & WHM features, including the ability to set sites up on their own dedicated IPs (including mapping the additional internal IP to the additional external IP) and deploy SSL certificates. This is a significant issue in attempting to deploy cPanel & WHM in VMWare vCloud environments in a way that will not cause significant support load.

[aghconsultores]

We have all our cPanel/Enkompass VPS over VMware vSphere 4.1 with public IP and we are interested in NAT 1:1 support too.

[neodnoc]

I would also like to see 1:1 NAT support in cPanel.

A seperate Filtered Bridge firewall just for cPanel is a pain.

Thanks!!!

[itdoug]

This is a necessary feature for us. Going to have to ditch cPanel if this isn't supported soon.

[luigidelgado]

+1 here... I have been wondering how to take cPanel into EC2 with no hassle... Cloud is not the future, it is here, now. Cant think what could happen to cPanel if they dont take this valuable feature request seriously...

This feature will be in short a must. Hope to hear from it soon

[darlanart]

With the approaching end of IPv4, is an urgent need.

[yakatz9]

We are also really interested in 1:1 NAT support.
The new update to the managed firewall we use really wants to force 1:1 NAT on us, so in the mean time we will be using cPanel in an unsupported configuration.