Dynamic Firewall Rules: Implicit and Explicit Network Access for tiCrypt VMs
A dynamic firewall rule, called a VM access rule in tiCrypt, lets a VM reach one outside server, such as a license server, on chosen ports. It is a narrow exception to tiCrypt's default of blocking all outbound traffic from secure VMs. A super-admin writes the rule once. From then on, tiCrypt opens and closes the path by itself as VMs start and stop and as users open and close access, so nobody has to edit the firewall by hand. Any server and port that no rule names stays unreachable.
- The problem: secure VMs have no outbound network access, yet research software often needs a license server, an activation service or a package repository.
- The global list: the Licensing Servers list opens each server to every VM, all the time.
- What dynamic rules change: a server opens only to the VMs that need it, and only while they need it. Everything else stays blocked.
- Scope: one rule covers chosen VMs, one server, and the ports and protocol you set.
- Implicit rules: always on while the VM runs. Example: a license server the software checks at start-up.
- Explicit rules: off until a user opens access, then closed again after the time limit the rule sets. Example: a vendor's activation server used once a year.
- Mechanism: nftables on the firewall host. The backend sends the full list of allowed VM-to-server connections to the
ticrypt-nftservice every 5 minutes and right away after any change. Entries expire after 10 minutes unless renewed, so access fails closed. - Who does what: super-admins create rules. Users who can see a VM open and close access on its explicit rules. Only rule setup is logged.
Why VMs need dynamic rules
Secure VMs in tiCrypt have no outbound network access by default. Any path out of a VM is a path data can leave by, so tiCrypt blocks them all. For the full isolation model, see How tiCrypt Isolates Virtual Machines at the Network Level.
Research software still needs a few outside services: a license server for a statistics or engineering package, an activation service, an institutional package repository. The established way to allow them is the Licensing Servers list, and that list is global: every entry opens its server to every VM in the deployment. A global list has two costs:
- Scope: a license server that one project pays for becomes reachable from every VM, including VMs of projects that have no reason to talk to it. Each new entry widens the network surface of the whole deployment.
- Time: an entry stays open around the clock, whether or not anyone is using the software, until an administrator deletes it.
VM access rules address both. A rule names the VM configurations it serves, so only their VMs gain the path. An explicit rule adds a time limit, so the path exists only while a person has asked for it.
Three allow lists, one firewall
tiCrypt keeps its network exceptions in one nftables table on the host that routes traffic between the secure VM network and the rest of your network. The ticrypt-nft service fills that table with what the tiCrypt backend sends. Three sets do the work:
| Set | What it allows | Filled from | Entry lifetime |
|---|---|---|---|
ti_proxy | A user's device into one VM, on port 22 only | Each user connection to a VM | 15 minutes to connect; an open connection continues |
ti_alist, the global allow list | Every VM out to a server | The Licensing Servers table | Until the entry is deleted or deactivated |
ti_alist_vm, the per-VM allow list | The VMs of a rule's configurations out to the rule's server | The VM Access Rules table | 10 minutes, renewed every 5 minutes while the rule applies |
Both tables are in Management > Virtual Machines.
Firewall host, table "ticrypt"
┌──────────────────────────────────────┐
User device ─┤ ti_proxy device to VM, port 22 ├─> VM
├──────────────────────────────────────┤
Secure VM ───┤ ti_alist every VM, global list ├─> Server
│ ti_alist_vm one VM, per-VM rules │
│ no match dropped │
└──────────────────────────────────────┘
Traffic from a secure VM to the outside passes only if it matches the global list or the per-VM list. VM access rules fill the per-VM list.
What a rule contains
The following table describes the fields of a VM access rule.
| Field | Description |
|---|---|
| Name | A label for the rule. Users see it in the Network access card and when they open access, for example "Open access: Vendor activation". |
| VM configurations | Every VM configuration whose VMs the rule serves. |
| Server | A domain name or IPv4 address, such as license.example.edu or 10.0.0.5. IPv6 addresses are not supported. |
| Network access | The protocol, TCP or UDP, and one or more ports or port ranges, such as 1688 or 27000-27010. A rule has one protocol, so a server that needs both takes two rules. |
| Access type | Always allowed creates an implicit rule. Time-limited access creates an explicit rule. |
| Maximum access time | Explicit rules only: the longest time, in minutes, a user can open access for. |
Why rules name configurations, not VMs
A VM configuration is not a running VM. The configuration is the saved definition a researcher starts VMs from, and each start can produce a VM with a new ID and a new IP address. A rule written against one VM would stop applying the first time that VM restarted. A rule written against the configuration follows every VM started from it: when a VM starts, tiCrypt finds the rules that name its configuration and adds the VM's current address to the per-VM list.
A rule selects VMs by configuration only. The configuration's project, team and owners do not widen or narrow a rule. To cover every VM a project uses, list each of the project's configurations in the rule.
Implicit rules: always allowed
An implicit rule allows traffic to its server whenever a VM is running from one of its configurations. Nobody opens or closes anything. The rule is implicit because the permission comes from the VM's state alone: a VM that runs from a listed configuration has the access, and a VM that stops loses it.
Use an implicit rule when the software in the VM needs the server in every session and cannot work without it, such as a license server the application checks at start-up.
The implicit workflow
- A super-admin creates the rule in Management > Virtual Machines > VM Access Rules, sets Access type to Always allowed, and selects the configurations.
- A user starts a VM from one of those configurations. The VM can reach the server about 30 seconds after someone connects to it, or at the next refresh if that comes sooner. Refreshes run every 5 minutes by default.
- While the VM runs, tiCrypt renews the access at every refresh. No one needs to act.
- When the VM stops, its address leaves the per-VM list at the next refresh.
In the configuration's detail panel, the Network access card lists the rule with Always allowed next to it, so researchers can see which outside servers their VM can reach.
Explicit rules: time-limited access
An explicit rule is closed by default. A user opens it for one VM configuration, for a number of minutes up to the rule's Maximum access time, and it closes again when that time runs out. The rule is explicit because a person has to ask for the access each time, which turns a standing exception into a deliberate, bounded one.
Use an explicit rule when the VM needs the server only for a specific task, or when the destination is sensitive enough that it should be closed whenever nobody needs it.
The explicit workflow
- A super-admin creates the rule, sets Access type to Time-limited access, and enters a Maximum access time in minutes.
- A user who can see one of the rule's configurations opens access from any of these places:
- Open access: rule name among the configuration's actions.
- The Open access button next to the rule in the Network access card of the configuration's detail panel.
- Open access on the rule in Management > Virtual Machines > VM Access Rules.
- In the Open access dialog, the user selects the VM configuration and enters an Access time (minutes). The field starts at 60 minutes, or at the rule's maximum if that is lower, and accepts no more than the maximum.
- tiCrypt records who opened access and until when, and sends the updated per-VM list right away. The VM running from that configuration can now reach the server.
- To end access early, the user selects Close access in any of the same places. Closing takes effect at once, and closing access that is already closed does nothing.
- Otherwise, access ends at the first refresh after the time runs out, so up to 5 minutes later with the default settings.
How open access behaves
- Access belongs to the configuration, not to the user: when one owner opens access, the VM running from that configuration has it, whoever is connected to the VM. Any user who can see the configuration can close it again.
- Opening again sets a new end time: opening access that is already open replaces its end time with one counted from now, which can extend or shorten it.
- Access can be opened before the VM starts: the clock starts when access is opened, not when the VM starts. Access opened for a configuration also carries over a restart of its VM within the window.
- Open connections are not cut: the firewall lets established connections continue, so closing access or letting it expire refuses only new connections. A program that holds one long connection to the server keeps it until the program disconnects.
Implicit and explicit side by side
| Implicit | Explicit | |
|---|---|---|
| Shown in the interface as | Always allowed | Time-limited access |
| Default state | Open while a VM runs from a listed configuration | Closed |
| Who acts | Nobody, once a super-admin creates the rule | A user who can see the configuration opens access |
| How long access lasts | As long as the VM runs | Up to the rule's maximum access time, per opening |
| Access ends when | The VM stops, the configuration leaves the rule, or the rule is deleted | Time runs out, a user closes access, the configuration leaves the rule, or the rule is deleted |
| Best for | Services the software needs in every session | Destinations needed only for a task, or that should stay closed when idle |
Examples
Server names, ports and times in these examples are illustrative. Use the values your software vendor documents.
Implicit rule examples
- A license server that one project pays for: a department licenses an engineering package whose license manager listens on TCP
27000-27010, and only the department's project uses it. An implicit rule named "Engineering license" lists that project's configurations, so their VMs check out licenses at start-up and VMs of other projects cannot reach the server. - A license manager that needs TCP and UDP: some license managers listen on the same port over both protocols, for example port
1947. Create two implicit rules with the same server and configurations, one for TCP and one for UDP. - GPU software licensing: software on GPU configurations must reach a license service on TCP
443in every session. An implicit rule for the GPU configurations keeps CPU-only VMs off that path. - A reference service one study depends on: a cohort study's analysis code queries an institutional terminology or geocoding service in every run. An implicit rule for the study's configurations makes the service reachable from those VMs and from no others.
Explicit rule examples
- Software activation and renewal: an analysis package must contact the vendor's activation server once after installation and again at each annual renewal. An explicit rule named "Vendor activation" with a maximum of 30 minutes lets the researcher open access, activate, and close access again. For the rest of the year the server is unreachable.
- Installing packages from an institutional mirror: researchers occasionally install R or Python packages from the institution's package mirror on TCP
443. An explicit rule with a 60-minute maximum lets them open access for an installation session. For a mirror on the NFS share that needs no network path at all, see Installing Python Packages in Air-Gapped Research VMs. - A scheduled data pull from a partner: a data provider makes an extract available on its server for a set window. An explicit rule for the researcher's configuration, with a maximum of 120 minutes, lets the researcher open access, retrieve the extract, and close access.
- A shared license with few seats: a costly license server is shared with other departments, and the institution wants this project's VMs to connect only during working sessions. An explicit rule with a maximum of 480 minutes lets researchers open access for a working day.
Combining both on one configuration
One configuration can need both kinds. A statistics workstation configuration might carry:
| Rule | Type | Server and ports | Maximum access time |
|---|---|---|---|
| "Statistics license" | Implicit | license.example.edu, TCP 27000-27010 | None |
| "Vendor activation" | Explicit | activate.vendor.example, TCP 443 | 30 minutes |
| "Package mirror" | Explicit | mirror.example.edu, TCP 443 | 60 minutes |
The license works in every session with no action from anyone. Activation and package installation each need a deliberate, time-limited opening. In the configuration's detail panel, the Network access card shows all three: the license as Always allowed, the other two with Open access and Close access buttons.
Once a VM can reach a server, software in the VM can send data to it as well as receive from it. Treat every rule, and especially one toward a server outside your institution, as a data egress decision. Prefer explicit rules with short maximum times for such servers, and use tiCrypt's own ingress paths for bulk data where you can. For more information, see Getting Data Into the Enclave.
When to use the global list instead
Use the global list when every VM in the deployment needs the server. A Windows KMS host that activates every Windows VM, or a Remote Desktop license server that every Windows VM uses, belongs in Licensing Servers, not in a rule that lists every configuration. Such a rule would also need updating each time someone creates a configuration; the global list does not.
Choosing a mechanism
- Every VM needs the server in every session: add it to Licensing Servers.
- Some configurations need the server in every session: create an implicit rule.
- Some configurations need the server for a task, or it should be closed when idle: create an explicit rule.
- The goal is moving data into tiCrypt: use the Vault, an inbox or an SFTP connection rather than a network path.
Who can do what
| Action | Who |
|---|---|
| Create, edit and delete rules | Super-admins only. No permission grants this to other roles. |
| See rules | Super-admins see every rule. Other users see only the rules that name a configuration they can see, and each of those rules lists only those configurations. |
| Open and close access on explicit rules | Anyone who can see the configuration: its owners and co-owners with View their VM configurations and those shared with them, users with View all VM configurations, and super-admins. |
View all VM configurations lets its holder open access for every configuration that an explicit rule names. Grant it with that in mind.
tiCrypt logs only the setup of rules: creating, editing and deleting them. Opening and closing access is not logged.
How tiCrypt keeps the list current
tiCrypt never edits the per-VM list entry by entry. The backend computes the whole list from three inputs: the rules, the address of each VM running from a configuration the rules name, and the access users have opened on explicit rules that has not yet run out. It sends the complete list to ticrypt-nft, which swaps it into the firewall in one step. The backend sends the list:
- every 5 minutes;
- right away after a rule is created, edited or deleted, and after access is opened or closed;
- about 30 seconds after a user connects to a VM, so a newly started VM does not wait for the next refresh;
- whenever
ticrypt-nftconnects or reconnects to the backend.
Each entry lives 10 minutes in the firewall unless the next list renews it. The design fails closed: if the backend stops sending lists, per-VM access lapses within 10 minutes instead of staying open.
Server names
A rule can name its server by domain name. ticrypt-nft resolves the name on the firewall host, pins it to one IP address, and opens that address. It also writes the name and address to the hosts file of the DNS service the VMs use, dnsmasq-secure, so software in the VM resolves the name to the same address the firewall allows. If a later lookup fails, the name keeps its last address, so a DNS outage does not close access that was open. A name that has never resolved is left out until it resolves.
Changes to rules and configurations
- Editing a rule: a change to its server, ports or configurations takes effect at once.
- Deleting a rule: any access opened for it ends at once.
- Changing the access type: a rule changed from explicit to implicit drops any open access, since it no longer needs any. A rule changed from implicit to explicit stays closed until a user opens access.
- Deleting a VM configuration: tiCrypt removes it from every rule and closes any access opened for it. A rule left with no configurations stays in the table so a super-admin can review and delete it.
Turning dynamic rules on
Dynamic rules need three pieces, all configured by a system administrator:
- The tiCrypt backend: version 3.16.0 or later, with
nft.enabled = truein the tiCrypt VM service configuration. It isfalseby default.nft.alist-vm-refreshsets how often the per-VM list is sent,5 minutesby default; keep it well under the 10-minute entry lifetime. Withnft.enabledon, Licensing Servers entries fill the global allow list as well. - The
ticrypt-nftservice: with itsticrypt-firewallruleset, on the host that routes VM traffic./etc/ticrypt/ticrypt-nft.tomlsets the per-VM entry lifetime ([alist] vm_lease,10mby default) and the window for opening a user connection ([proxy] timeout,15mby default). dnsmasq-secure: loading the hosts files thatticrypt-nftwrites, withaddn-hosts=/var/lib/ticrypt-nft/dnsmasqin its configuration.
The VM Access Rules table appears in Management only when the backend supports the feature. To see what the firewall currently allows, run nft list set ip ticrypt ti_alist_vm on the firewall host; each element carries a comment with the server names it was granted for. ticrypt-nft logs follows the service log.
Backend support for VM access rules shipped in tiCrypt backend 3.16.0 on 20 October 2026. The VM Access Rules screens and the nftables version of ticrypt-nft are in development for an upcoming release.
Related documentation: Licensing Servers | VM Configurations | tiCrypt VM Service Configuration | How tiCrypt Isolates Virtual Machines at the Network Level