Cloud IPs are “dual-stack” and each one has both both IPv4 and IPv6 addresses that are mapped together as a pair.
Cloud IPs belong to an account and can be mapped to resources on the same account. They are added to an account by “creating” them and billed by the hour until they are removed by “destroying” them.
All cloud servers have a private IPv4 address accessible only from within the Brightbox network. Once a Cloud IP is mapped to a server, IPv4 packets to and from the Cloud IP are translated using NAT to the server’s private IPv4 address.
Outgoing IPv4 connections from the server to the Internet are translated to the first Cloud IP mapped to the server. If no Cloud IP is mapped, a shared IPv4 address is used.
Incoming and outgoing connections to and from the server’s private IPv4 (such as from other servers on the Brightbox network) are unaffected by Cloud IP mappings.
Moving a Cloud IP address will interrupt any established connections using the address.
All cloud servers have a public
/64 IPv6 network allocation. When a Cloud IP
is mapped to a server, IPv6 packets to the Cloud IP IPv6 address are translated
using NAT to the server’s first IPv6 address.
Outgoing IPv6 connections from the server are unaffected by Cloud IP mappings. This allows your server’s native IPv6 addresses to work exactly the same whether a Cloud IP is mapped or not.
Cloud IPs can be mapped to Load Balancers, allowing seamless transition from one server to many.
Load Balancers are inaccessible until a Cloud IP is mapped to them. Once a Cloud IP is mapped to a load balancer, packets to the Cloud IP are translated to the Load Balancers. Load Balancers do not make outgoing connections to the Internet themselves, so no outgoing translation occurs.
Mapping the first Cloud IP to a Load Balancer also triggers the Let’s Encrypt certificate generation.
IPv6 connections to the Cloud IP address are accepted by Load Balancers and turned into a IPv4 connection to the back-end servers.
Cloud IPs can be mapped to Cloud SQL instances. SQL instances are inaccessible until a Cloud IP is mapped to them.
Cloud IPs are actually mapped to an interface on a server. The API accepts a server identifier as the destination and maps the IP to the first available interface.
Cloud IPs are mapped directly to load balancers as they do not have interfaces like Cloud Servers.
The first Cloud IP mapped to a Cloud Server is accessible using the DNS record
srv-xxxxx is the server identifier
gb1 is the region code). The name will return both
to give both the IPv4 and IPv6 addresses.
If no Cloud IP is mapped, the record fails to resolve (returning a
$ host public.srv-abcde.gb1.brightbox.com public.srv-abcde.gb1.brightbox.com has address 126.96.36.199 public.srv-abcde.gb1.brightbox.com has IPv6 address 2a02:1348:ffff:ffff::6d6b:2636
The default reverse DNS of a Cloud IP is currently of the form
cip-109-107-36-145.gb1.brightbox.com. and resolves to both the IPv4 and IPv6
Port Translation can be used to change the destination port of a TCP or UDP connection coming into a Cloud IP. It can be used to emulate having multiple private IP addresses on a Cloud Server. It’s commonly used to host multiple TLS/SSL sites on the same server.
Port Translation applies only to connections coming into a Cloud IP - they do not affect outgoing connections from the Cloud Server.
See the Port Translation guide for a walk through on how to use them.
As with Cloud IP mappings, Port Translation acts on traffic before the Cloud
Firewall. So, for example, if you’re translating
443 on a Cloud IP to port
2443 on a Cloud Server, your firewall rules
would need to allow port
Cloud IPs with port translations can of course be mapped to load
balancers too. You need to specify your load
balancer listeners to use the translated port. So, if you’re translating port
443 to port
2443 then your load balancer needs a listener on port
Last updated: 19 Nov 2018 at 17:39 UTC