primary IP address and SSL needing dedicated IP

wayan said 11 months, 2 weeks ago:

I’m experimenting with a cloud server. So far, I’m just using one IP address. On my current dedicated (non-cloud) server, I need three IP addresses for multiple websites to support SSL and ecommerce requiring an IP address dedicated to just one website.

If I understand correctly, all outbound traffic uses the primary IP address regardless of the incoming IP. Does this cause problems for SSL connections that require a unique IP, or any other applications that come in on an IP address other than the primary IP?

krisl said 11 months, 2 weeks ago:

@wayan,

That’s only partially true. All outbound traffic *initiated* from the cloud server machine to the internet will go out the primary IP. An example would be your cloud server downloading a file from the internet, this will always take place over the primary IP.

All traffic that is in response to an outside initiated connection will go out the correct IP Address. For example, If you have a a port forward setup for port 443 on a secondary ip, the response from the Cloud Server will go out the secondary IP, not the primary.

If you want to host multiple ssl sites on a single cloud server all you need to do is on the cloud server have the ssl site run on a different port, then port forward the different port to port 443 on the secondary IP. An example is below:

SSL site 1: Primary IP (x.x.x.1) port 443 CloudServer1 port 443
SSL site 2: Secondary IP 1(x.x.x.2) port 443 CloudServer1 port 1443
SSL site 3: Secondary IP 2(x.x.x.3) port 443 CloudServer1 port 2443
SSL site 4: Secondary IP 3(x.x.x.4) port 443 CloudServer1 port 3443

wayan said 11 months, 2 weeks ago:

I think that makes sense. Just to be sure, my understanding is that my server on the private network only sees or sends the VPN (such as 1.1.1.*) and a port. My server couldn’t distinguish incoming PrimaryIP/port443 from incoming SecondaryIP/port443 since they both translate to VPN/port443. Assigning different SSL ports to each site is the only way my server can distinguish the incoming SSL requests. Requests other than SSL (such as http or mail) are sorted out by the domain name. Is this correct?

A follow up question: When is the ‘*’ in the VPN such as ’1.1.1.*’ assigned and can it ever change?

krisl said 11 months, 2 weeks ago:

@Wayan,
I am not sure what you mean with VPN, but I think I understand what you are asking.

Your server cannot tell the difference between an incoming request from primaryip/port 433 and secondaryip/port443 *assuming* that they both are sent to GDCSserver/port 443. That is 100% correct. This is why for each ssl site on your GDCSserver you create a binding to a different port, such as 1443.

To give an example. The ssl cert for https://example.com is bound to GDCSserver/443 which is then forwarded to primaryip/443 (all requests sent to GDCSserver/443 will be served with the ssl cert for example.com). The ssl cert for https://example2.com is bound to GDCSserver/1443 which is forwarded to secondaryip/443 (all requests to GDCSserver/1443 will be served with the ssl cert for example2.com). In this config requests to the primary ip will get the ssl cert for exmaple.com and requests to secondary ip will get the ssl cert example2.com.

If you were to take the above config and change the forwarding of the primary ip to the following: GDCSserver/1443 -> primaryip/443, then all requests to the primary ip will be served with the ssl cert for example2.com (since the ssl cert for example2.com is on GDCSserver/1443).

Requests that are not secured via ssl are able to be handled by the domain name or some other method. The issue with https is that the ssl session gets established before the name of the requested domain is sent. So the web server is unable to determine which domain the request is for and use the appropriate cert. There is a new spec that is being supported that will solve this problem: http://en.wikipedia.org/wiki/Server_Name_Indication

wayan said 11 months, 2 weeks ago:

I think we’re both saying the same thing. I’ve had a dedicated server for years but I’m just starting with cloud servers and terminology. The “manage” tab Network Rules in my cloud server Data Center shows VPN L2TP/IPSec which looks like a class C IP address (10.1.1.*). I assume this is the local IP on my server’s side of the NAT router, and the only IP that my server sees on incoming data. When does the ‘*’ in ’10.1.1.*’ get filled by by the router? When I create the account? When I start or reset the server? Could it change if I reset or stop/start my server or at any other time?

Thanks for all your help.

krisl said 11 months, 2 weeks ago:

@wayan

I see now. For the VPN L2TP/IPSEC section, that is a class C and it is different than the classs C for your private network. This only displays network information if you have configured a VPN at some point. In order for the VPN connections to work correctly clients as they connect will get assigned IP’s via dhcp from this pool. Clients connected via vpn will access the servers from an ip in that class C. These will be assigned and reused on an as needed basis.

The class C that is used for your cloud servers was selected at the time that you created your GDCS network. This is currently not changeable, the vm’s will be assigned an IP from this range. This IP will always be assigned to the same server from our system, so the same machine will always get the same IP address. If you remove/recreate a machine it will get a different IP address that will be permanent for the life of that machine.

You can determine what this range is by looking at one of the machines under your network. If you look at the Machine Details section on the right hand side you will notice something like: Private IP: 10.0.0.2, in this case the private /24 for servers is: 10.0.0.0/24.

wayan said 11 months, 2 weeks ago:

Thanks KrisL. I hope this helps others as well.