<div dir="ltr"><div>If I am understanding correctly, you have a central node, 3 sub nodes, and 3 techs that should be able to access only the node assigned to them?</div><div><br></div><div>and the current issue is that tinc of course tries to help everyone play nice, thus letting tech A access the site C subnet for example.</div><div><br></div><div>simple solution I think.</div><div><br></div><div>each site connects to admin, each site does NOT have the keys or information to connect to each other (note this will cause admin to handle all routing for each site, desired or undesired?)</div><div>also set</div><div><br></div><div>
IndirectData = no <br></div><div>
<pre><span style="font-family:arial,helvetica,sans-serif">Forwarding = kernel<br><br></span></pre><pre><span style="font-family:arial,helvetica,sans-serif">in each tinc.conf<br></span></pre><pre><span style="font-family:arial,helvetica,sans-serif">You will then need to handle all forwarding rules in the firewall setup on admin. and thus admin becomes a single point, you run into a bad actor and you can cut there client off at the firewall, giving you ample time to rotate out their <br></span></pre><pre><span style="font-family:arial,helvetica,sans-serif">public key from their site, if for any reason they hamper this, you can even close there site off via the firewall or by the admin tinc config, by temporarily blanking the offending site's public key until said bad actor is dealt with. <br></span></pre><pre><span style="font-family:arial,helvetica,sans-serif">This setup will give you more fine grained control over how tinc behaves, at the cost of slight increase to kernel cpu overhead, and requiring direct firewall configuration to handle packet flow.<br><br></span></pre><pre><span style="font-family:arial,helvetica,sans-serif">Setting the above config options in each tinc.conf also ensures that if a bad actor attempts to bypass those settings by changing them, they will give themselves away. they will only be able to change the ones on their own site, <br></span></pre><pre><span style="font-family:arial,helvetica,sans-serif">admin being the central point will still have it set for all sites, and force it to be honored, and the other sites will have it set, thus ignoring any attempts the bad site makes to talk to them directly.<br><br><br>
<span style="font-family:arial,helvetica,sans-serif">Forwarding = kernel</span>
can also be replaced with<br>
<span style="font-family:arial,helvetica,sans-serif">Forwarding = off<br></span></span></pre><pre><span style="font-family:arial,helvetica,sans-serif"><span style="font-family:arial,helvetica,sans-serif">on each site, leaving admin "holding the bag" for literally all vpn packet movement</span> <br></span></pre><pre><br><br></pre><pre> </pre>
</div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 2, 2018 at 2:59 PM Parke <<a href="mailto:parke.nexus@gmail.com">parke.nexus@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Oct 2, 2018 at 2:41 PM, Michael Munger <<a href="mailto:mj@hph.io" target="_blank">mj@hph.io</a>> wrote:<br>
> It would be nice to just disable the key at some central point and then<br>
> authentication / encryption / decryption just *break* for that bad actor.<br>
<br>
Depending on your specific network topology, 4 separate VPNs might<br>
very well give you the single break point you want.<br>
<br>
If I was going to try to use Tinc to solve your problem, I would start<br>
by trying the 4 separate VPN approach.<br>
<br>
-Parke<br>
_______________________________________________<br>
tinc mailing list<br>
<a href="mailto:tinc@tinc-vpn.org" target="_blank">tinc@tinc-vpn.org</a><br>
<a href="https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc" rel="noreferrer" target="_blank">https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc</a><br>
</blockquote></div>