Hello, I'm experiencing a problem with Wireguard and WSL2. If I activate my tunnel and then I ping a machine on the VPN IP range from WSL2, I don't get any response. However, if after activating Wireguard, I ping from cmd or PowerShell, I successfully get the ping back and I'm able then also to ping from WSL2. I'm not sure if this is related to Wireguard or WSL2, In any case I reported the bug here: https://github.com/microsoft/WSL/issues/5810 Is it a problem of my machine, a problem from WSL2 or Windows Wireguard? -- _ -. .´ |∞∞∞∞ ', ; |∞∞∞∞∞∞ ˜˜ |∞∞∞∞∞∞∞∞∞ RdB ,., |∞∞∞∞∞∞ .' '. |∞∞∞∞ -' `' https://rdb.is
Hi Ruben, On Mon, Nov 23, 2020 at 5:43 PM Ruben Di Battista <rubendibattista@gmail.com> wrote: > > Hello, > > I'm experiencing a problem with Wireguard and WSL2. If I activate my > tunnel and then I ping a machine on the VPN IP range from WSL2, I > don't get any response. > > However, if after activating Wireguard, I ping from cmd or PowerShell, > I successfully get the ping back and I'm able then also to ping from > WSL2. > > I'm not sure if this is related to Wireguard or WSL2, In any case I > reported the bug here: https://github.com/microsoft/WSL/issues/5810 > > Is it a problem of my machine, a problem from WSL2 or Windows Wireguard? That's pretty weird. I've seen a few related bugs like that, where it seems like WSL will drop packets that don't meet some unusual stateful criteria. I don't know if they're trying to do some kind of connection tracking, or if the routing logic is partially broken for NdisMediumIP devices. I assume you're experiencing this using the latest WireGuard 0.3 [1]? To answer your direct question, though, I think this might be a WSL problem rather than a WireGuard problem. If that Github issue doesn't get any attention after some time, I can try to reverse engineer the hyper-v networking drivers to see what's going on, but as always with that kind of thing, no guarantees on its success. Jason [1] https://lists.zx2c4.com/pipermail/wireguard/2020-November/006075.html
Ehi Jason! Thanks for the detailed answer. I just checked on the new 0.3 and the problem still persists. I'm not a network engineer, but I think it might be useful if you can provide more details in the Github issue (or the one I link in the second comment) that could help speed up the process... I guess it's a problem with their hyper-v networking adapter... On Mon, Nov 23, 2020 at 5:51 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote: > > Hi Ruben, > > On Mon, Nov 23, 2020 at 5:43 PM Ruben Di Battista > <rubendibattista@gmail.com> wrote: > > > > Hello, > > > > I'm experiencing a problem with Wireguard and WSL2. If I activate my > > tunnel and then I ping a machine on the VPN IP range from WSL2, I > > don't get any response. > > > > However, if after activating Wireguard, I ping from cmd or PowerShell, > > I successfully get the ping back and I'm able then also to ping from > > WSL2. > > > > I'm not sure if this is related to Wireguard or WSL2, In any case I > > reported the bug here: https://github.com/microsoft/WSL/issues/5810 > > > > Is it a problem of my machine, a problem from WSL2 or Windows Wireguard? > > That's pretty weird. I've seen a few related bugs like that, where it > seems like WSL will drop packets that don't meet some unusual stateful > criteria. I don't know if they're trying to do some kind of connection > tracking, or if the routing logic is partially broken for NdisMediumIP > devices. > > I assume you're experiencing this using the latest WireGuard 0.3 [1]? > > To answer your direct question, though, I think this might be a WSL > problem rather than a WireGuard problem. If that Github issue doesn't > get any attention after some time, I can try to reverse engineer the > hyper-v networking drivers to see what's going on, but as always with > that kind of thing, no guarantees on its success. > > Jason > > [1] https://lists.zx2c4.com/pipermail/wireguard/2020-November/006075.html -- _ -. .´ |∞∞∞∞ ', ; |∞∞∞∞∞∞ ˜˜ |∞∞∞∞∞∞∞∞∞ RdB ,., |∞∞∞∞∞∞ .' '. |∞∞∞∞ -' `' https://rdb.is
On Mon, Nov 23, 2020 at 8:53 PM Ruben Di Battista
<rubendibattista@gmail.com> wrote:
>
> Ehi Jason!
>
> Thanks for the detailed answer. I just checked on the new 0.3 and the
> problem still persists. I'm not a network engineer, but I think it
> might be useful if you can provide more details in the Github issue
> (or the one I link in the second comment) that could help speed up the
> process...
If I can figure out more details, I'll post them. Right now I have
mostly speculation and haven't started dissecting WSL2's networking
quirks. I have subscribed to that issue though.