Re: Standardized IPv6 ULA from PublicKey

[Luis Ressel]

On Mon, 4 Dec 2017 10:52:28 -0600
Lonnie Abelbeck <li...@lonnie.abelbeck.com> wrote:

> Hi,
> 
> Has anyone thought about a standardized WireGuard IPv6 ULA generated
> from the PublicKey ?

This was indeed already discussed, albeit not for ULAs, but link-local
addresses (fe80::/64). IIRC, Jason rejected it citing the KISS
principle -- and I fully agree with that. Adding a hundred small
features useful for certain corner cases is a sure way to transform
wireguard into a behemoth of ipsec/openvpn dimensions. :)

Cheers,
Luis Ressel
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: wg showconf

[Luis Ressel]

On Sat, 4 Nov 2017 21:04:22 +0100
Markus Woschank <markus.woschank...@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
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: wg showconf

[Luis Ressel]

On Sun, 5 Nov 2017 00:01:22 +0100
Luis Ressel <ara...@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


pgp6v_qvbt_Of.pgp
Description: OpenPGP digital signature
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: wg showconf

[Luis Ressel]

On Sat, 4 Nov 2017 14:25:28 -0700
Markus Woschank <markus.wosch...@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


pgpMAEywRMWDP.pgp
Description: OpenPGP digital signature
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: WG: ideas/features

[Luis Ressel]

On Mon, 26 Mar 2018 20:17:17 +0300
ST  wrote:

> Hello,
> 
> as I mentioned before I'm learning WireGuard and there are certain
> things that I need but didn't find them yet in the docs (either
> because I didn't read enough yet or because it's just not there).
> I'll list them here and you'll tell whether it is worth for a new
> feature or not; or whether I should continue reading...

Don't ask whether you should read the docs. Of course you should,
that's the whole purpose of documentation! :)

> 1. Labels.
> 
> Is it possible to add an optional label to a peer to make it a bit
> more usable for humans (who tend not to remember IPs or keys). A label
> associated with a peer is just a string (could be a first/last name,
> email, "NY Office" or whatever). So if you read through the .conf file
> or query wg for that label - you can get the right IP to SSH to, if
> needed.

This has been suggested a few times already, but so far noone has
bothered to implement it. I don't see any fundamental issues with the
idea, though.

> In the .conf file it could probably be realized through some sort of
> comments before each [Peer] section (didn't check whether # or
> something actually work). But querying wg from command line for a
> label is also handy...

As documented in wg(8), wireguard's config files can indeed contain
comments.

> 
> 2. Includes in .conf files.
> 
> Is it possible to include .conf files in the main wg0.conf file? Like:
> 
> [Interface]
> ...
> 
> Include ./us_peers.conf
> Include ./eu_peers.conf
> 
> [Peer]
> ...
> 
> This way you can group peers into pools, so there will be a bit more
> order/structure...

The config parser doesn't support file inclusion. It doesn't seem to be
worth the hassle to add it either, since there's another way to combine
multiple config files: wg's "addconf" verb. It'll load a config file
without wiping out prior configuration, so you can combine config files
by chaining multiple "wg addconf" verbs.

If atomicity is desired, you could also concatenate the config files to
a temporary file which you then supply to wg setconf (or perhaps even
pipe the concatenated files to "wg setconf /proc/self/fd/0").

Cheers,
Luis
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Mixed MTU hosts on a network

[Luis Ressel]

On Fri, 16 Mar 2018 14:25:47 +0500
Roman Mamedov  wrote:

> What helps, is only reducing MTU of the entire wg0 interface to 1412.
> Then everything works fine. But it doesn't feel optimal to reduce MTU
> of the entire network just because of 1 or 2 hosts. I would rather
> use a couple of those mtu-override routes, if they worked.

Unfortunately, lowering the MTU of the whole tunnel interface is the
only reliable solution right now. Per-peer configurability of MTUs has
been on project TODO for a while, so there will be a better solution
some day. I even started to work on this a few months back, but got
sidetracked.

Cheers,
Luis
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: add/remove a peer

[Luis Ressel]

Hello,

