What's new?

Find all the latest release information here. If you want to read the release notes, then click this link.

Release 1.9

Release 1.9 adds several new features for increased ease of use and performance. Endpoints may now be imported in bulk to a gateway using a CSV upload, and they can also be moved between Gateways using the orchestrator UI. In addition, multiple users, host agents and endpoints can now be added to groups in one single click using the 'Actions' menu in the orchestrator UI. NAT gateway functionality has been extended to add multiple VLAN support. Other improvements include adding support for endpoints and host agents to use wildcarded DNS names, and improved throughput and lower CPU usage in the Linux host agent.

Release 1.8

In release 1.8 release we have added Egress Policies for managing external network connectivity of Gateway endpoints, support for gateway remote console access from the orchestrator and additional policy control functionality.

Egress policies for endpoint external network access

External network access for endpoints behind a gateway can now be controlled with egress policies. This allows endpoints isolated behind a Gateway to have external access for a software update, for example.

The Egress Policy menu in the Orchestrator allows policies for external network access to be configured on a per-endpoint group basis, where the groups are defined in the Orchestrator Groups menu. Allowed destinations may be defined either by network prefix or by DNS names and the policy may be further controlled by specifying an allowed service. An egress policy may be enabled or disabled from the Orchestrator if the external network access is only temporary.

To learn more about Egress Policies, please click on this link

To learn how to configure an Egress Policy, please click here.

Remote CLI console for Gateways

A CLI console for remote configuration, management and troubleshooting of gateways is available from the orchestrator UI.

This permits an Orchestrator user to remotely login to the CLI console interface of a Gateway and access the console functionality which permits you to view logs and peer connections, configure the Gateway's network interfaces, access the shell and reboot the Gateway.

To learn how to use the Gateway remote CLI console access, click here.

Enabling and disabling of policies

Individual policies may be enabled and disabled from the Orchestrator policy menu page. This makes it quick and easy to manage the applicability of policies and retain them in the Orchestrator even when they are not being applied to a node.

A policy may be controlled by checking or unchecking the Policy Enabled checkbox.

Release 1.7

In the 1.7 release we have added new gateway functionality, more user authentication options and time-based controls of group membership for policy and micro-segmentation.

Gateways can now use a celluar modem as the uplink interface, allowing a Gateway to be deployed where there is no physical internet connection. There is also support for running a Gateway as a container, providing a flexible and lightweight deployment option. It is now possible to authenticate users with the SSO of an identity provider, allowing an enterprise to make use of existing user authentication tools. Time-based policy control can now be enabled by setting the expiry times on group membership.

More information is given below.

Support for using cellular modems as the uplink interface on gateways

The x86 Gateway software appliance can support a cellular uplink interface. This is suitable for Gateway deployments in remote or isolated sites where there is no cabled Ethernet infrastructure, including applications such as in the oil and gas industry, energy and water utilities and mining.

The cellular uplink interface is configured during the software installation onto the x86 platform. If a cellular interface is detected, then it will be offered as a choice for the uplink interface during the installation.

Automatic expiration of group membership

You can configure a member to be removed from a group at a pre-defined time by setting an expiry time on the group member. This applies to any type of group member; users, agents and endpoints. For example, the group expiry allows you to authorize a user to use a policy until a pre-defined end time, at which point the user will be removed from the policy group.

The configurable group expiry is useful in scenarios where a time limited access policy is required, such as temporary remote access to a protected asset for vendors or support engineers.

To learn how group membership expiration is configured, please click on this link.

Authenticate users using an External Identity Provider's SSO

It is possible to configure a user to authenticate using the single sign-on service (SSO) of your your Identity Provider (IdP). This permits third-party MFAs to be used as an alternative to the BlastShield™ Authenticator. This gives flexibility of deployment options so that an enterprise can authenticate BlastShield™ users with the same authenticator that is used for existing corporate applications. BlastShield™ uses OIDC and SCIM to integrate with the SSO.

SSO authentication is a global setting for IdP users. An SSO user will see an option for SSO authentication in the Desktop Client at the start of an authentication session and will not use the FIDO2 or BlastShield™ Mobile Authenticator methods.

SSO based authentication is configured in the Orchestrator, in the 'USER AUTHENTICATION METHOD' settings of the Identity Provider configuration. To learn more about External Identity Providers and authentication options, click here.

Support for running a Gateway as a container

The BlastShield Gateway can run in a containerized environment. The image will run on 32-bit arm, 64-bit arm and x86_64. The Gateway addressing mode must use either source+destination NAT or destination NAT.

Running the Gateway as a container will allow you to use it alongside other apps running in the same environment, allowing for a more cost effective use of resources.

Upgrading a Gateway that is deployed as a container is done by re-deploying the container with a new image.

Containerized deployment using Source and destination NAT

In Source+Destination NAT mode the Gateway is deployed out of line. It can be deployed with minimal changes to the network (no changes to the routing or IP addressing of endpoints are required). The Gateway rewrites destination addresses for all endpoint packets; the packets from the user will have the destination address rewritten from the address configured in the overlay to the IP address entered as the destination. The Gateway also rewrites the source address+port to the gateway's local IP address, such that it appears as if the packet came from the gateway directly. The destination IP address of each endpoint is configured in the Orchestrator.

Containerized deployment using Destination NAT

In Destination NAT mode the Gateway is usually deployed inline to provide endpoint isolation, but it can also be deployed out of line if required (in the latter case it will not provide local isolation or segmentation). The Gateway rewrites destination addresses for all endpoint packets; the packets from the user will have the destination address rewritten from the address configured in the overlay to the IP address entered as the destination. The destination IP address of each endpoint is configured in the Orchestrator.

To learn how to run a Gateway as a container, please click on this link.

Support for running a Gateway in a Kubernetes cluster

The BlastShield Gateway supports running as a container in a K8s cluster. The image will run on 32-bit arm, 64-bit arm and x86_64. The Gateway addressing mode must use source+destination NAT.

Endpoints must be created on the Gateway for the services that you want to expose over the Blastshield™ network. For example, ClusterIP services can be created as endpoints, but you can expose any service that the container itself can get to, even if the service is outside the cluster. Endpoints will not be able to establish connections out over the BlastShield™ network overlay because there is no route to the overlay network.

To learn how to deploy a Gateway in a Kubernetes environment please read this article.