Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Markus Woschank <markus.woschank@gmail.com>
To: Luis Ressel <aranea@aixah.de>
Cc: wireguard@lists.zx2c4.com
Subject: Re: wg showconf
Date: Sun, 5 Nov 2017 01:05:18 +0100	[thread overview]
Message-ID: <CAKUy5az5NX6hLDPsiUg1eoJEnJ4VK6Q2KyrKLzZ3BMAGrg2nnw@mail.gmail.com> (raw)
In-Reply-To: <20171105000327.0a772771@vega.skynet.aixah.de>

>> While searching for arguments I realised that wireguard will allow a
>> peer to connect with a different IP from the one set in the
>> configuration.
>> Not sure if this is the best behaviour (I understand that the peer
>> needs to know the secret key, anyway not sure).
>
> Yes, wg does this. It's a deliberate design decision which is important
> to support roaming peers.
>
> This is not a security problem. Since wg uses UDP as a transport
> protocol, source IPs can be trivially forged by an attacker; therefore
> checking source IPs wouldn't add any real value.

Nevertheless this is different from the behaviour I expected:
If I specify an endpoint IP the peer is only allowed to connect via
the specified IP/Port.
If I don't specify an endpoint IP the peer is allowed to connect from
everywhere.

Yes, I could have read the documentation more carefully but maybe
restricting the remote IP/Port in cases the endpoint has been
specified would prevent some confusion/discussion.
This would also make the behaviour of the showconf command more
"consistent" because then the information, if the endpoint is set by
config or not, would be available and also the showconf command could
generate an equivalent configuration.

I imaging specifying an endpoint IP for a peer and than discovering
that it connected from a different IP may be surprising to some. I
generally prefer for things to break if I configure them the wrong way
and not work "sometimes" (wrong endpoint IP on one side but the other
first initiating the connection most of the time).

Thanks,
Markus

  reply	other threads:[~2017-11-05  0:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-04 20:04 Markus Woschank
2017-11-04 20:27 ` Luis Ressel
2017-11-04 21:25   ` Markus Woschank
2017-11-04 23:01     ` Luis Ressel
2017-11-04 23:03       ` Luis Ressel
2017-11-05  0:05         ` Markus Woschank [this message]
2017-11-06 16:06           ` Bruno Wolff III

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=CAKUy5az5NX6hLDPsiUg1eoJEnJ4VK6Q2KyrKLzZ3BMAGrg2nnw@mail.gmail.com \
    --to=markus.woschank@gmail.com \
    --cc=aranea@aixah.de \
    --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).