Sebastian Goscinski

Implementing Fine-Grained Network Segmentation with Tailscale ACLs

Sebastian Goscinski's photo
Sebastian Goscinski
·

4 min read

In recent posts, we’ve explored the fundamentals of Tailscale and how it can be integrated with pfSense, as well as an introduction to basic access control configurations. Building on that knowledge, it’s time to dive deeper into creating fine-grained network segmentation using Tailscale’s Access Control Lists (ACLs) for ultimate control over network traffic and user permissions.

Proper segmentation is key in a well-architected network for both security and efficiency. In this article, we'll explore multiple scenarios showing how Tailscale ACLs can be used to carve out precise access for various user roles and resources within your network.

Scenario 1: Hosting Multiple Services on a Single Device

The Challenge: You have a server hosting multiple services, such as a web server on port 80 and an SSH service on port 22, and you want to grant access to these services to different user groups.

The ACL Strategy:

  • Assign tags to the server’s services, separating the web service from SSH.

  • Define user groups for web developers and system administrators.

  • Create ACL rules to segment access.

Example Configuration:

{
  "Groups": {
    "group:web-devs": ["dev1@example.com", "dev2@example.com"],
    "group:sysadmins": ["admin@example.com"]
  },
  "Tags": {
    "tag:web": ["100.101.102.1"],
    "tag:ssh": ["100.101.102.1"]
  },
  "ACLs": [
    {
      "Action": "accept",
      "Users": ["group:web-devs"],
      "Ports": ["tag:web:80"]
    },
    {
      "Action": "accept",
      "Users": ["group:sysadmins"],
      "Ports": ["tag:ssh:22"]
    }
  ]
}

In this example, only web developers have access to the web server, while only system administrators can SSH into the machine.

Scenario 2: Granular Access within the Company’s Departments

The Challenge: The company has multiple departments, such as HR, Engineering, and Sales, requiring access to specific resources without exposing them to the entire network.

The ACL Strategy:

  • Create tags for resources belonging to each department.

  • Define user groups per department.

  • Write ACL rules to establish access boundaries.

Example Configuration:

{
  "Groups": {
    "group:hr": ["hr@example.com"],
    "group:engineering": ["eng@example.com"],
    "group:sales": ["sales@example.com"]
  },
  "Tags": {
    "tag:hr-resources": ["100.201.202.1"],
    "tag:engineering-resources": ["100.201.202.2"],
    "tag:sales-resources": ["100.201.202.3"]
  },
  "ACLs": [
    {
      "Action": "accept",
      "Users": ["group:hr"],
      "Ports": ["tag:hr-resources:*"]
    },
    {
      "Action": "accept",
      "Users": ["group:engineering"],
      "Ports": ["tag:engineering-resources:*"]
    },
    {

      "Action": "accept",
      "Users": ["group:sales"],
      "Ports": ["tag:sales-resources:*"]
    }
  ]
}

This configuration ensures that each department only accesses its designated resources.

Scenario 3: Time-Limited Access for Temporary Project Teams

The Challenge: You have teams working on short-term projects needing temporary access to certain parts of the network.

The ACL Strategy:

  • Use Tailscale’s ephemeral key feature to create time-limited access for devices.

  • Assign temporary tags correlating with project resources.

  • Define ACL rules that expire along with the ephemeral keys.

Example Configuration:

Create ephemeral keys manually in the Tailscale admin panel and apply the following ACLs.

{
  "Groups": {
    "group:project-alice": ["temporary-key-alice@example.com"],
    "group:project-bob": ["temporary-key-bob@example.com"]
  },
  "Tags": {
    "tag:project-resources": ["100.301.302.2"]
  },
  "ACLs": [
    {
      "Action": "accept",
      "Users": ["group:project-alice"],
      "Ports": ["tag:project-resources:8080"]
    },
    {
      "Action": "accept",
      "Users": ["group:project-bob"],
      "Ports": ["tag:project-resources:8080"]
    }
  ]
}

The ephemeral keys expire based on the configuration you set, which automatically revokes the associated device’s network access.

Scenario 4: Enforcing Different Access Levels for the Same User

The Challenge: A user needs different levels of access depending on whether they're on a corporate or personal device.

The ACL Strategy:

  • Tag devices accordingly as corporate or personal.

  • Define ACL rules to grant broad access from corporate devices and more limited access from personal devices.

Example Configuration:

{
  "Groups": {
    "group:user-jane": ["jane@example.com"]
  },
  "Tags": {
    "tag:jane-personal": ["jane-personal-device"],
    "tag:jane-corporate": ["jane-corporate-device"]
  },
  "ACLs": [
    {
      "Action": "accept",
      "Users": ["group:user-jane"],
      "Ports": ["tag:jane-corporate:*"]
    },
    {
      "Action": "accept",
      "Users": ["group:user-jane"],
      "Ports": ["tag:jane-personal:443"]
    }
  ]
}

With this setup, Jane has unrestricted access from her corporate device, while her personal device is limited to HTTPS traffic.

Conclusion

Tailscale’s ACL system offers unrivaled flexibility for network segmentation and access control, proving indispensable in a modern, dynamic network environment. When deploying your ACL configurations, always validate and test each rule to ensure they align with your intended security policies and access requirements.

Effective use of ACLs enhances both security and productivity, and with Tailscale, setups that were once complex and cumbersome are accessible and manageable. By engaging with scenarios like these, you can adapt solutions to fit your unique network topology and organizational needs.

For more advanced tips and strategies on managing a secure and efficient network, keep connected with sebiweise.dev.

tailscalevpnnetworking