On Fri, Jul 22, 2016 at 04:09:13AM -0500, Bruno Wolff III wrote: > On Fri, Jul 22, 2016 at 10:18:21 +0200, > Baptiste Jonglez <[email protected]> wrote: > > > >Yes, the notion of "immediate next destinaton" does not make sense for > >Wireguard. It encapsulates plain IP, not Ethernet. > > I thought that the next IP address might have been available for wireguard > to see as the information seems to be available for routing. But as you > mention below and I realized, that doesn't help with the return packets > since they can have (almost) any source address. > > >You need "allowed ips 0.0.0.0/0" here. Your situation is just a regular > >client/server tunneling setup, there's nothing special about "proxying", > >whatever that means. > > Yeah I realized that when thinking about this some more. "Proxy" in this > case means source nat will be used on the outgoing packets.
Ok, excellent! Wireguard really doesn't care or even know about the source NAT you may apply on the server (well, at least when thinking about it at a high level). If you had used a public IP addresses on the client side (instead of 192.168.7.2), and simply forwarded packets on the server without applying any NAT, it would be exactly the same from the perspective of Wireguard.
signature.asc
Description: PGP signature
_______________________________________________ WireGuard mailing list [email protected] http://lists.zx2c4.com/mailman/listinfo/wireguard
