What You Can Do With ACSC

Anti-Cloud Secure Connect (ACSC) allows you to build secure, private networks of any shape or size. ACSC makes it easy to connect far-flung offices, datacenters, and users together, just as if they were all on the same local network.

Using the ACSC management UI, you can mix and match and combine any parts of the following examples – enabling you to set up exactly the right access your workforce needs for their data and services.

Core Uses of the ACSC Hub

The ACSC management UI is designed to make it easy to connect remote computers together through a central ACSC hub. By running the network through a central hub, you can quickly and securely manage, filter, and add or revoke access to all the computers on the same private ACSC network.

Remote Access to Office

One common way ACSC is used is to allow remote users access to computers in an office.

For example, if you enroll the laptop of a user who works from home into ACSC, as well as enroll various computers at her office, she’ll be able to access all the computers with ACSC on them as if she were working right next to them in the office.

Connect Multiple Offices

Another common use for ACSC is to connect multiple offices together.

For example, if you enroll the computers at an office in Atlanta into ACSC, and enroll the computers at an office in Boston into the same ACSC network, the computers at the Atlanta office will be able to access services from the Boston office, and vice versa – just as if they were all on the same LAN (Local Area Network).

No Office

ACSC is perfect for a company with a large remote workforce – even when the company has no offices of its own.

You can simply enroll each company computer into the same ACSC network, and each end-user will have access for sharing files, screens, or services among all the computers as if they were all together in the same physical office – no matter where in the world they actually are.

Remote Access to Datacenter

For a company with servers running in the cloud (or in their own on-premises datacenters), ACSC makes it easy to access those remote servers securely.

For each of your servers in the cloud or remote datacenters that you want to allow remote access, enroll them into ACSC, and do the same for the computers of each user who you want to be able access the servers. This will allow each remote user to access the servers in the datacenter, just as if they were sitting right next to the servers themselves.

Extending the ACSC Network

ACSC doesn’t lock you into a strict hub-and-spoke model. You can use the ACSC management UI to extend the core ACSC network in multiple ways through different spokes, enabling you to customize each organization’s network to fit its unique needs.

Single Endpoint

Sometimes you need to connect a computer that’s on an ACSC network to some other remote computer that shouldn’t have access to anything else on the ACSC network.

For example, say an organization has a database that various organization members need to access – and one external third-party contractor needs to access the same database, too. You can enroll the database into the organization’s ACSC network, allowing all the other computers in that ACSC network to access it.

Then you can use the ACSC management UI to add a separate ACSC point-to-point connection just between the database server and the third-party contractor’s workstation. The contractor can install the ACSC agent on his workstation (or employ a standard WireGuard client) to use the point-to-point connection with the configuration you’ve defined.

This enables the single endpoint of the contractor to securely access the database – without having any access to anything else in the organization’s ACSC network. And you can still use the ACSC management UI to manage and monitor the contractor’s access to the database, and to revoke his access at any time.

Datacenter Gateway

Sometimes you need to connect an ACSC network to private services that aren’t on servers you control.

For example, an organization may use services managed by a cloud provider in a cloud datacenter (or may have hardware or virtual machines in their own on-premises datacenters that are fully managed by a third-party service provider).

To enable access to these services from the rest of an ACSC network, you can use the ACSC management UI to add a point-to-site connection between the organization’s ACSC hub and the datacenter network (or an isolated subnet in the datacenter). You can install the ACSC agent on any generic server, VM (Virtual Machine), or container running in the remote datacenter, enabling it to serve as the gateway from the ACSC network to the datacenter.

If you use the default settings for this gateway, it will allow other computers connected directly to the ACSC network to access services in the datacenter network, via SNAT (Source Network Address Translation) applied at the gateway. From the perspective of the datacenter services, connections from the ACSC network will appear to come from the gateway itself – and therefore any network-level access controls (like firewalls) will grant the same level of access to ACSC connections as the gateway itself has.

With the default settings for the gateway, the servers and other services in the datacenter will not be able to connect outbound to the ACSC network. You can, however, use the ACSC management UI to configure the gateway to allow access from the datacenter to the ACSC network; either via SNAT, or by forwarding connections directly without NAT. (However, this does require you to separately configure the routing in the datacenter network to route the private ACSC network address space through the gateway.)

Datacenter Hub

Sometimes you need to connect an ACSC network to servers that don’t have direct access to the Anti-Cloud datacenter.

For example, say you have a few servers in an isolated subnet in a remote datacenter, with no Internet access from the isolated subnet. If you can install the ACSC agent on some other generic server, VM, or container running on a subnet in the datacenter that does have Internet access – and if the isolated subnet is able to access that ACSC server, VM, or container – you can use the ACSC management UI to set up the server/VM/container as subsidiary ACSC network hub for the datacenter.

