On Sun, Mar 29, 2020 at 8:29 PM Philipp Czerner <[email protected]> wrote: > > Signed-off-by: Philipp Czerner <[email protected]> > --- > Hi, > > I had some issues setting up Wireguard behind another VPN. Curiously, it > bound the physical interface instead of the other VPN, which was the default > route. According to MSDN "the actual route metric used to compute the route > preference is the summation of interface metric specified in the Metric > member of the MIB_IPINTERFACE_ROW structure and the route metric offset > specified in this member" (documentation for MIB_IPFORWARD_ROW2), but the > code did not seem to consider this. After I changed the calculation, I got > the expected behaviour. > > Cheers, > Philipp > > tunnel/defaultroutemonitor.go | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/tunnel/defaultroutemonitor.go b/tunnel/defaultroutemonitor.go > index c102b64..4b24e8e 100644 > --- a/tunnel/defaultroutemonitor.go > +++ b/tunnel/defaultroutemonitor.go > @@ -33,8 +33,14 @@ func bindSocketRoute(family winipcfg.AddressFamily, device > *device.Device, ourLU > if err != nil || ifrow.OperStatus != winipcfg.IfOperStatusUp { > continue > } > - if r[i].Metric < lowestMetric { > - lowestMetric = r[i].Metric > + > + iface, err := r[i].InterfaceLUID.IPInterface(family) > + if err != nil { > + continue > + } > + > + if r[i].Metric + iface.Metric < lowestMetric { > + lowestMetric = r[i].Metric + iface.Metric;
Nice semicolon ;-). Thanks a lot for this patch and triaging the issue. Nice to hear that nested VPNs work. If you don't mind sharing, I'd be interested to learn what software sets up its routes in this manner. Anyway, applied here: https://git.zx2c4.com/wireguard-windows/commit/?id=66ad537f4e2144112cb6686c4fc4856d70bf6a3d Jason
