Re: Standardized IPv6 ULA from PublicKey

:/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 ___

Re: wg showconf

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

Re: wg showconf

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

Re: wg showconf

n 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

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

Re: Mixed MTU hosts on a network

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

Re: add/remove a peer

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

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

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

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

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

Re: WireGuard connecting hosts WAN->LAN

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

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

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

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

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

Re: [PROPOSAL] wg-quick ip rule priority

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

Re: Logging

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

Re: 'wg syncconf' and interface addresses

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

Re: Logging

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.