Shered nodes and quarantine

Hello, I’m reading the docs and I’ve found this:

In the future we will provide an option to disable quarantining for full bidirectional communication.

I’m very interested in this feature, Is there any rough timeline?

We’ve actually been waiting for someone to ask for this feature :slight_smile: Many people use sharing but the desire to remove quarantining is apparently very rare. This makes sense is people are primarily sharing servers. As a result though, the ability to turn off this protection has dropped fairly low on our priority list.

A workaround is to share in the other direction instead. Would that help?

Not sure, please help me wrap my head around this.
Two networks:

  • OPS with one shared node: OPS-node1. That’s the one which needs bidirectional connections, it is a Zabbix server.
  • CLIENT-A: with two nodes (CLIENT-A-node1 and CLIENT-A-node2). These nodes will need to talk with OPS-node1. Some checks are initialized by CLIENT-A-node* and others are initialized by OPS-node1.

Now as a workaround I can share both ways and probably I’ll get away with reduced segmentation.

But what happens when another network (CLIENT-B) comes into play. I would need to share OPS-node1 to CLIENT-B network and share CLIENT-B-node1 to OPS network.

Would shared CLIENT-A nodes see shared CLIENT-B nodes? I would say no, because only OPS-node1 is shared to CLIENT-B.
I guess I’m asking about cross-sharing, is it even possible to share a shared node? I hope it’s not too confusing :slight_smile:

Currently we do not have this feature , We have logged the feature request for the same , please subscribe to Allow cross-sharing using the Tailscale node sharing. · Issue #1946 · tailscale/tailscale · GitHub for future update.

Hi Michal,

Got it, you have a server that needs to both accept incoming connections and make outgoing connections. Right now this isn’t supported when using node sharing.

Is there a way to get around this? Generally speaking, if shared nodes can only go in one direction, it is more difficult to execute “lateral attacks” from one network to another. That is, if someone on CLIENT-A is able to break into OPS-node1, then OPS-node1 could then be used to break ingo CLIENT-B. If OPS-node1 can only either accept connections (outgoing spread prevented) or make outgoing connections (incoming attacks prevented), lateral movement is greatly slowed down.

That said, you are correct that if you share OPS-node1 into both CLIENT-A and CLIENT-B networks, the two networks would not be able to see each other directly. OPS-node1 would be able to see both.

I must say that the more I think about it and experiment with sharing+ACLs, the more I like the way it is right now with only one-way sharing.