On 2021-08-29, Erling Westenvik <erling.westen...@gmail.com> wrote: > On Fri, Aug 27, 2021 at 07:36:21PM -0000, Stuart Henderson wrote: >> >> Make sure you have set wgaip to allow traffic from the machines on the >> subnet on the other side of the tunnel. > > That was it. Thank you so much. Not directly intuitive to me that > "access" to a remote subnet must be specified on the connecting client, > but I think I understand the mechanisms a little better now. > > I can now access my home/office LAN which was my primary goal but I just > found out that traffic to everything else leaves egress untunneled. > However - trying something like: > > route change default 10.0.0.1 > > leaves the laptop dead in the water. Again a routing problem of some > kind I guess. Any hints on where to start digging?
Changing the default route means that wg won't be able to reach the endpoint because the route to it is over the wg interface itself. If you want to tunnel all traffic, the easiest way is: - set your physical interface in a different routing domain, e.g. add "rdomain 2" to hostname.em0 - set wg to use the route table associated with that routing domain when sending the encapsulated packets, e.g. add "wgrtable 2" to the wg interface itself. - set your physical interface in a different routing domain, e.g. add "rdomain 2" to hostname.em0 - set wg to use the route table assocoated with that routing domain when sending the encapsulated packets, e.g. add "wgrtable 2" to hostname.wg0 - on the machine you're connecting wg to, unless you use externally routable IPs directly on the wg interface, you'll probably want something like "match out on em0 received-on wg0 nat-to (em0)" - and because now you'll be receiving traffic from anywhere over the wg interface you'll need wgaip 0.0.0.0/0 I think that covers everything but if not then tcpdump on various interfaces and both wg endpoints to figure out where packets are getting to, and that they have the expected address. -- Please keep replies on the mailing list.