Then you can use the ACSC management UI to add spokes for each server in the isolated subnet, allowing you to enroll those isolated servers into the ACSC network, connected to the rest of the ACSC network through the datacenter hub. The isolated servers will still be protected against inbound connections from any source other than ACSC, but will be available to initiate and receive connections to and from the other hosts in your private ACSC network.

Chain of Hubs

If you need to extend the ACSC network through several hops to access isolated servers, you can do that, too.

Say, for example, you have several subnets in a datacenter that can access only directly neighboring subnets, but not the Internet, and not all subnets are direct neighbors. You could install the ACSC agent on one server (or VM or container) in each subnet, and use the ACSC management UI to configure them as subsidiary hubs on the ACSC network, with some hubs routed through others.

Then you can install the ACSC agent on all the other servers (or VMs or containers) in the isolated subnets that you want to connect to the ACSC network, and use the ACSC management UI to configure them as spokes to the subsidiary hubs. Every server enrolled in ACSC this way can connect to all the other hosts on the same private ACSC network. (And you can still carve out exceptions to allow certain local traffic to and from an isolated subnet, or to block certain traffic to or from the rest of the ACSC network.)

Hub and Gateway

You can also use the same ACSC agent as both a hub and a gateway.

The same ACSC agent software can serve as a single endpoint, connecting the host on which it is installed to the ACSC network through a hub; or as a hub itself, enabling other ACSC hosts to connect to the main ACSC network through it; or as a gateway, allowing access from the ACSC network to other servers or services not on the ACSC network. You can use the ACSC management UI to control what type of access a host with the ACSC agent installed on it provides – and it can be both a hub and a gateway at the same time.

For example, an organization may need access to several servers at a remote datacenter which you yourself fully manage (like say for a few custom web applications), as well as several managed services to which you only have limited access (like say a managed database service and a managed directory service).

To enable access from the ACSC network to the managed services that you don’t control, you can use the ACSC management UI to add a point-to-site connection between the organization’s ACSC hub and the datacenter network (just like the “Datacenter Gateway” example above). You can install the ACSC agent on any generic server, VM, or container running in the remote datacenter, enabling it to serve as the gateway from the ACSC network to the managed services at the datacenter.

And you can further strengthen the security of the access from the ACSC network to the servers at the datacenter over which you do have full control by installing the ACSC agent on them. You can use the ACSC management UI to configure the ACSC agent on the same sever that you use as the datacenter gateway to also serve as a subsidiary hub for the ACSC network. The other servers at the datacenter with the ACSC agent installed on them can connect directly and securely to the ACSC network through this subsidiary hub.

Separate Networks

You can also use the ACSC management UI to create additional separate ACSC networks for an organization, completely isolated from the organization’s main ACSC network. You may want to do this if you want to apply the security and ease of management that ACSC provides to:

• Connect computers that are geographically close neighbors
• Connect computers that do not have Internet access
• Completely isolate a particular network from all other networks

Point to Point

To connect one single computer directly to another single computer, you can create an isolated point-to-point network.

You might use ACSC to set up a separate network of this type if you want to securely connect one computer to another over an untrusted network. For example, you might use this to connect a laptop to a local file server over a public WiFi network.

Using ACSC like this would prevent other random people from being able to connect to the local server (or to the end-user laptop), while ensuring that all the data transferred between the laptop and server is end-to-end encrypted.

Hub and Spoke

You can use ACSC to build more complicated independent networks, like an isolated hub-and-spoke network.

If you need to connect a bunch of computers together over an untrusted network, you might use ACSC to set up a network of this type. For example, you could use a network like this to allow multiple different end users to connect to multiple different local servers over an untrusted network at a shared office space.

Site to Site

You could also use ACSC to connect two nearby datacenters.

For example, say you have a few managed servers or services in a datacenter at Cloud A, and a few other servers and services in a datacenter at Cloud B in the same geographic region. You can install the ACSC agent on a generic server (or VM or container) at datacenter A, and the ACSC agent on a generic server at datacenter B, and then use the ACSC management UI to connect the two sites through an isolated ACSC network connection.

This would allow services at datacenter A to connect to services at datacenter B, and vice versa, as if they were located together in the very same datacenter.

ACSC Management UI

To set up networks like these in the ACSC Management UI, use the guided connection wizard. On the first page on the wizard, select the type of network you want to set up.

• For any of the Core Uses of the ACSC Hub, use Point-to-Internet
• For an extended Single Endpoint, use Point-to-Point
• For an extended Datacenter Gateway, use Point-to-Site
• For an extended Datacenter Hub, use Hub-and-Spoke
• For an extended Chain of Hubs, use Hub-and-Spoke
• For an extended Hub and Gateway, use Point-to-Site
• For a separate Point to Point network, use Point-to-Point
• For a separate Hub and Spoke network, use Hub-and-Spoke
• For a separate Site to Site network, use Site-to-Site