Chris's Wiki :: blog/sysadmin/WireGuardForFirewallBypass Commentshttps://utcc.utoronto.ca/~cks/space/blog/sysadmin/WireGuardForFirewallBypass?atomcommentsDWiki2022-10-03T05:01:01ZRecent comments in Chris's Wiki :: blog/sysadmin/WireGuardForFirewallBypass.By DrScriptt on /blog/sysadmin/WireGuardForFirewallBypasstag:CSpace:blog/sysadmin/WireGuardForFirewallBypass:a570a793cb014b31387af8f137ddab7e318c9571DrScriptthttps://dotFiles.tnetconsulting.net/<div class="wikitext"><p>I find myself wondering if WireGuard could do something like IPsec Transport Mode. That way the IPs stay the same.</p>
<p>You can do IPsec without any daemons running via static transformation configurations.</p>
</div>2022-10-03T05:01:01ZBy Juan on /blog/sysadmin/WireGuardForFirewallBypasstag:CSpace:blog/sysadmin/WireGuardForFirewallBypass:ef3510e18808bf57655bc32251f5b17d296aa50cJuan<div class="wikitext"><p>Ah, I had a good number of leads as to how to approach implementing a wireguard mesh network utilizing an IPv6. The internal network IPs would be set by truncating the last 64 bits from the public key and using them as the host bits. I got busy before I tried to figured out how to have kernel wireguard alert and message that a new client had connected.</p>
<p>Regardless, have you looked at <a href="https://github.com/juanfont/headscale">headscale</a> or <a href="https://github.com/HarvsG/WireGuardMeshes#hsexplain1">the other wireguard mesh tools</a>?</p>
</div>2022-09-30T02:49:53ZBy Chris Siebenmann on /blog/sysadmin/WireGuardForFirewallBypasstag:CSpace:blog/sysadmin/WireGuardForFirewallBypass:e1dd936adea68f6762fc94576b9ceb6ebfe61d17Chris Siebenmann<div class="wikitext"><p>Tailscale is out of our budget (which is zero for something like this),
and as far as I know requires running additional daemons on the machines.
One of the appeals of bare WireGuard is that it's daemon-free; you
configure it and you're done, with the kernel handling everything else.</p>
<p>We certainly could create a special inside subnet for the WireGuard IPs
of external hosts and expose that, but it would require routing updates
on all of our servers to add the new subnet and its gateway (which is,
admittedly, more or less automated). The attraction of other options is
that they're more contained (and as a side effect, also limit (internal)
access to the WireGuard IPs of external machines, just in case they're
running services we don't want internally accessible).</p>
</div>2022-09-28T22:41:52ZBy Joe on /blog/sysadmin/WireGuardForFirewallBypasstag:CSpace:blog/sysadmin/WireGuardForFirewallBypass:0702744913c69a2fc6fb453a894e659249b235b7Joe<div class="wikitext"><p>Surely there's a third option?</p>
<p>Allocate address space in your network that routes to your wireguard 'server'. It doesn't need to NAT?</p>
<p>It also doesn't need to be a spof, there're are a couple of ways you can offer multiple endpoints externally. Internally, you've got simple solutions like keepalived?</p>
</div>2022-09-28T08:17:49ZBy Michael on /blog/sysadmin/WireGuardForFirewallBypasstag:CSpace:blog/sysadmin/WireGuardForFirewallBypass:1e96ebe1d67eaf29e917a43c88bfb48f4af11b15Michael<div class="wikitext"><p>Have you ever considered Tailscale [<a href="https://tailscale.com/]">https://tailscale.com/]</a> as a solution for this?</p>
</div>2022-09-28T06:17:03Z