What's New in 2.2

2.2.1 HIP tunnelMonitoring

New in this release is the ability to monitor HIP tunnel state changes directly. You can configure a monitor to watch the HIP tunnel to a particular remote Airwall Edge Service or to all trusted peer Airwall Edge Services. As with all monitors, you can create actions on events to alert, change policies, etc.

2.2.1 HIP tunnelstats graph

The tunnel stats introduced in 2.1.5 for Airwall Relays is now available for all Airwall Edge Services. You can see Tx and Rx bits between any pair of Airwall Gateways, allowing you to troubleshoot underlay and overlay connectivity issues.

2.2.1 OpenID Connect

Conductors now support OpenID Connect as an external authentication provider type. You can now use an Identity and Access Management tool such as Okta or OneLogin and integrate Single Sign-On (SSO) or Multi-Factor Authentication (MFA) support.

2.2.1 Multiple Underlay Networks

We now support active/standby multi-homed wired and wireless uplinks, even allowing communication between different ISPs. Multiple Underlay Networks give you more control over which link handles HIP tunnels and which link handles connection to the Conductor.

2.2.1 Multiple Overlay Networks

We now support isolation between port groups. Each overlay port group has its own overlay IP, static routes, and related network settings. Each overlay port group bridges its interfaces, but communication between port groups requires policy.

2.2.1 Port group Configuration

Interfaces appear on the screen with live status information from the Airwall Edge Service. Also, all configurations are committed only after the Airwall Edge Services validates and successfully implements the changes, eliminating disagreement between what is configured in the Conductor and what is actually implemented in the Airwall Edge Service.

2.2.1 Network Objects

You can now use a CIDR (like 10.3.5.0/24) instead of a /32 for a device address. The term Network Objects simply refers to a device that uses a CIDR, and this device can be used wherever you would use any other device, like in device groups and overlay networks. Using network objects, you can allowlist an entire IP network in one click. This should make policy migration from Firewalls and Routers during new deployments much easier. Site-to-site VPN becomes trivial. More specific policies are still supported, so you can create wide policies to open general site-to-site traffic and still segment traffic to Airwall Edge Services.

Negative policies are also supported so you can allow networks or individual IP addresses (like a router) and then create exceptions using a negative policy (like a firewall).

This makes it much easier to manage Airwall Edge Services. Configurations become simpler, shorter, and easier to maintain. For cloud-based Airwall Edge Services, route injection is much simpler because routes are summarized.

2.2.1 User Auth (Windows, Mac, Android; iOS to release shortly)

MacOS and Android now support the user authentication feature introduced in 2.1.3 Windows clients and Airwall Linux Agents. macOS will support this feature in a later release. This feature allows an admin to require client users to provide an additional factor of authentication, currently username and password, to access the overlay for a period of time. Since usernames and passwords are centrally managed, this mitigates concerns about stolen laptops or devices, giving an admin a centrally managed way to approve and deny overlay access.

2.2.1 New shell for Airwall Gateways (airsh)

New in this release is Airwall shell (airsh), a console that replaces the special login user accounts such as like mapconfig, macinfo, and factory reset. The Airwall shell provides tab-completion, inline help, and greatly expands your ability to deploy & configure an Airwall Edge Service directly without going into diagnostic mode.

2.2.1 Overlay Intrusion Prevention Monitor (snort)

Intrusion Prevention allows you to activate any number of pre-defined rule sets. Traffic on the overlay is inspected and if a rule matches, an event is created and sent to the Conductor. You can define event actions based on Snort events.

2.2.1 Airwall Gateway Latency improvements

On certain platforms with a single CPU core, the data plane latency has been reduced from 7ms to approximately 2ms. However, it is important to note that the reduction in latency can vary and depends on concurrency, packet sizes, and various other factors, but in general the latency through an Airwall Edge Service is reduced.

2.2.1 Airwall Relay Performance improvements

In version 2.2, we improved the speed of Airwall Relay traffic using XDP acceleration, allowing traffic to scale even more on your existing hardware.

2.2.1 Full tunnel Windows Airwall Agents and Airwall Linux Agents

In prior releases, an Airwall Agent or Airwall Linux Agent needs policies to opt-in to the overlay network, the default being split tunnel. In version 2.2, an administrator can check a box on the Airwall Agent or Airwall Linux Agent in the Conductor to make the default full tunnel and capture all network traffic into the overlay, allowing for a few exceptions that may be in the underlay like DNS, AD, etc. Please note this is Windows only; macOS clients and Linux Airwall Linux Agents will be available in a future release.

2.2.1 Multiple VLAN Tags per interface

We now support trunk ports, allowing you to have two or more VLANs configured on an interface. Each VLAN tag makes a new sub-interface. For example, VLAN tag 25 on eth0 creates a virtual interface named eth0.25. These interfaces can go into various port groups. East-West policies in the Conductor can be built between devices in different VLANs. Please note that you can still create bridges between VLANs as you did in version 2.1.x and earlier.

2.2.1 MAPv1 no longer supported

Conductor version 2.2 and beyond will no longer be able to manage Airwall Edge Services running 2.0 and earlier. Please note that this requires you to upgrade your Airwall Edge Services to version 2.0 or later your Conductor to version 2.2. Review the upgrade section at the beginning of this document for more information about the recommended upgrade process.

2.2.1 Dual-use port mode deprecated

Dual-use mode for interfaces is no longer available. Using multiple port groups and trunk ports, it is now much easier to implement split-tunnel with East-West policies. You can add the DNS, AD, and other servers as protected devices to an Airwall Edge Service and give them a separate overlay port group connected to the underlay network. In Conductor, you can then give your protected devices policy to the DNS, AD, etc., servers.