Maybe a stupid question, but is there no way, to create a ACL, to make sure, that 2 VM’s can only communicate on port xxx and only to each other ?
I thought so, but looking at the guide, I understand that the ACL is for user and host communication. Not host’s between.
Am I wrong ?
Hi @robert,
This post may help:
Thanks. But that post is around user 2 machine.
I want machine 2 machine.
Does that mean it’s not possible ?
The best way to do fine-grained ACLs is with tagging: https://tailscale.com/kb/1068/acl-tags
Yes but the guide mention tag owners, as a pre req.
I have no users in my setup, only hosts.
Is this still possible. From the guide, I can’t figure It out.
There is always at least one user: the person who created the tailscale account, is authenticating machines, etc. You can set up that user as a tag owner for a particular tag (say tag:server). Then you add both nodes as --advertise-tags=tag:server, and set an ACL that allows tag:server to talk to tag:server.
An important detail is that once you assign a tag to a node, that node no longer has the rights associated with the user who created the node. So even if admin@example.com has the right to connect to anything they want, a tag:server node created by admin@example.com does not have that right unless you set it in the ACLs.
You can use any number of tags to create any level of complexity in your machine-to-machine ACLs.
That makes sense. It’s a lot different, that I first thought. Thanks I will try that 
Great. Do you mind sharing how you thought it would/should work?
off course. Would love to.
My understanding was that the ACL below, would work, something like this.
Note there might be formating errors, but I hope you get the idea.
// Example/default ACLs for unrestricted connections.
{
// Declare static groups of users beyond those in the identity service.
“Groups”: {
“group:example”: [ “user1@example.com”, “user2@example.com” ],
},
// Declare convenient hostname aliases to use in place of IP addresses.
“Hosts”: {
“DS918”: “100.77.49.59”,
“nas”: “100.96.240.40”
},
// Access control lists.
“ACLs”: [
// Match absolutely everything. Comment out this section if you want
// to define specific ACL restrictions.
{ “Action”: “accept”, “Hosts”: [“DS918”,“nas”], “Deny”: [""], “Ports”: [":*"] },
]
}
Ah, I see. Yeah, we should probably extend the syntax to allow hosts
as both source and destination in the ACLs section (although it
wouldn’t look exactly like the above).
We’ll probably get there someday, although ACL tags seem to be a more
user-friendly way to handle these sorts of things in general.
To be honest. it was just my understanding that was off.
Tags would be fine as well, and probably more flexible. I just don’t think it’s 100% clear, that tags also can work, for hosts to hosts.
But that might just be me (as a non native English speaker :-). )
The documentation for tags definitely needs improvement. I think a lot of people don’t quite understand what’s possible with them