Low-level tools such as wg aren't the right place for the "automagic"
features you're suggesting. wg should have simple, bugproof code and
behave reliably and predictably so that it can serve as a solid
foundation for all sorts of high-level scripts.

Of course, this doesn't mean your suggested features would be useless
-- they just don't belong into the same binary as the low-level stuff.
Build a script to handle the boring IP assignments for you, and if you
believe it might be useful to others, by all means publish it!

Cheers,
Luis
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Some potential bug in wg-quick re. fwmark and default route

[Luis Ressel]

Hello Saeid,

I'm sorry your inquiry has gone unanswered for two weeks; it was simply
drowned by all the user questions. I'm glad I found it now, since you
raise a few interesting points.

As you have discovered, wg-quick is very limited (being the wacky shell
script that it is) and behaves oddly in some corner cases.

I'm drawing a few diagrams right now to see if I can find a way to
improve the add_route/add_default and del_if parts of wg-quick without
increasing the overall complexity too much. Both of your suggestions are
good ideas; if you have further input, that'd be much appreciated!

Cheers,
Luis
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Endpoint address dns resolution - option to prefer IPv6 or IPv4

[Luis Ressel]

On Fri, Mar 13, 2020 at 03:52:19PM +0100, Torsten Krah wrote:
> I've got an endpoint with a DNS name which has both, an A and 
> record.
> I would like to configure the client, so that I can tell him, to either
> prefer IPv6 or IPv4 for the vpn connection.

The relevant source code can be found here:
https://git.zx2c4.com/wireguard-tools/tree/src/config.c#n242

As you can see, wg resolves host names through the libc's getaddrinfo()
function, and simply uses the first ip address returned by that
function.

A standards-compliant implementation should return an ipv6 address in
the first position if one is available and the host has a working
connection to the v6 internet. As far as I know, both glibc and musl do
this (though the behaviour of glibc can be modified by editing
/etc/gai.conf); I'm not sure what other libcs do.

It would of course be possible to make this behaviour configurable for
wg; we just need to figure out if that's an useful feature, and what the
exact semantics should be.

Cheers,
Luis

Re: WireGuard connecting hosts WAN->LAN

[Luis Ressel]

On Sat, Mar 14, 2020 at 04:33:44PM +0100, Germano Massullo wrote:
> I want to:
> 1) connect A to C passing through B. I don't want to expose C to
> internet at all, (so no things like port forwarding)
> 2) A must have C public key (and viceversa), so in case of B being
> compromised, the A<->C VPN will not be compromised.

The answer you quoted is correct. If you don't wish to set up port
forwarding, and C is thus not accessible from the internet at all, A
can't establish a tunnel with it.

You may want to consider setting up two tunnels on A:
* wg0 with B as the peer
* wg1 with C as the peer
and then route the encrypted packets of wg1 through wg0. The
disadvantage of this is that you're encrypting every packet twice, which
hurts performance and lowers the tunnel MTU.

Cheers,
Luis

Re: Endpoint address dns resolution - option to prefer IPv6 or IPv4

[Luis Ressel]

On Sat, Mar 14, 2020 at 06:08:35PM +0100, Matthias Urlichs wrote:
> Ideally some background process forked by `wg` or `wg-quick` should set
> the first address, monitor the peer, and use the next one if it hasn't
> been established after some configurable number of seconds (or when the
> keepalive fails). Bonus points for re-resolving the address when it expires.

Yes, trying the ips in order until a tunnel can be established is
certainly a good idea, and in fact what the relevant standards
recommend, but so far noone has bothered to implement it.

Running a daemon that periodically re-resolves the host and sets the
endpoint to its current ip, on the other hand, would interfere with
wireguard's transparent roaming support, so wg(8) isn't ever going to do
that. Of course, you can easily do this yourself if it makes sense for
your setup.

Cheers,
Luis

Re: wg set fail to update endpoint if traffic is flowing

[Luis Ressel]

On Tue, Mar 31, 2020 at 08:36:52AM +, xtus wrote:
> The set endpoint works only if no traffic is flowing.
> 
> Is this expected behavior?

