Spokes v1.3.10

Published at November 27, 2022 ·  5 min read

Spokes v1.3.10 adds new features to some of the existing Admin API endpoints. We also fixed some critical bugs in this release and added some new small features.

This release includes some internal changes that help us build towards a clustering feature that some of our enterprise customers have been asking for.

Admin API Updates

This release now includes support for adding firewall rules for HTTP sites and TCP forwarding rules. Both IPv4 and IPv6 address filtering are supported. IP filtering uses CIDR notation to either allow or drop incoming connections to an HTTP site or TCP application.

When a single host needs to dropped or allowed using the /32 and /128 for the appropiate version of IP.

We have an example request for a TCP forwarding rule in our docs. Below is an example of a TCP forwarding rule that includes the necessary property for adding IP address filtering firewall.

We use the action value allow to filter out all incoming requests except those coming from these two IPv4 addresses.

{
  "ports": [{
    "port": 22123,
    "destination": 127.0.0.1,
    "dstPort": 22,
    "firewall": [
      {
        "sequence": 1,
        "action": "allow",
        "network": "9.18.124.47/32"
      },
      {
        "sequence": 2,
        "action": "allow",
        "network": "128.64.1.34/32"
      }
    ]
  }]
}

We also have examples for HTTP sites in our docs. This is an example for dropping requests from a specific network using CIDR notation and the /24 netmask.

{
  "sites": [{
    "domain": "host-123.spokes.example.com",
    "upsteamURL": "http://127.0.0.1:8080",
    "useLetsEnc": true,
    "redirect": true,
    "firewall": [
      {
        "sequence": 1,
        "action": "drop",
        "network": "25.1.2.0/24"
      }
    ]
  }]
}

Callers can also use the action drop to set rules that will drop incoming requests from the networks or individual hosts they list. A list can be utilized with drop.

Combining the use of firewall rules that use both drop and allow actions will actually result in just the allow rules being applied. By using allow rules, all other traffic that does not met 1 or more of these rules for an HTTP site or TCP application will be dropped.

OpenID Connect Support

OpenID Connect is an HTTPS handshaking protocol that can be used to integrate identificaton and authentication mechanisms between a web applications and an single-sign-on (SSO) provider chosen by an organization.

There’s many resources for learning more about OpenID but this introduction provide some helpful information and links to other resources.

One of our customers asked us to provide this feature and we think it’ll be useful for many organizations that use Spokes and also have a SSO provider that provides authentication for them.

OpenID can be configured manually using the configuration file. An example of the OpenID block is below. The clientID, clientServert and url are all mandatory options. The providerName is also necessary to help identify the provider but it is not a functional property for integrating OpenID Connect.

Restarting Spokes will be necessary when the configuration file is edited manually.

{
	"openID" : {
		"clientID": "",
		"clientSecret": "",
		"url": "",
		"providerName": ""
	}
}

OpenID Connect can also be configured using the web dashboard built into the Spokes web application. Below is a screenshot illustrating the new tab we added to the server configuration page where the OpenID parameters can be input and saved.

Changes are applied dynamically and OpenID can be used immediately when using the dashboard.

Once OpenID is configured and set up a new option for logging in will be presented. The url that is used OpenID configuration is used to forward the user to the sign-on portal for the OpenID provider.

The organization can establishe accessl controls that limit which users that can log into this application and also enforce policies such as using 2FA for authentication.

Once a user authenticates or had authenticated in the past, even with a different application, will be redirected to the Spokes server where we verify the user is authentication with the SSO provider and create a new web session.

Database Defaults in Configuration File

We’re trying to simplify our configuration file with the use of defaults. Below is an example of past configuration files. We use the dataPath to store files such as licenses, web sessions, and typically the databases.

{
	...
	"dataPath": "/var/lib/spokes",
	"database": {
		"path": "/var/lib/spokes/spokes.db"
	},
	...
}

We are removing the need to specify a database property and path in configuration file moving forward.

Spokes will utilize the dataPath as the root directory for databases and create and manage the primary database spokes.db in this path identified with dataPath. The additional databases used for storing connection logs and events will be managed here as well.

If the database object is populated and a custom path is used, Spokes will read and honor those values.

We’re making this change since we want to use the database object to specify more meaningful customizations.

In the future this could poentially be using different databases such as Postgres. We are planning to use a different database to support our clustering feature so will be using new objects stored in the database block to save the parameters for this new database.

Improvements & Bug Fixes

One of our customers let us know that HTTP/1.0 requests were not being responded appropriately. We found that the issue is in our client where we reverse proxy the request and internally that means we rewrite the HTTP/1.0 request into an HTTP/1.1 request.

This breaks the HTTP/1.0 client that originated the request chunked responses can be sent. These responses are not part of the 1.0 spec and causes issues. We’ve implemented a fix for this and now HTTP/1.0 requests are processed correctly.

A deadlock issue was discovered in one of our tunnel maintenance routines in v1.3.9. The issue here is that we added a background routine to check the number of data connections associated to a tunnel session.

If none are found after two sequential checks then the session is terminated. These checks are made every 30 seconds and will terminate a tunnel session prior to the keep-alive check triggering a termination.

A mutex was not properly managed and caused a deadlock in this new maintenance routine. This release fixes the issue.

Thanks!

We appreciate all the inputs and suggestions you’ve sent us! Let us know if we can focus on any other new features or other improvements that we can add to Spokes.

Cheers!