[ANNOUNCE] wireguard-linux-compat v0.0.20200318 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, A new version, v0.0.20200318, of the backported WireGuard kernel module for 3.10 <= Linux <= 5.5.y has been tagged in the git repository. Please note that until Linux 5.6 is released, this snapshot is a snapshot rather than a secure final release. == Changes == WireGuard had a brief professional security audit. The auditors didn't find any vulnerabilities, but they did suggest one defense-in-depth suggestion to protect against potential API misuse down the road, mentioned below. This compat snapshot corresponds with the patches I just pushed to Dave for 5.6-rc7. * compat: RHEL 7 backported skb_ensure_writable() * compat: RHEL 8.2 backported ipv6_dst_lookup_flow Usual set of fixes for the RHEL kernels. * curve25519-x86_64: avoid use of r12 This buys us 100 extra cycles, which isn't much, but it winds up being even faster on PaX kernels, which use r12 as a RAP register. * wireguard: queueing: account for skb->protocol==0 This is the defense-in-depth change. We deal with skb->protocol==0 just fine, but the advice to deal explicitly with it seems like a good idea. * receive: remove dead code from default packet type case A default case of a particular switch statement should never be hit, so instead of printing a pretty debug message there, we full-on WARN(), so that we get bug reports. * noise: error out precomputed DH during handshake rather than config All peer keys will now be addable, even if they're low order. However, no handshake messages will be produced successfully. This is a more consistent behavior with other low order keys, where the handshake just won't complete if they're being used anywhere. * send: use normaler alignment formula from upstream We're trying to keep a minimal delta with upstream for the compat backport. This release contains commits from: Jason A. Donenfeld and Luis Ressel. As always, the source is available at https://git.zx2c4.com/wireguard-linux-compat/ and information about the project is available at https://www.wireguard.com/ . This snapshot is available in compressed tarball form here: https://git.zx2c4.com/wireguard-linux-compat/snapshot/wireguard-linux-compat-0.0.20200318.tar.xz SHA2-256: fa74a8627f731754fbf4ea7d6ae8f571a2cfe8cd4b744a5f165065619cb836a1 A PGP signature of that file decompressed is available here: https://git.zx2c4.com/wireguard-linux-compat/snapshot/wireguard-linux-compat-0.0.20200318.tar.asc Signing key: AB9942E6D4A4CFC3412620A749FC7012A5DE03AE Remember to unxz the tarball before verifying the signature. If you're a package maintainer, please bump your package version. If you're a user, the WireGuard team welcomes any and all feedback on this latest version. Finally, WireGuard development thrives on donations. By popular demand, we have a webpage for this: https://www.wireguard.com/donations/ Thank you, Jason Donenfeld -BEGIN PGP SIGNATURE- iQJEBAEBCAAuFiEEq5lC5tSkz8NBJiCnSfxwEqXeA64FAl5zAa8QHGphc29uQHp4 MmM0LmNvbQAKCRBJ/HASpd4DrrYxEACi9sfH52BtJgCjyF+dTpM4fj/JsxTdS76K 3dE7YP4ML2UW3yGDwSRryeyW2LZnv7c9y0utSnjObp69uTTA0AvN70b1qjveFURk bvI19FtuK5S8OrzPdlU+o3OVg3T+/7+LrVnJnI65NUddMZVwgBPFQJXEsmgymlZW ULJO0D28S0K7dZAoKD8noAwqaMEKNE0R/e+QmP4F0JvaVWxNZFN6b5lj6HcRqqq8 zwOje/OBVTJqiiXPwUJrWn6t1ecDSgzHMdmUGV3znWHdfAxbRQpgZUdsGT0CPrOZ +uR89rNIEn4GPGBC7uoFE2WjfEUphjo949JhIlQPZ7v8lAkMEPYZh9bcmSBecp/C joptq/+FSImLUUXwbMPixs0CfSWwfga6o2YI237QWPc4kBj/VkAG9e3FVXtyI+6A S+3IgiVlPMl5nZYSUz2HUDpELKoDl1EBdpNBxgAZ88/AUKNURpBdENWZ7S3mkjkR Q0bLulcWnaiSxAd5sqW1COCkytNGpdRebzAxSlPXDw9SLMGTXvuesM3WqkPIYFr7 X8O6+n1r0/7q3dVoVUiy+zTJEp4kQ69CDEGGKERlRR4VqMGwgggnJdPCbw4W1xIk 5VDvG+d1S/n1ab68Ik4L+/827K+CHHem4MVDYNMn5PTMJb1ULduzt9/Bg80h/+Jo I1eq24NntA== =eef/ -END PGP SIGNATURE-
Re: [PATCH wireguard-android] strings: Update Japanese Translation, corresponds to commit 724884e.
On Thu, 19 Mar 2020 at 05:14, Eiji Tanioka wrote: > > Signed-off-by: Eiji Tanioka > --- > ui/src/main/res/values-ja/strings.xml | 1 + > 1 file changed, 1 insertion(+) Applied, thanks. In the coming days we'll be making the translations available on Crowdin so if you find that more preferable, the option will be available. The project link is https://crowdin.com/project/wireguard.
[PATCH wireguard-android] strings: Update Japanese Translation, corresponds to commit 724884e.
Signed-off-by: Eiji Tanioka --- ui/src/main/res/values-ja/strings.xml | 1 + 1 file changed, 1 insertion(+) diff --git a/ui/src/main/res/values-ja/strings.xml b/ui/src/main/res/values-ja/strings.xml index 2f85bc8..49a4ee0 100644 --- a/ui/src/main/res/values-ja/strings.xml +++ b/ui/src/main/res/values-ja/strings.xml @@ -99,6 +99,7 @@ カーネルモジュールは実験的ですがパフォーマンスが向上する可能性があります。 カーネルモジュールバックエンドの無効化 ユーザースペースバックエンドは低速ですが安定しています。 +成功。アプリケーションは再起動します… MTU 複数トンネルの同時有効化 同時に複数のトンネルを有効化できます -- 2.25.1
Re: WireGuard connecting hosts WAN->LAN
On Sat, Mar 14, 2020 at 16:33:44 +0100, Germano Massullo wrote: A simple question to Wireguard developers, since while asking for help in OpenWRT forum[1] I have been told that I am asking a thing that Wireguard cannot do, so I want to ask upstream if it is possible or not Scenario: A = internet (WAN) host (WireGuard IP 10.1.1.3) B = OpenWRT router (WireGuard IP 10.1.1.1) C = LAN host (WireGuard IP 10.1.1.2) 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. In a few words, I want B to just route forwards packages from A to C. This set of requirements seems odd. Do you not trust C to be able to properly ignore unwanted packets? It is possible to have C ignore layer 3 traffic (DHCP traffic is special) that is not using the tunnel. Inbound you block all traffic not destined for the tunnel's port. Outbound you block all traffic not tagged as tunnel traffic. (Wireguard provides a way to tag tunnel traffic.) The default route should be through the tunnel. Tunnel traffic should be routed through B. The configuration gets trickier if you want to send traffic to A's external address as then you have a routing dependency not based on the destination address. You can do this by having two routing tables using the tag to pick which table gets used.
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. 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
Re: Logging
On Tue, 17 Mar 2020 18:12:05 + Luis Ressel wrote: > > 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. > 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. That said, adding logging to stderr is also very trivial, given the current code. I have updated the two files on my website [1] to include this. Just set environment variable WG_LOG_DEST to "stderr" and then start wireguard-go. Please test. If this works as desired, I will update the git patch that I sent in yesterday. -jr [1] optional syslog logging for wireguard-go http://opal.com/jr/wireguard/logger.go http://opal.com/jr/wireguard/logger_syslog.go (both files are needed)
