wg showconf

wg showconf

[Markus Woschank]

Hello everyone,

I'm having a minor issue with the showconf command:
The configuration generated may change over time without any settings
changed on the interface, I noticed that peers without an endpoint set
suddenly have an endpoint setting in the output once they established
a handshake with the remote peer.

Is there a specific reason for this behaviour? If not, then I would
argue that showconf should reflect the settings used to configure the
interface and not the current state.

Having the output of showconf reflect the original configuration in a
deterministic way enables configuration/provisioning software to check
if the interface is in the desired state and only take action if it's
not - that would be very helpful at least to me.

Thanks Markus

Re: wg showconf

[Luis Ressel]

On Sat, 4 Nov 2017 21:04:22 +0100
Markus Woschank <markus.woschank+wg@gmail.com> wrote:

> Is there a specific reason for this behaviour? If not, then I would
> argue that showconf should reflect the settings used to configure the
> interface and not the current state.

Peer endpoints are the only part of the information displayed by wg
showconf which change dynamically. Wireguard doesn't cache the original
endpoint specified by the config (if any), so it's not possible to
display it.

> Having the output of showconf reflect the original configuration in a
> deterministic way enables configuration/provisioning software to check
> if the interface is in the desired state and only take action if it's
> not - that would be very helpful at least to me.

I'd suggest you set up your provisioning software to ignore the
endpoints in "wg showconf"'s output if(f) the configuration file
doesn't specify endpoints at all.

If the config file does contain an endpoint, it's probably a good idea
to compare it to the endpoint reported by wg showconf.

Cheers,
Luis Ressel

Re: wg showconf

[Markus Woschank]

>> Having the output of showconf reflect the original configuration in a
>> deterministic way enables configuration/provisioning software to check
>> if the interface is in the desired state and only take action if it's
>> not - that would be very helpful at least to me.
>
> I'd suggest you set up your provisioning software to ignore the
> endpoints in "wg showconf"'s output if(f) the configuration file
> doesn't specify endpoints at all.
>
> If the config file does contain an endpoint, it's probably a good idea
> to compare it to the endpoint reported by wg showconf.

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).

Thanks,
Markus

Re: wg showconf

[Luis Ressel]

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

On Sat, 4 Nov 2017 14:25:28 -0700
Markus Woschank <markus.woschank@gmail.com> wrote:

> 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 supporting 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.

Cheers,
Luis Ressel

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: wg showconf

[Luis Ressel]

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

On Sun, 5 Nov 2017 00:01:22 +0100
Luis Ressel <aranea@aixah.de> wrote:

> Yes, wg does this. It's a deliberate design decision which is
> important to supporting roaming peers.

Whoops, sorry about that. Absentmindedly editing sentences without
reading the result is not a good idea. :)

Cheers,
Luis Ressel

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: wg showconf

[Markus Woschank]

>> 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

Re: wg showconf

[Bruno Wolff III]

On Sun, Nov 05, 2017 at 01:05:18 +0100,
  Markus Woschank <markus.woschank@gmail.com> wrote:
>
>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).

Perhaps, but I think you are thinking about the function incorrectly. The 
peer address shouldn't be looked at as a restriction, but rather as a hint 
of where to send traffic to reach the peer if no traffic has been received 
from it. In that light, wg's behavior makes sense. The last IP address 
the peer was seen at, is normally the best place to look for it later.