Firmware Version 1.7 Release Notes
Release Date: 28th June 2023
Firmware release 1.7
New Features
Summary | Release |
|---|---|
Support for using cellular modems as the uplink for gateways. | 1.7.0 |
Added option to authenticate users using the IdP's SSO instead of the BlastShield Authenticator app. | 1.7.0 |
The portion of the overlay subnet to allocate endpoint addresses from can now be specified per gateway. | 1.7.2 |
The syslog server port can be specifed by appending ":<port>" to the syslog server address. | 1.7.2 |
It's now possible to run a gateway container in "Destination NAT" mode if the container is launched in "host" networking mode, and the "ENDPOINT_IFACE" environment variable is set. | 1.7.3 |
Added externally sharable provisioning URLs when creating gateways. | 1.7.3 |
Added FCC unlock codes for certain AMIT Wireless modems. | 1.7.3 |
Enhanced filtering in various listview across the orchestrator UI. | 1.7.5 |
Added support for running a containerized Destination NAT gateway on Advantech ICR-4xxx platforms. | 1.7.5 |
Limit the number of items displayed in columns in various listviews in the orchestrator UI. | 1.7.7 |
The tunnel UDP port used by gateways and agents are now configurable. | 1.7.7 |
Bug Fixes
Summary | Release |
|---|---|
Provisioning of IdP users could fail if the user authentication method was set to "SSO Credentials". | 1.7.1 |
Group synchronization from Okta did not work in firmware releases 1.7.0-1.7.1 if the authentication method was set to "SSO Credentials". | 1.7.2 |
The generated openapi.json is now compatible with openapi-python-client. | 1.7.2 |
The state for HA gateways was not represented correctly in the web UI. | 1.7.2 |
Specifying a set of users/agents in the group create/update API calls did not work correctly. | 1.7.2 |
Single NIC gateways running in VMware could experience excessive latency with certain traffic patterns. | 1.7.2 |
All endpoints would not be marked as unreachable when the last gateway went offline in HA setups. | 1.7.3 |
Added exponential back-offs while establishing Orchestrator tunnel. | 1.7.4 |
Running a destination-NAT gateway in a container on some ARM platforms did not work correctly. | 1.7.4 |
Source+destination NAT gateways could get in to a state where unused ports are no longer recycled. | 1.7.5 |
Deleting a node that was used as fallback for a DNS suffix would make the Orchestrator UI render a blank screen. | 1.7.5 |
The "Add new agent" button was not visible in all browsers. | 1.7.6 |
Increased ARP table size for NAT gateways. | 1.7.6 |
Fall back to broadcast ARP probes before marking endpoints as unreachable. | 1.7.6 |
Applying the endpoint configuration to gateways with large number of endpoints could incur packet loss. | 1.7.7 |
Components to be upgraded
New firmware is available for the following applications.
BlastShield™ orchestrator.
BlastShield™ gateway.
BlastShield™ host agent.
BlastShield™ desktop client.
Upgrade instructions
Upgrade your BlastShield™ desktop client.
See the following page for details. Update the BlastShield™ Desktop Client
Upgrade the firmware of the BlastShield™ orchestrator.
See the following page for details.Upgrade the Orchestrator firmware
Upgrade the firmware of the connected BlastShield™ gateways.
See the following page for details.Upgrade the Gateway
Upgrade your BlastShield™ host agents.
See the following pages for details.Upgrade an Agent from the host or Upgrade the Agent from the Orchestrator
Feature Descriptions
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.