ZeroTier 1.2 Beta Available

mlnews

https://www.zerotier.com/blog/?p=1032

Happy Holidays! After many months of work, we now have a beta version available of ZeroTier 1.2.0. Alongside this release comes a major revision of ZeroTier Central with support for our new rules engine and many changes under the hood to improve reliability.

Your holiday gift to us can be breaking it! … and telling us how, of course. Use GitHub or e-mail to [email protected] to report any problems.

We plan to release 1.2.0 sometime in early to middle January 2017.

Version 1.1.17 is available over at GitHub, and we have pre-built Windows [MSI] and Macintosh [PKG] binaries available as well. The new version of ZeroTier Central is up at my-beta.zerotier.com. Since it’s a beta test site it might be updated or reset at any time, and accounts and networks created there will eventually be cleared. If you want to upgrade your account there, use a Stripe test card number. (Though you won’t see many differences on the beta site.)

What’s new? Let’s see… where to begin…

ZeroTier Core

Rules and Micro-Segmentation: ZeroTier now has a true “enterprise-grade” SDN rules engine. You can read more about its design and capabilities here. Using it requires the new controller code, and the new ZeroTier Central UI provides a simple rules language that makes defining rules a lot easier.
Upstream Federation: ZeroTier now supports the configuration of user-designated upstream nodes that behave like root servers and can provide root functionality if root servers are not reachable. This is the first step toward a more mesh-like mode of operation, and also toward making ZeroTier a viable solution for on-premise SDN by allowing the designation of on-site upstream devices. This feature still needs a bit of work and testing, but you are free to try specifying a designated upstream in local.conf.
Dead Path Detection Improvements: ZeroTier is now even more aggressive at detecting path failure and finding new paths. Dead links should be renegotiated more rapidly.
Security Improvements: Stricter and smarter rate limits have been introduced to harden the core against DOS attacks, and a few other minor issues have been fixed.

ZeroTier One (Mac/Linux/Windows/etc. service)

New Windows UI: We’ve transformed our Windows UI into a task bar app that can be used to quickly join, activate, and deactivate networks. It remembers past networks and lets you easily re-join them.
New Macintosh UI: Our Macintosh UI is completely rewritten and now runs as a task bar app with similar functionality to the new Windows UI. It’s designed to resemble the Macintosh WiFi menu. Think of it as WiFi with unlimited range.
Controller Completely Reworked: The controller has been significantly refactored to use an in-filesystem store of JSON documents instead of SQLite to store network and member configuration and state information. This makes administration and archiving of networks easier and reduces dependencies. The controller also now builds by default in all desktop and server builds of ZeroTier One, which will allow us in the future to include simple “ad-hoc networking” capabilities in client UIs.
Windows High CPU Bug Fix: A major bug reported by many users running ZeroTier alongside Hyper-V that caused high CPU usage should now be fixed. This was a tough one to track down!
Default Route Support in UIs: Windows, Mac, Android, and iOS UIs all now expose global and default route permissions for networks.

ZeroTier Central (web UI)

General UI Improvements: UI sections are now collapsable, and collapsable help is now available beneath each. The look of the members area has been improved, and members now have an advanced settings panel that can be expanded via the little wrench icon next to the member’s ZeroTier address that contains less common configuration options.
Rules Definition Language: You’ll notice a new section called “Flow Rules” below the main network settings area. This contains an editor window where you can write rule sets. We’re working on comprehensive documentation and tutorials for this, but for now you should be able to experiment by following the help and some of the examples at the bottom of this post.
Real-Time Updates: Previous versions of ZeroTier Central required a refresh or reload to see changes. This version streams updates continuously. It even works if more than one person is editing a network. You’ll see changes almost instantly, like Google Docs.
Member Paging: The members list is now paged to improve UI performance on huge networks. We found in testing that more than 25 members per page results in poor UI performance on most systems and browsers. With paging we were able to administrate networks with thousands of members without a “spinning wheel of death” or extreme browser slowdown.
Better Reliability: Under the hood, Central has been refactored to use RethinkDB in high availability cluster configurations instead of PostgreSQL and to automatically manage controller fail-over. The new cluster at my-beta.zerotier.com is a true automatic failover HA cluster instead of a master-backup configuration. This should allow us to keep scaling without performance issues and should prevent issues like the one we experienced on October 27th.

Outstanding Issues Remaining

Documentation: We have a lot of documentation to write!
More Documentation: The live API docs on my-beta are out of date. There have been a few changes, and new fields and capabilities added.
Federation Testing: Federation (designated upstreams) still needs testing and of course documentation!
Further Rules Engine Testing: While the core of the rules engine is well tested, tags and capabilities still need a bit of work. There’s still a bit of UI work remaining in Central as well to fully support these more advanced features in a user-friendly way.
Software Updates: We’re planning a huge overhaul of the software update mechanism for Macintosh and Windows for 1.2.0, but it’s not done yet.
Linux Build Farm 2.0: We’re also planning on creating a new Linux build environment based on qemu-chroot that will allow us to build native binaries for many different Linux architectures and distribution versions using native compilers and test them on “native” (emulated) versions of the target system. This will allow us to offer packages for things like MIPS, ARM64, RISC-V, etc.

There’s also been a tremendous amount of work on the ZeroTier SDK, which we’ll be going into in a separate blog post closer to the actual 1.2.0 release.

I suspect that for most users our rules engine will be the most exciting part of this release. Unfortunately we have yet to produce the kind of comprehensive documentation that will be needed to take full advantage of it. Until then, you can get started by reading the help on my-beta.zerotier.com and also referring to the example below. It shows how to create a simple network that allows IPv4 and IPv6 and how to whitelist TCP connections.

mlnews

Try cutting and pasting this script into your own network on my-beta and testing it out!

# This is an example rule set to illustrate the basic syntax of
# ZeroTier Central's rules editor, as well as a few of the rules
# engine's most important capabilities.

# Central just compiles this into a raw rule set, which in the Central
# UI can be seen to the right of the editor window.

# Drop all Ethernet frame types that are not IPv4 or IPv6
# Note that 'and' is the default for chains of conditions in an action,
# so its use is strictly ornamental.
drop
	not ethertype 0x0800 # IPv4
	and not ethertype 0x0806 # IPv4 ARP
	and not ethertype 0x86dd # IPv6
;

# Senders in every sender-receiver pair will send a copy of the first
# 128 bytes of every packet to a security observer.
tee 128 beefbeef01 not chr inbound;

# Now have receivers do the same. This way one security observer will
# see all sender-side traffic, and another will see all receiver-side
# traffic!
tee 128 beefbeef02 chr inbound;

# TCP whitelisting: allow ssh, http, and https. Note the 'or' modifier.
# Conditions are evaluated in order, so each 'and' or 'or' applies to
# the next condition and is evaluated vs. the result of all previous
# conditions.
accept
	chr tcp_syn
	and dport 22
	or dport 80
	or dport 443
;

# TCP whitelisting: do not allow anything else! Since ZeroTier's filter
# is stateless, we accomplish this by prohibiting the initial TCP SYN
# packet in the TCP three-way handshake. The above whitelist rules allow
# it only for designated ports.
drop
	chr tcp_syn
	and not chr tcp_ack
;

# Accept all other traffic
accept;

Francesco Provino

This is IMHO the most interesting OSS project since many years to date, very nice work!
Can't wait to use the 1.2 in production.