<div dir="ltr">Agreed , thanks Graham. My purpose is just for inter-site connectivity in order to gain access to our central file server. And like you said, it depends on the assets trying to protect. I think for my purpose a reputable VPS provider will serve purpose, and I would just need to ensure that my remote sites are locked down in an event of attempted breach. Thanks all for inputs.</div><div id="DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><table style="border-top:1px solid #aaabb6;margin-top:30px">
        <tr>
                <td style="width:105px;padding-top:15px">
                        <a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail" target="_blank"><img src="https://ipmcdn.avast.com/images/logo-avast-v1.png" style="width: 90px; height:33px;"></a>
                </td>
                <td style="width:470px;padding-top:20px;color:#41424e;font-size:13px;font-family:Arial,Helvetica,sans-serif;line-height:18px">This email has been sent from a virus-free computer protected by Avast. <br><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail" target="_blank" style="color:#4453ea">www.avast.com</a>
                </td>
        </tr>
</table><a href="#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"></a></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr">Regards<br>Yazeed Fataar<br></div><a href="mailto:yazeedfataar@hotmail.com" target="_blank"></a></div></div></div></div></div>
<br><div class="gmail_quote">On Sun, Jan 24, 2016 at 4:05 PM, Graham Cobb <span dir="ltr"><<a href="mailto:g+tinc@cobb.uk.net" target="_blank">g+tinc@cobb.uk.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 24/01/16 12:19, Yazeed Fataar wrote:<br>
> I cannot use dynamic dns , the remote sites connect through 4G LTE and<br>
> get assigned "Private Addresses" that are NATd to a Public Address. The<br>
> LTE clients can only make connections outward to the Internet and<br>
> features such as PAT and Dynamic DNS will not work. Therfor for these<br>
> remote sites I need a Central Server Located on Internet to peer with in<br>
> order for the Site to Site connection to work. Tinc works perfectly in<br>
> this and I have tested it thoroughly, I just have concerns now over the<br>
> Central Server which holds all the tinc configuration data.<br>
<br>
</span>The issue with all security is to understand what is the threat (who are<br>
you trying protect from), how long do you need to resist the threat, and<br>
how much is the protected asset worth (i.e. how much are you willing to<br>
spend to protect it).  If you are REALLY serious about your question,<br>
and are willing to spend money to fix it, you need to pay a security<br>
consultant to come up with the required design that trades these three<br>
off in the way you choose.<br>
<br>
That said, here are some free thoughts (and I am no expert) - which are<br>
worth all that you are paying for them :-)<br>
<br>
In my experience, in practice, a paid-for VPS, from a reputable<br>
supplier, is secure enough for most purposes.  Even small businesses.  A<br>
medium-sized business might prefer a physical co-lo server in a locked<br>
cage.  In either case, you have a contract with the provider, they have<br>
a policy (such as the Digital Ocean policy you quoted), and they have a<br>
reputation to uphold. Of course, that will not protect you from state<br>
actors (police, spies, etc), and it won't protect you against someone<br>
who is willing to bribe the VPS staff.  On the other hand, I have run<br>
tinc with a VPS central node for many years (probably more than 10) and<br>
have never seen any unexpected node appear (of course, I can't tell if<br>
someone is decrypting all my traffic).<br>
<br>
If you really want to avoid having the keys on the central server, you<br>
could arrange to run tinc on a server you control (e.g. at home) and<br>
forward all the (encrypted) tinc traffic from the central server to it.<br>
 You could, for example, make an outgoing SSH connection from your home<br>
node to the central server with port forwarding, so that all traffic to<br>
the tinc port on the central server gets forwarded to the tinc port on<br>
your home server.  You would have to write some scripts to make sure the<br>
connection was reconnected whenever it failed, and performance would<br>
probably be very poor, but it would avoid the keys being on the central<br>
server.<br>
<br>
But, is it worth it?  If you are trying to protect against state actors<br>
you have probably already lost.  If not, a VPS is probably good enough.<br>
 If it isn't, you are probably a large corporation with plenty of real<br>
physical servers visible on the internet.<br>
<br>
Just my thoughts.<br>
<span class="HOEnZb"><font color="#888888"><br>
Graham<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
tinc mailing list<br>
<a href="mailto:tinc@tinc-vpn.org">tinc@tinc-vpn.org</a><br>
<a href="http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc" rel="noreferrer" target="_blank">http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc</a><br>
</div></div></blockquote></div><br></div>