Development discussion of WireGuard
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Damian Kaczkowski <damian.kaczkowski@gmail.com>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Ability to use one udp port for multiple wg interfaces
Date: Tue, 2 May 2017 21:45:05 +0200	[thread overview]
Message-ID: <CAHmME9rReXuDHmGTU8k7+ryu3pWSMHR0aGfaFWQzWhAnZy9DjA@mail.gmail.com> (raw)
In-Reply-To: <CAGzienGZMTeD6HqQsg36N_g+6faxivOGpBQFF2MmMTzk63iTnw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]

On May 2, 2017 19:59, "Damian Kaczkowski" <damian.kaczkowski@gmail.com>
wrote:

On 2 May 2017 at 18:32, Jason A. Donenfeld <Jason@zx2c4.com> wrote:

> > Hello Janson.
>
> My name is Jason.
>

Sorry.


> > 3. Well if one uses firewall to control flows between zones in
> environment
> > with mix protocols (eg. gre, ipsec, openvpn and so on) then using second
> > tool just to control only wireguard ACLs is not very convenient way from
> > administrative point of view. Also in case where peer is roaming and
> > changing its source IP (eg. road warrior) then maintaining wireguard ACLs
> > will be a huge PITA, if not impossible at large scale.
>
> No, you are wrong. Allowed-ips controls the IP addresses _within_ the
> tunnel. Thus your iptables rules can use "-i wg0 -s 10.0.0.3/32" or
> similar to match a _precise_ peer.
>

Ok. Thanks for a tip. However I still think wireguard looses some
flexibility in that way eg. when peer roams from one network to another
then its ip address may be unknown.



No, wrong. Roaming regards external IP. Allowed IPs regards internal tunnel
IPs, which are static.


Anyway, it is not only about roaming case so if it is not much of a work
and if it is not a security problem then please consider to allow multiple
wg interfaces to work on one port. I hope it won't hurt to allow this
functionality and I am sure it might come handy for some admins in the
wild. Maybe it could be implemented in pair with the idea of refactoring
per interface vs per peer private keys? Hope you will consider it at some
point.


No, you are very mistaken. Please reread the docs on allowed ips keeping in
mind that these concern internal tunneled ips and are static. Typing to you
on my phone so can't write more now.


Best Regards.
Damian.

[-- Attachment #2: Type: text/html, Size: 3699 bytes --]

  reply	other threads:[~2017-05-02 19:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-02  8:20 Damian Kaczkowski
2017-05-02  8:55 ` Jason A. Donenfeld
2017-05-02  9:56   ` Damian Kaczkowski
2017-05-02 16:32     ` Jason A. Donenfeld
2017-05-02 17:59       ` Damian Kaczkowski
2017-05-02 19:45         ` Jason A. Donenfeld [this message]
2017-05-05 18:28           ` Damian Kaczkowski
2017-05-11 10:30             ` Jason A. Donenfeld

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=CAHmME9rReXuDHmGTU8k7+ryu3pWSMHR0aGfaFWQzWhAnZy9DjA@mail.gmail.com \
    --to=jason@zx2c4.com \
    --cc=damian.kaczkowski@gmail.com \
    --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).