Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Christoph Loesch <wireguard-mail@chil.at>
To: <wireguard@lists.zx2c4.com>
Subject: Re: WireGuard connection without interface-address / linknet
Date: Wed, 3 Nov 2021 17:03:25 +0100	[thread overview]
Message-ID: <ddc62364-6764-3662-5d76-f720a4a375ff@chil.at> (raw)
In-Reply-To: <1da52141-2cca-9ebb-e415-af471b14e74e@chil.at>

Hi,

regarding the Windows Client I got a good hint in the chat from user another| who told me to look at the routing table.

There I figured out the differences:
- if an address is configured, the Windows Client sets the correct routes from defined AllowedIPs to reach the remote subnets.
- if *no address* is configured in [Interface] then not a single route is set from AllowedIPs but it sets routes for APIPA 169.254.* subnet.

Version information:
App version: 0.5.1
Driver version: 0.10.1
Go version: 1.17.2
Operating System: Windows 10.0.19043
Architecture: amd64

Kind regards,
Christoph

Am 03.11.2021 um 14:45 schrieb Christoph Loesch:
> Hi,
>
> (mail resent without URLs, because it got filtered by moderation)
>
> I am using WireGuard on an OpenWRT VM as server for clients basically to reach the server's internal LAN at 10.5.44.0/24
>
> As clients I currently use different WireGuard implementations like:
> - Ubiquiti EdgeRouter (EdgeOS v2 based on Debian/stretch) with package from github/WireGuard/wireguard-vyatta-ubnt
> - Mikrotik RouterOS v7.1 with Mikrotik own (at the moment beta) implementation
> - Windows 10 Client from wireguard website
>
> Server config looks like this:
>
> config interface 'wg0'
>         option proto 'wireguard'
>         option private_key 'cNT...8Hc='
>         option listen_port '51820'
>         list addresses '172.27.0.1/16'
> config wireguard_wg0
>         option description 'router-test'
>         option public_key 'qT5...YGo='
>         option preshared_key 'Dle...ozI='
>         option persistent_keepalive '25'
>         option route_allowed_ips '1'
>         list allowed_ips '172.27.34.28/32'
>         list allowed_ips '10.34.28.0/24'
>
> Client config looks like this:
>
> [Interface]
> PrivateKey = mDk...uVs=
> Address = 172.27.34.28
> [Peer]
> PublicKey = 1sy...IkU=
> PresharedKey = Dle...ozI=
> AllowedIPs = 172.27.0.1/32,10.5.44.0/24
> Endpoint = server.mydomain.at:51820
> PersistentKeepalive = 25
>
> Clients should just be able to reach the server's 10.5.44.0/24 subnet and this subnet should be able to reach clients at (in this one example) 10.34.28.0/24
> Now this works all well as expected but I would like to omit using the 172.27.* addresses/linknet if possible because I dont really need/use this as it is only defined for the WireGuard tunnel itself.
>
> On the EdgeRouter this also works perfectly fine if I remove the 172.27.* address on both sides. It is still possible to reach the other end repestively.
> On the Mikrotik device and on the Windows client (using exact same configuration) it does not work as soon as I remove just the 172.27. address/linknet from configuration.
> (I didn't test other clients yet)
>
> I guess on the EdgeRouter this works because I set: set interfaces wireguard wg0 **route-allowed-ips true** - so the corresponding routes are added.
> The Mikrotik device and the Windows client do not offer such an option, so those routes have to be added manually I guess?
> But why does that work "out of the box" as soon as I add any linknet (172.27.* in my example) for the tunnel itself to the configuration?
>
> Is this a fault in the implementation and I should file a bug report or is that expected that way?
>
> (it's not a big issue using the linknet, I am just curious and would like avoid using it if it is not neccessarily required)
>
> Thanks for any thoughts and kind regards,
> Christoph

  reply	other threads:[~2021-11-03 16:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-03 13:45 Christoph Loesch
2021-11-03 16:03 ` Christoph Loesch [this message]
2021-11-03 16:18   ` Jason A. Donenfeld
2021-11-03 16:39     ` Christoph Loesch
  -- strict thread matches above, loose matches on Subject: below --
2021-11-02 22:15 Christoph Loesch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ddc62364-6764-3662-5d76-f720a4a375ff@chil.at \
    --to=wireguard-mail@chil.at \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).