Migrating from the Blue Cedar Gateway to the Blue Cedar Connect Gateway Generation 2 

The Blue Cedar Gateway (previously known as the Atlas Gateway) will be End of Life (EOL) on June 30, 2021. Customers must migrate to the Blue Cedar Connect Gateway Generation 2 as technical support will no longer be available after this date. 

The Blue Cedar Gateway was available in two form factors: as a physical 1U rack hardware appliance and as a virtual appliance. Both form factors operate using the Blue Cedar OS, a proprietary operating system that runs atop a custom Linux kernel. The only functional difference between the two form factors are as follows. 



Virtual ApplianceHardware Appliance

Concurrent connections

500 per virtual appliance100,000 per hardware appliance
UpgradesRequires a new .ova file that replaces the previous virtual appliance. In-place upgrades with a new software patch


What’s New in the Blue Cedar Connect Gateway Generation 2

A summary of the key new features of the Blue Cedar Connect Gateway Generation 2 are provided below. View this article for a detailed feature comparison of the Blue Cedar Gateway versus the Blue Cedar Connect Gateway Generation 2.

Highlights

  • Use of the IKEv2 protocol, which provides increased performance and stability
  • A new TLS-based control channel for end-user authentication
  • NAT support for client IP addressing in addition to DHCP and Static IP address pools
  • Deployable on standard CentOS or RedHat Linux operating systems.
  • Support for OAuth authentication provider

What do I need to know to migrate

Deployment

The Blue Cedar Connect Gateway Generation 2 is provided as a standard .ova virtual machine file. This can be deployed via a hypervisor product such as VMware. Additionally this new Blue Cedar Connect Gateway Generation 2 is deployable on cloud services such as Microsoft Azure or Amazon Web Services.

External port changes

The Blue Cedar Gateway operated solely over port UDP 4500 on the external (public) interface. This port handled all authentication as well as IPsec traffic. The new Blue Cedar Connect Gateway Generation 2 has a new control channel that operates over TLS on port 443. Once the user is successfully authenticated, connectivity transitions to IPsec via UDP port 4500. Additionally UDP port 500 is required.

Management interface changes

The previous generation of the gateways had a dedicated management interface that was used solely for SSH/SCP access to the gateway. The Blue Cedar Connect Gateway Generation 2 has merged the management and private interface into a single interface. All management access to the Blue Cedar Connect Gateway Generation 2 is now performed over the private (internal) interface of the gateway. This may require you to adjust internal firewall rules to now allow TCP traffic over port 22 (default port) to reach the private interface of the gateway rather than the previous management interface.

Capacity and load balancing

If you are migrating from a Blue Cedar Gateway hardware appliance, then you need to scale out multiple Blue Cedar Connect Gateway Generation 2 virtual appliances to accommodate your current capacity loads. In order to migrate successfully you need to properly load balance your new gateways to handle the incoming traffic volume. There are specific load balancing requirements that need to be configured to successfully allow clients to connect to the Blue Cedar Connect Gateway Generation 2.

  • Use long lived source IP stickiness

    Round robin traffic distribution can be used for net new connections from a client source IP address, however, due to the new control channel mechanisms implemented in the Blue Cedar Connect Gateway Generation 2, you must ensure that returning traffic is redirected back to the original gateway it first connected to. If a client is directed to a new gateway after the user authenticates then that user's authorization is no longer valid on the second gateway.

  • Active / Active Data Centers are not supported

    If you are leveraging a global load balancer for traffic distribution, then we advise working with an active/passive data center model. Since global load balancers do not generally support IP stickiness, the risk of a client being distributed to an alternate data center is increased. This would not allow for successful authentication to IPsec data connectivity transitions. 

  • Client addressing

    If you currently have a large pool of static IP addresses or several pools of addresses on your current Blue Cedar Gateway hardware appliance, you may have to break those pools down into smaller groups for use on multiple virtual gateways.

    It is important to note that this could have an impact on your current network routing rules. Your routing rules may need to be adjusted to ensure that any traffic entering your network as a client from that IP address pool returns back to the originating gateway.

Note: The new Blue Cedar Connect Gateway Generation 2 supports NAT addressing. This can be used in place of static IP addressing to reduce your network rules and allow you to route traffic based solely on the private interface IP addresses of your gateways.

Certificates and trust

The Blue Cedar Connect Gateway Generation 2 now provides connectivity trust via traditional SSL (TLS 1.2) certificates which require slightly different parameters on how to prepare the proper HTTPS certificates for use on the Blue Cedar Connect Gateway Generation 2. 

Configuration

Configuration files from the previous gateway are not compatible with the new Blue Cedar Connect Gateway Generation 2. The new gateways need to be configured as net new installs. However we recommend copying values from your previous configuration to ensure compatibility with your network design. 

If you would like to engage Blue Cedar Professional Services to assist you with your migration, please contact us at support@bluecedar.com