WG interface to ipv4

Kalin KOZHUHAROV me.kalin at gmail.com
Sat May 5 11:28:35 CEST 2018


On Sat, May 5, 2018 at 10:18 AM, ѽ҉ᶬḳ℠ <vtol at gmx.net> wrote:
> I like to keep things neat/controlled and any necessary open socket is only
> sticking out like a sore (wondering why it is opened when not wanted for).
> It would certainly instill more confidence in network security/control if it
> would be possible to define which sockets are opened by WG, like other apps
> do.
>
+1 !

> Which brings up the next point, I have asked previously twice about -
> wildcard ip 0.0.0.0 . How to bind WG to a particular iface/subnet, as  a
> another matter of network security?
>
It is not possible AFAIK. I am not sure in the intrinsic workings, may
be it is not possible by design?

Hmm, should be, given that it only listens to UDP on a single IP
address (as configured on the wgX interface).
Well, one can configure multiple addresses to a single interface, but still
What about when we have more than one wgX interface, do they share memory?

Certainly, the source lists it is binds to any interface:
https://git.zx2c4.com/WireGuard/tree/src/socket.c#n330
unconditionally.

So I guess we can use (from `man 7 socket`)

       SO_BINDTODEVICE
              Bind this socket to a particular device like “eth0”, as
specified in the passed interface name.  If  the
              name  is an empty string or the option length is zero,
the socket device binding is removed.  The passed
              option is a variable-length null-terminated interface
name string with the maximum size of IFNAMSIZ.  If
              a socket is bound to an interface, only packets received
from that particular interface are processed by
              the socket.  Note that this works only for some socket
types, particularly AF_INET sockets.  It  is  not
              supported for packet sockets (use normal bind(2) there).

              Before  Linux  3.8,  this socket option could be set,
but could not retrieved with getsockopt(2).  Since
              Linux 3.8, it is readable.  The optlen argument should
contain the buffer size available to receive  the
              device name and is recommended to be IFNAMSZ bytes.  The
real device name length is reported back in the
              optlen argument.

Just a wild guess.

Cheers,
Kalin.


More information about the WireGuard mailing list