What's New in 2.2

2.2.1 HIP Tunnel Monitoring

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 HIP Service or to all trusted peer HIP Services. As with all monitors, you can create actions on events to alert, change policies, etc.

2.2.1 HIP tunnel stats graph

The tunnel stats introduced in 2.1.5 for HIP relays is now available for all HIP Services. You can see Tx and Rx bits between any pair of HIPswitches, 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 Portgroup Configuration

Interfaces appear on the screen with live status information from the HIP Service. Also, all configurations are committed only after the HIP Service validates and successfully implements the changes, eliminating disagreement between what is configured in the Conductor and what is actually implemented in the HIP 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 whitelist 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 HIP 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 HIP Services. Configurations become simpler, shorter, and easier to maintain. For cloud-based HIP 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 HIPservers. OS 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 HIPswitches (hipsh)

New in this release is HIPshell, a console that replaces the special login user accounts such as like mapconfig, macinfo, and factory reset. HIPshell provides tab-completion, inline help, and greatly expands your ability to deploy & configure a HIP 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 HIPswitch 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 a HIP Service is reduced.

2.2.1 HIP relay Performance improvements

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

2.2.1 Full tunnel Windows clients and HIPservers

In prior releases, a client or HIPserver 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 client or HIPserver 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 HIPservers 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 HIP Services running 2.0 and earlier. Please note that this requires you to upgrade your HIP 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 a HIP 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.