<div dir="ltr">Hi Jason,<br><div><div class="gmail_extra"><br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So: things won't be too big of a pain, and at some point, there won't be<br>
any possibility of pains.<br></blockquote><div> </div><div><br></div><div>Great to hear that!<br><br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What precisely are you doing that you think might be easier with JSON?</blockquote><div><br><br>I did look at wg-json. I was wondering more about /etc/wireguard/*.conf and the possibility of using json config there. I am trying to parse wgX.conf so that we can quickly add and remove peers and subnets. Currently I am dumping it into a python dict keyed with the pubkeys <br><br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In this sense, on outgoing, it's sort of like a routing table. on incoming, it's sort of like an IP access control list.</blockquote><div> </div><div><br></div><div> That's a pretty succinct way of putting it. It does sounds simple put that way.<br><br><span class="gmail-m_-940280795865836910gmail-"><br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_-940280795865836910gmail-">
</span>You don't have to run WireGuard in a star topology. You can do full mesh<br>
if you want, or whatever other topology. One interface can have multiple<br>
peers, so you can connect things together any which way you like.<br></blockquote><div><br> <br></div><div>As Jonathan mentioned he is running a mesh. And it does open up possibilities in terms of access control that I haven't fully considered. But how do we scale a mesh? For a number of hosts lets say 20+ with 20 container subnets or more to share, one would imagine managing a peer to peer configuration as the network scales up and down can become a chore. <br><br>A client server with let's say a /16 shared may be more feasible, as then all the client's acceptedIPs can be the single /16 subnet, while the individual client subnets are added to the server for routing as they are added. I will think about this some more.<br><br></div><div>Once again this is really impressive and valuable.<br></div><div><br></div><div>Thanks!<br></div><div>Raul<br></div><br></div></div></div><br><br></div></div></div>