Yes, it is. It's not that wg set fails to update the endpoint; rather,
the endpoint you've set is immediately overwritten again -- to support
seamless roaming, wg updates the endpoint every time it receives an
authenticated packet from a peer.


Luis

Re: [PROPOSAL] wg-quick ip rule priority

[Luis Ressel]

On Sun, Apr 05, 2020 at 07:37:18PM +0200, vr...@tuta.io wrote:
> Hi everyone!
> I have some tiny proposal for wg-quick utility: adding priority for iproute2 
> routing rules
> 
> For linux.bash this should be as easy as this:
> https://gitea.tort.icu/vrein/wireguard-tools/commit/0947dc76770a5d81ba39340ebe9189b80a92584c

While I don't think it'd be a bad idea to support configurable rule
priorities if they're useful to someone, they shouldn't be neccessary
for the use case you described -- you can avoid the separate routing
rules for wg1 altogether.

All you should need to do is to add "FwMark = 51820" (or some other
arbitrary value, as long as it's identical for both wg tunnels) to the
config files of both wg interfaces. Then you end up with these ip rules
(taken from your post rather than an actual test):

0:  from all lookup local
32764:  from all lookup main suppress_prefixlength 0
32765:  not from all fwmark 0xca6c lookup 51820
32766:  from all lookup main
32767:  from all lookup default

Furthermore, wg-quick would add an "0.0.0.0/0 dev wg0" route to table
51820, and "10.5.0.0/24 dev wg1" to the main table.

This would result in encrypted traffic using the routes in the main
table, traffic to 10.5.0.0/24 the wg1 tunnel, and everything else the
wg0 tunnel, exactly as intended by you.

> PS:
> Somehow, connectivity with both A and B peers were worked in single wg0 
> interface some time ago,
>   but after few updates this feature stopped working.

It should indeed be possible to have both of these peers on the same wg
interface. If you're running into issues with that, please elaborate on
them here or pay us a visit on IRC (#wireguard on Freenode).


Luis

Re: Logging

[Luis Ressel]

On Tue, Mar 17, 2020 at 08:37:17AM +0100, J.R. Oldroyd wrote:
> Since adding syslog support is so trivial, given the existing code
> is already designed around logging levels and given Go's clean support
> of syslog, why not just build it in so that wireguard's logging is done
> consistently with all other UNIX daemons?  Piping stdout to logger
> is non-standard and also loses the ability to filter the different
> log levels to different log destinations.

If you're adding logging support, I'd prefer logs on stderr over a
centralized legacy mechanism such as syslog. That's much more flexible;
in particular, it makes it much easier to direct logs of different
daemons to different places, or run daemons in chroots.

Cheers,
Luis

Re: 'wg syncconf' and interface addresses

[Luis Ressel]

On Tue, Mar 17, 2020 at 04:13:34PM +, David Steinn Geirsson wrote:
> Is Address a valid key for WireGuard configuration, and if so should the wg 
> tool not parse and apply those changes as well?

The wg-quick script uses an extension of the wg config file format, with
config keys such as Address which aren't recognized by wg.

If you wish to use a config file with both wg-quick and wg, you can use
the "wg-quick strip" verb to remove wg-quick options from the config
file. In some shells such as bash, this can be done quite comfortably:
$ wg syncconf wg0 <(wg-quick strip wg0)

Cheers,
Luis

Re: Logging

[Luis Ressel]

On Wed, Mar 18, 2020 at 09:14:42AM +0100, J.R. Oldroyd wrote:
> First, I should point out that the whole purpose of syslog(3) is
> to do the flexible directing of different daemons' logs to different
> places, including in chroots.

By design, syslog funnels all logs through a single socket. Separating
them again requires matching the contents of log messages, which is
inefficient and error-prone. Getting syslog to work in chroots can be
annoying, since it requires opening the logging socket before chrooting
(which requires support by the daemon), or providing a /dev/log socket
inside the chroot.

That said, I'm aware that syslog is more convenient in some setups, so
offering both stderr and syslog logging sounds reasonable to me.

Cheers,
Luis