Re: WG default routing

[Samuel Holland]

On 1/5/21 3:13 PM, Chris Osicki wrote:
> On Wed, Jan 06, 2021 at 01:25:30AM +0500, Roman Mamedov wrote:
>> On Tue, 5 Jan 2021 21:12:12 +0100
>> Chris Osicki  wrote:
>>
>>> As far as I can see after few tests, AllowedIPs config file option has 
>>> nothing to do with routing and I hope 
>>> it will stay like this.
>>
>> wg-quick uses AllowedIPs to also set up matching entries in the system 
>> routing
>> table. This can be disabled in its config.
>>
>>> It is just a filter
>>
>> It is not only a filter on incoming packets, but also WG's internal routing
>> table for knowing which packets should be sent to which peer.
> 
> I'm sorry to contradict you but after some more readig I have to :-)
> WG has no "internal routing table", wg-quick (which, BTW, is not the subject 
> of my query) uses it to modify

Did you read this part of the home page?

https://www.wireguard.com/#conceptual-overview

At the heart of WireGuard is a concept called Cryptokey Routing,
which works by associating public keys with a list of tunnel IP
addresses that are allowed inside the tunnel.

[...]

In the server configuration, when the network interface wants to
send a packet to a peer (a client), it looks at that packet's
destination IP and compares it to each peer's list of allowed
IPs to see which peer to send it to.

[...]

In other words, when sending packets, the list of allowed IPs
behaves as a sort of routing table, and when receiving packets,
the list of allowed IPs behaves as a sort of access control
list.

WireGuard itself does indeed have an internal routing table. And you
should really read that whole section.

> kernel routing tables, from the wg-quick man page:
> 
>It infers all routes from the list of peers' allowed IPs, and 
> automatically adds them to  the  system  routing
>table.  If  one  of  those  routes is the default route (0.0.0.0/0 or 
> ::/0), then it uses ip-rule(8) to handle
>overriding of the default gateway.
> 
> So, in my test config I have a server, 10.10.10.1 and two clients, 
> 10.10.10.2/3
> If on the server I remove the AllowedIPs option, no one can connect.
> Giving AllowedIPs = 10.10.10.0/24 both clients can connect and routing in 
> them stays as it was.
> The same for the clients, without AllowedIPs = 10.10.10.0/24 cannot connect.
> 
> Thus, my question still remains: why this filtering function?

Because, as the WireGuard website explains, a tight, static binding
between a peer's identity and its IP address range is an extremely
useful building block, both for security and for designing a network
topology.

Cheers,
Samuel

Re: [PATCH] Add Simplified Chinese translation

[Samuel Holland]

On 2/24/20 10:02 PM, srb12...@vip.qq.com wrote:
> From: LilligantMatsuri 
> 
> Resend the patch. Please ignore the patches I sent before.
> 
> Signed-off-by: LilligantMatsuri 
> ---
>  app/src/main/res/values-zh-rCN/strings.xml | 174 +
>  1 file changed, 174 insertions(+)
>  create mode 100644 app/src/main/res/values-zh-rCN/strings.xml

Applied, thanks!
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [PATCH wireguard-android] remove tag due to no plural form in Japanese.

[Samuel Holland]

On 2/25/20 9:24 PM, Eiji Tanioka wrote:
> Signed-off-by: Eiji Tanioka 
> ---
>  app/src/main/res/values-ja/strings.xml | 6 --
>  1 file changed, 6 deletions(-)

Applied, thanks!
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [PATCH] Update Simplified Chinese translation

[Samuel Holland]

On 2/25/20 2:13 AM, Eiji Tanioka wrote:
> Hi Samuel.
> 
> I already translated in Japanese, but I didn't concern about plurals.
> 
> Japanese doesn't have plurals, so does "values-ja/strings.xml" needs these 
> fix?
> - remove plurals
> - add string resource that have same "name" attribute as plurals

Resources that have  tags in the untranslated XML should use  in
translations as well. However, the only  tag inside them should be
"other". (It should look like the Chinese translation did before this patch.)

So the only thing to fix is removing the  tags.

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

Re: [PATCH] Update Simplified Chinese translation

[Samuel Holland]

On 2/23/20 5:12 AM, srb12...@vip.qq.com wrote:
> From: LilligantMatsuri 
> 
> Signed-off-by: LilligantMatsuri 
> ---
>  app/src/main/res/values-zh-rCN/strings.xml | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/app/src/main/res/values-zh-rCN/strings.xml 
> b/app/src/main/res/values-zh-rCN/strings.xml
> index 3360dae..97e871a 100644
> --- a/app/src/main/res/values-zh-rCN/strings.xml
> +++ b/app/src/main/res/values-zh-rCN/strings.xml
> @@ -1,21 +1,27 @@
>  
>  
>  
> +无法删除 %d 项：%s
>  无法删除 %d 项：%s

These look to be the same as the "other" case. Additional quantity items are
only needed if they are different:

https://developer.android.com/guide/topics/resources/string-resource#plurals-item-element

>  
>  
> +删除了 %d 项
>  删除了 %d 项
>  
>  
> +已选择 %d 项
>  已选择 %d 项
>  
>  
> +导入了 %d 项，读取到 %d 项
>  导入了 %d 项，读取到 %d 项
>  
>  
> +导入了 %d 项
>  导入了 %d 项
>  
>  
> +%d 个排除应用
>  %d 个排除应用
>  
>  添加节点
> @@ -38,7 +44,7 @@
>  属性未知
>  节未知
>  数值超出范围
> -文件扩展名必须为 .conf 或 .zip
> +扩展名必须为 .conf 或 .zip
>  取消
>  无法删除配置 “%s”
>  “%s” 的配置已存在
> @@ -60,7 +66,7 @@
>  正在使用暗色（黑夜）主题
>  使用暗色主题
>  删除
> -全部取消
> +反选
>  DNS 服务器
>  编辑
>  对端地址
> 

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

Re: [PATCH] Add japanese translation.

[Samuel Holland]

On 2/14/20 11:27 PM, Eiji Tanioka wrote:
> Hi, Samuel.
> 
> Thank you for your reply!
> I re-created patch.

Thanks, applied:
https://git.zx2c4.com/wireguard-android/commit/?id=822f72df956ecd3aaa6a2b254e059e38ba5122e4
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [PATCH] Add japanese translation.

[Samuel Holland]

On 2/13/20 4:31 AM, Eiji Tanioka wrote:
> This patch is Japanese translation for wireguard-android.

Thank you for the patch!

Yes, `git format-patch` and sending to this list is how we're currently
accepting contributions to the Android app.

Next time, please also include your Signed-off-by: line in the commit message.

> ---
>  app/src/main/res/values-ja/strings.xml | 300 -
>  1 file changed, 150 insertions(+), 150 deletions(-)

It looks like you created this file in a previous commit. Please squash your
changes to a single commit that creates the file with its final contents.

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

Re: Wireguard andoird and Fire TV

[Samuel Holland]

Jason,

On 5/21/19 8:58 AM, Jason A. Donenfeld wrote:
> Looks like you added that in dc7363845b3edacc5bac7be85eb7fc63790e97af.
> Remember why?

Yes (after some digging). It's due to the fact that ListView's
OnItemClickListener won't fire if you have a focusable view (like a checkbox or
a switch) in your list item. That's no longer an issue since moving to
RecyclerView, since we add the listeners to each list item ourselves. To be
sure, I tested without blocksDescendants, and I couldn't notice any difference
on a touchscreen device.

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

Re: Wireguard andoird and Fire TV

[Samuel Holland]

Revath,

On 5/21/19 5:45 AM, Revath S Kumar wrote:
> I have send a patch to fix this issue.
> Let me know if any more changes needed for the patch.

Thank you very much for the patch! I could have guessed at what to change, but I
wouldn't have been able to test it. I've merged your patch with a bit of
cleanup, so it'll be included in the next release.

> with regards,
> Revath S Kumar

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

Re: Wireguard andoird and Fire TV

[Samuel Holland]

On 5/6/19 4:27 AM, Revath S Kumar wrote:
> Hello all,
> 
> I tried to side load the wireguard android on Fire TV stick.
> I was successfully able to install and create a new config.
> But once the config is created I was not able to enable the config.
> 
> The navigation using the FireTV remote never gets focus on config toggle 
> button.
> 
> Any plan to support TV sooner?

See https://lists.zx2c4.com/pipermail/wireguard/2019-January/003768.html

It's possible to get it working with the remote, but that would require someone
to write (and test!) the code to do so. Right now there's nobody working on the
Android app.

> with regards,
> Revath S Kumar,
> JavaScripter / Rubyist / PHP

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

Re: Single CPU core bottleneck caused by high site-to-site traffic

[Samuel Holland]

On 03/01/19 22:24, Xiaozhou Liu wrote:
> Hi Jason and the list,
> 
> Here at our corporate network we run some inner site-to-site VPNs using
> WireGuard. Thanks for giving out such a beautiful software to the world.
> 
> Recently we encountered some noticeable network latency during peak traffic
> time. Although the traffic is pretty huge, the WireGuard box is far from
> running out of any of its resources: CPU, memory, network bandwidth, etc.
> 
> It turns out that the bottleneck is caused by the single UDP connection
> between the sites, which cannot be routed to different CPU cores by RSS
> on receiving. The total CPU usage is not high, but one of the cores can
> reach 100%.
> 
> Maybe we can improve this by:
> 
>   embedding more endpoints in one peer so that the VPN tunnel can run
>   multiple UDP flows instead of one. Hence, the single huge UDP flow is
>   effectively broken down to some smaller ones which can be received by
>   multiple queues of the NIC and then later processed by more CPU cores.
>   It will not break current users because the single UDP connection is
>   still provided as the default configuration.

While a native solution would be nice, you should be able to do this today with
nftables. Dynamically rewrite the port number on a portion of the outgoing
packets, and redirect that additional port to the main port on the receive side.
This (untested) is based on the examples in the nftables wiki[1]:

$ nft add rule nat output ip daddr $OTHER_PEER udp dport $MAIN_PORT \
dnat to $PEER : numgen inc mod 2 map { \
   0 : $MAIN_PORT ,\
   1 : $ALT_PORT \
}
$ nft add rule nat prerouting ip daddr $MY_IP udp dport $ALT_PORT \
redirect to $MAIN_PORT

[1]: https://wiki.nftables.org/wiki-nftables/index.php/Load_balancing

> It is also possible to set up multiple wg interfaces and more connections
> explicitly. But it would make the network administration much more complex.
> 
> We are planning to make a working demo of this idea but we would like to
> hear from you first.
> 
> Any idea or comment is appreciated.
> 
> 
> Thanks,
> Xiaozhou

Regards,
Samuel

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

Re: dynamic reload of configuration file

[Samuel Holland]

On 02/17/19 09:21, Raffaele Spazzoli wrote:
> I'm using wireguard to build a VPN mesh. The nodes of the mesh are dynamic 
> and can come and go at any time. Is there a way to reconfigure a wireguard 
> device without restarting it or losing the current connections?
> 
> If yes, how can it be done?

Yes, please read the wg(8) manual page, specifically the `set`, `setconf`, and
`addconf` sections.

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

Re: [PATCH] %i is not a valid format specifier

[Samuel Holland]

Hi,

On 01/21/19 17:38, Alex Xu (Hello71) wrote:
> ---
>  app/src/main/res/values/strings.xml | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

Applied, thanks!

Samuel
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: WireGuard roaming behind a load balancer

[Samuel Holland]

On 01/16/19 18:21, Ivan Labáth wrote:
> In your setup, where H,A,B are wg nodes, and
>   (H)A - B
> is switched to
>   (A)H - B

I assume here A and H are the active/hot-spare pair, and B is the remote node.

> B->HA traffic will be lost (considered junk) until either
> 
>  - B's timer expires and a B->H rekey is issued (maybe 10s of seconds?)

To be precise, this timer is 120 seconds from the last successful handshake.

>  - H->B traffic and/or timer initiates a H->B rekey
> 
> If HA can initate traffic to B, you may be able to rig a rekey soon,
> with a <1s outage, or even lossless in some circumstances, but you are
> going against the design of a host-to-host "stateless" vpn.

H can immediately send handshakes to all peers when it is brought up (and will
do so today if they have persistent keepalives set). But you need more than HA
being able to initiate traffic to B. B could have roamed to a new IP while it
was communicating with A. Then A would know about the new IP (because it
received an authenticated packet from there), but H would not.

So you need some way to stream endpoint updates between A and H. I'm not sure if
WireGuard's netlink has a way to push endpoint changes (that would be nice), but
you could at least poll netlink on the active host, and push netlink on the 
standby.

You could also extend the netlink interface with a way for userspace to request
a handshake on all peers. Then you could leave the interface up, and wouldn't
need any persistent keepalives.

> Real hot-standby HA VPNs with transparent lossless switching
> on the HA side usually share their ephemeral keys.

Sharing ephemeral keys would avoid the need for a new handshake at failover, but
that is very little benefit, since handshakes happen every couple of minutes
anyway. More importantly, sharing keys comes with the security risk of sending
your most sensitive data over the network. Anyone with those keys can decrypt
VPN traffic in real time.

Plus you *still* need the updated endpoint information to send packets from H to
B before B sends anything to AH, even if the session key is still valid. So I
highly recommend against attempting to extract the ephemeral keys from the 
kernel.

> Regards,
> Ivan

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

Re: [Android app] Can't connect to a chromecast when wireguard is running

[Samuel Holland]

On 12/30/18 14:09, Samuel Holland wrote:
> Hi,
> 
> On 12/30/18 13:10, Christophe-Marie Duquesne wrote:
>> Thinking about my former setup with Openvpn, I realized it had a setting 
>> "bypass VPN for local networks" (under "routing"). Is there such a thing
>> in the Wireguard app? (In the peer config, there is a checkbox "Exclude 
>> private IPs". In doubt, I tried to enable it, but then the wireguard 
>> interface stopped working with the message "Error bringing up tunnel: Bad 
>> address")
>> 
>> Generally, the app which I believe would solve my chromecast problem is 
>> probably "Google play services" (com.google.android.gms). It is 
>> unfortunately not part of the list of applications one can exclude from the
>> UI. Is there a way to do one of these two things? - Implement a feature
>> similar to "bypass VPN for local networks"
> 
> That's the idea with the "Exclude private IPs" checkbox. Anything in the 
> RFC1918 range will not use the tunnel. Could you export a log (there's an 
> option in the app settings) with it failing, and send it to me (privately if 
> you want)?

The issue that was breaking the "Exclude private IPs" checkbox has been fixed
and will be part of the next release. Thanks for the report. (For the curious:
an IPv6 DNS server was getting added to the Allowed IPs list with an incorrect
netmask, and Android rejects VPN routes to subnets with a non-zero host part.)

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

Re: [Android app] Can't connect to a chromecast when wireguard is running

[Samuel Holland]

Hi,

On 12/30/18 13:10, Christophe-Marie Duquesne wrote:
> Thinking about my former setup with Openvpn, I realized it had a setting 
> "bypass VPN for local networks" (under "routing"). Is there such a thing in 
> the Wireguard app? (In the peer config, there is a checkbox "Exclude private 
> IPs". In doubt, I tried to enable it, but then the wireguard interface 
> stopped working with the message "Error bringing up tunnel: Bad address")
> 
> Generally, the app which I believe would solve my chromecast problem is 
> probably "Google play services" (com.google.android.gms). It is
> unfortunately not part of the list of applications one can exclude from the
> UI. Is there a way to do one of these two things? - Implement a feature
> similar to "bypass VPN for local networks"

That's the idea with the "Exclude private IPs" checkbox. Anything in the
RFC1918 range will not use the tunnel. Could you export a log (there's an option
in the app settings) with it failing, and send it to me (privately if you want)?

> - Make it possible to exclude an application by string input (directly typing
> "com.google.android.gms" in some text area)

You can do that today by exporting the configuration, adding a line to the
[Interface] section, and re-importing:

ExcludedApplications=com.google.android.gms

The UI currently shows all apps that have a launcher icon. Maybe we need to
change that filter? Can you check if there's a "Google Settings" or similar
entry in the list? I believe that's the name of the launcher entry point for
Google Play Services.

> Thanks, Christophe-Marie

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

Re: Behaviour of multiple Allowed-IPs 0.0.0.0/0 or ::0/0?

[Samuel Holland]

On 12/27/18 10:27, Rene 'Renne' Bartsch, B.Sc. Informatics wrote:
> how does Wireguard behave with multiple peers with Allowed-IPs 0.0.0.0/0 or 
> ::0/0?

That's not allowed. To quote the WireGuard homepage: "when sending packets, the
list of allowed IPs behaves as a sort of routing table, and when receiving
packets, the list of allowed IPs behaves as a sort of access control list."

If two peers had the same network "0.0.0.0/0" in AllowedIPs, how would you
choose which peer to send packets to? You can't, so WireGuard prohibits
duplicating AllowedIPs networks across peers. If you add "0.0.0.0/0" to the
AllowedIPs of one peer, it is removed from the AllowedIPs of every other peer.
(So the end result is that the last peer in the configuration file ends up with
the AllowedIPs of 0.0.0.0/0).

If you have static allocation of internal IP addresses, then you don't want
AllowedIPs of 0.0.0.0/0. If Host A is always assigned IP 10.1.2.3, then its
AllowedIPs only need to be 10.1.2.3. Host B can have AllowedIPs of 10.1.2.4 etc.
and they don't overlap.

On the other hand, if you want to do dynamic routing or multipath, the best
solution for now is to have a separate WireGuard interface for each peer. Then
you can use 0.0.0.0/0, because routing decisions are made at the kernel routing
layer, not by WireGuard.

Hope that helps,
Samuel
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: wg-quick: Separate files for interface and peer definitions?

[Samuel Holland]

On 12/27/18 10:19, Rene 'Renne' Bartsch, B.Sc. Informatics wrote:
> we want to distribute the same file with peer definitions to all Wireguard 
> peers.
> 
> Is there any way in wg-quick to use one configuration file for the interface 
> definition and another file for the definition of peers?

In a way, yes. You can call `wg addconf` from a wg-quick PostUp hook to include
another configuration file containing only peers. However, the recommended way
of doing this if you are using a configuration management system
(puppet/ansible/salt/etc.) is to use a template that will concatenate the
interface configuration and peer definitions into one file.

Note that WireGuard will ignore a peer whose public key matches the interface's
private key. So you can distribute a single list of peers everywhere. Only the
[Interface] section needs to be customized per machine.

Hope that helps,
Samuel
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: wg-quick: Read private key from file?

[Samuel Holland]

On 12/27/18 10:51, Rene 'Renne' Bartsch, B.Sc. Informatics wrote:
> does wg-quick allow to read the private key from a file instead of a 
> .conf-file?

Yes, and the manual page wg-quick(8) even has an example of how to read the
private key from an external source:

Or, perhaps it is desirable to store private keys in encrypted form, such
as through use of pass(1):

PostUp = wg set %i private-key <(pass WireGuard/private-keys/%i)

If you want to use a file, just provide the filename, as in:

PostUp = wg set %i private-key /etc/wireguard/wg0.key

>From the wg(8) manual page:

Both private-key and preshared-key must be a files, because command line
arguments are not considered private on most systems; but if you are using
bash(1), you may safely pass in a string by specifying as private-key or
preshared-key the expression:  <(echo PRIVATEKEYSTRING).

There's no need to write additional wrapper scripts or anything like that.

If you weren't aware of those two manual pages, I suggest reading through both.
It will answer most of your questions :)

Hope that helps,
Samuel
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Should wg-quick with SaveConfig accumulate IPv6 link-local addresses

[Samuel Holland]

On 12/09/18 20:05, Jason A. Donenfeld wrote:
> On Mon, Dec 10, 2018 at 3:04 AM Samuel Holland  wrote:
>>
>> On 12/09/18 19:15, Jason A. Donenfeld wrote:
>>> This is mostly just a CentOS issue. On older kernels, we don't
>>> successfully disable LLv6:
>>> https://git.zx2c4.com/WireGuard/tree/src/compat/compat.h#n583
>>>
>>> There's probably a way to backport that tweak to before 3.17, but I
>>> haven't spent time on it. Feel free to send a patch, and if it's clean
>>> and fits entirely into compat.h, I'll gladly apply it.
>>
>> You can also work around this in wg-quick by changing up_if() to
>>
>>   cmd ip link set "$INTERFACE" up addrgenmode none
> 
> Does that work in kernels < 3.17?
> 

Oh, sorry, no it doesn't :( While it uses a totally different way of accessing
the device (so I thought it might still work), it's just another way of setting
addr_gen_mode.
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Should wg-quick with SaveConfig accumulate IPv6 link-local addresses

[Samuel Holland]

On 12/09/18 19:15, Jason A. Donenfeld wrote:
> This is mostly just a CentOS issue. On older kernels, we don't
> successfully disable LLv6:
> https://git.zx2c4.com/WireGuard/tree/src/compat/compat.h#n583
> 
> There's probably a way to backport that tweak to before 3.17, but I
> haven't spent time on it. Feel free to send a patch, and if it's clean
> and fits entirely into compat.h, I'll gladly apply it.

You can also work around this in wg-quick by changing up_if() to

  cmd ip link set "$INTERFACE" up addrgenmode none
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

WireGuard and IPv6 Source Address Selection (was: ipv6 tunnels and babel's source specific routing)

[Samuel Holland]

Hi,

This isn't quite the same situation you're in (I'm not using a routing daemon),
but I have also had issues with WireGuard and IPv6 source address selection, and
I thought I'd share my solution for the benefit of the list. This might be the
"some better way to deprioritize a given set of ipv6 addrs" you're looking for.

My VPN topology consists of two fixed sites with native IPv6, plus some road
warriors without IPv6. Site A has a DHCPv6 IA-PD subnet we'll call
2605:::aa::/56, and Site B has a DHCPv6 IA-PD subnet we'll call
2600:::bbb::/60. Because Site A was the original site, and it has the
larger prefix, I use a /64 from that subnet ("2605:::aacc::/64") to
connect all of the WireGuard peers in a mesh. So my configuration looks
something like this (ignoring IPv4), where the first IP address given for each
peer is the one assigned (with prefix length 64) to wg0:

[Peer]
PublicKey = 
AllowedIPs = 2605:::aacc::10/128, 2605:::aa::/56

[Peer]
PublicKey = 
AllowedIPs = 2605:::aacc::20/128, 2600:::bbb::/60

[Peer]
PublicKey = 
AllowedIPs = 2605:::aacc::81/128

[Peer]
PublicKey = 
AllowedIPs = 2605:::aacc::82/128

This works great for every machine *except* the router at Site B, which also
happens to be my main workstation. Linux always chooses 2605:::aacc::20
as the source address when sending packets to the Internet, and of course that
gets dropped by my ISP, because they only delegated me 2600:::bbb::/60.

I tried to set `preferred_lft 0` on 2605:::aacc::20, but that caused
other issues (it's been a couple of months so I don't remember the details). The
solution actually turned out to be really simple:

ip addrlabel add prefix 2605:::aa::/56 label 100

One of the rules for IPv6 source address selection is to prefer source addresses
with the same label as the destination. Normally, the whole publicly routable
IPv6 space is one label (while link-local, loopback, IPv4-mapped, etc. are
unique), but you can create arbitrary labels. Just pick any ID that's not
already in use (`ip addrlabel` shows the list of existing labels).

Having Site A's subnet on its own label does exactly what I want. Traffic to
Site A from the router at Site B always uses its address from wg0, and traffic
*outside* Site A's subnet *never* uses the address from wg0.

Hope this helps,
Samuel

On 11/08/18 20:57, Dave Taht wrote:
> I figured out the first two bits of using source specific routing for
> ipv6 with wireguard...
> 
> The first trick was to watch what wg-quick wanted to do and change it.
> So I setup my vpn client (deep within
> my network) thusly:
> 
> [Interface]
> #Address = 2600:8211:e001:9300::2/60
> ListenPort = 51820
> PrivateKey = neveryoumind
> 
> [Peer]
> PublicKey = notdoingthat
> AllowedIPs = 2600:8211:e001:9300::/60, ::/0
> Endpoint = tun.taht.net:51820
> 
> This tells wireguard to let any ipv6 address through and treat it like
> a default route. We don't really want this but I fix this later.
> 
> The server is setup similarly, but no ::/0 and an address of ::1/60
> 
> Then I changed the default startup to look like this:
> 
> #!/bin/sh
> ip link add wg0 type wireguard
> wg setconf wg0 /etc/wireguard/wg0.conf
> # preferred_lft 0 makes sure you don't use this address for anything
> you don't explicitly bind to
> # Otherwise *because* it is static, with a preferred_lft of forever,
> it gets chosen as
> # a default ipv6 addr over the dynamic ipv6 addresses. I only want the vpn for
> # specific tools...
> ip address add 2600:8211:e001:9300::2/60 dev wg0 preferred_lft 0
> ip link set mtu 1420 dev wg0
> ip link set wg0 up
> ip route add 2600:8211:e001:9300::/60 dev wg0
> # the default line generated by wg-quick inserts a default route for 
> everything
> # which disables my native ipv6 addrs and routing
> # The trick - note the from and the proto
> ip -6 route add ::/0 from 2600:8211:e001:9300::/60 dev wg0 proto 48
> 
> then I setup babeld.conf to have
> 
> redistribute proto 48 allow
> 
> which exports that "from default" to the rest of my network without
> doing a default default route that RA picks up
> 
> I can then do stuff anywhere else on my net (running babel rfc61236bis) , like
> 
> ip address add 2600:8211:e001:9301::1/64 dev whichever preferred_lft 0
> 
> which gives me a valid_lft of forever... and
> 
> this lets me use my native, dynamic, ipv6 ips from comcast in the general 
> case,
> and the vpn tunnel'd ipv6 address ranges only when I explicitly specify it.
> 
> I have no idea if dhcpv6-pd can be configured (with a valid_lft of a
> lot, constantly renewed, and a prefeered of 0) this way or hnetd, or
> if there was some better way
> to deprioritize a given set of ipv6 addrs, but...
> 
> Now that I have a whole /56 I can finally fiddle more with hnetd
> again. This also gives me cheap failover if one of my gws goes down...

Re: multiple wg interface in different namespace

[Samuel Holland]

Hello,

On 07/16/18 03:50, Quan Zhou wrote:
> I've been using wg for a while without any problem, but today I wanted
> to try something with the namespace[1]. There's a difference in my
> settings, I already have a wg working without the netns. This or
> perhaps other factors results in a failure bringing up the interface:
> ``RTNETLINK answers: Address already in use.'' Details follow.
> 
> [1]: https://www.wireguard.com/netns/
> 
> Configuration:
>  SiteA to SiteC (working correctly):
> 
> ```bash
> ip link add dev wg0 type wireguard
> wg setconf wg0 /etc/wireguard/wg0.conf
> ip link set up dev wg0
> ip route add 192.168.<>.0/24 dev wg0
> ip route add 10.12.<>.0/24 dev wg0
> ```
>  SiteA to SiteB (Trouble bringing up iface on Site A):
> ```bash
> ip netns add sv0
> ip link add sv0en0 type veth peer ens3
> ip link add sv0wg0 type wireguard
> ip link set sv0en0 netns sv0
> ip link set sv0wg0 netns sv0

Here you're creating the WireGuard interface before moving it to the sv0
namespace. The underlying UDP socket used by WireGuard is created in the
original namespace, and is _not_ moved with the interface. If you're using the
same ListenPort on both interfaces, the sockets will conflict, as you can see in
dmesg. Either:
- Use different listen ports for the two WireGuard interfaces, or
- Create sv0wg0 in the sv0 namespace instead of moving it there after the fact.

> ip -n sv0 addr add /32 dev sv0en0
> ip -n sv0 route add default dev sv0en0
> ip -n sv0 link set up sv0en0
> ip netns exec sv0 wg setconf sv0wg0 ./sv0wg0.conf
> ip -n sv0 addr add /31 dev sv0wg0
> ip -n sv0 link set up sv0wg0
> ```
> # ip -n sv0 link set up sv0wg0
> RTNETLINK answers: Address already in use
> 
>  dmesg |grep wireguard
> ```
> [   16.051148] wireguard: loading out-of-tree module taints kernel.
> [   16.051390] wireguard: module verification failed: signature and/or
> required key missing - tainting kernel
> [   16.051880] wireguard: WireGuard 0.0.20180708 loaded. See
> www.wireguard.com for information.
> [   16.051881] wireguard: Copyright (C) 2015-2018 Jason A. Donenfeld
> . All Rights Reserved.
> [  214.191712] wireguard: sv0wg0: Could not create IPv4 socket
> [  233.096882] wireguard: sv0wg0: Could not create IPv4 socket
> [  250.411586] wireguard: sv0wg0: Could not create IPv4 socket
> [  522.266844] wireguard: sv0wg0: Could not create IPv4 socket
> [  950.891264] wireguard: sv0wg0: Could not create IPv4 socket
> [ 1004.031902] wireguard: sv0wg0: Could not create IPv4 socket
> [ 1044.773710] wireguard: sv0wg0: Could not create IPv4 socket
> [ 1053.273612] wireguard: sv0wg0: Could not create IPv4 socket
> [ 1057.656802] wireguard: sv0wg0: Could not create IPv4 socket
> [ 1312.781415] wireguard: sv0wg0: Could not create IPv4 socket
> [ 1359.582271] wireguard: sv0wg0: Could not create IPv4 socket
> [ 1370.719755] wireguard: sv0wg0: Could not create IPv4 socket
> [ 1586.955734] wireguard: sv0wg0: Could not create IPv4 socket
> [ 1603.063851] wireguard: sv0wg0: Could not create IPv4 socket
> [ 2257.095367] wireguard: wg0: Could not create IPv4 socket
> [ 3631.242070] wireguard: sv0wg0: Could not create IPv4 socket
> ```
>  Workaround (not really)
> ```bash
> # ip link set down wg0
> # ip -n sv0 link set up sv0wg0
> # # >>> Works
> # ip link set up wg0
> # # >>> RTNETLINK answers: Address already in use
> # # >>> See entry [ 2257.095367] in the dmesg above
> ```
> 

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

Re: Android app whitelist/blacklist feature

[Samuel Holland]

On 07/02/18 21:31, Jason A. Donenfeld wrote:
> On Tue, Jul 3, 2018 at 4:27 AM Eric Kuck  wrote:
>> 
>> I was originally thinking the new fragment would be a per-tunnel thing
>> (set when you create the tunnel or edit it), but you’re right - making it
>> a general setting likely makes a whole lot more sense. I can’t think of
>> any use-cases for different tunnels handling different apps.
> 
> It might actually make most sense to make it a per-tunnel thing. We'd then 
> have to introduce conf key called, "ExemptedApplications=" or something. 
> Samuel - any thoughts on this?

Right, trying to make it a global setting requires either some sort of
out-of-band way to pass the information to wg-quick, or rewriting the
configuration file every time the tunnel is brought up.

Since from netd's point of view, this is a per-network setting anyway, I agree
it makes sense to configure it per-tunnel. ExemptedApplications works as a
configuration key, though I prefer ExcludedApplications--the application isn't
just not required to use the tunnel, it's not allowed to use the tunnel.

In that case, here are my UI suggestions:
- Add a button in the editor that switches to a fragment or pops up a Dialog
similar to a MultiSelectListPreference.
- For consistency, checked means excluded -- everything defaults to unchecked.
- The package names of excluded apps are put in the
com.wireguard.config.Interface, and wg-quick handles package name to uid
translation.

How does that sound?

Samuel
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Android app whitelist/blacklist feature

[Samuel Holland]

Hello Eric,

On 07/02/18 15:35, Eric Kuck wrote:
> I’d like to make a contribution to the Android app, but would like to know if
> this is something that would actually get merged before I go through all the
> effort. What I’d like to do is add an exceptions list (apps that will not be
> routed through the Wireguard interface). The rationale for this being that 
> some apps simply don’t work with Wireguard. For example, the use of a 
> Wireguard VPN with custom DNS breaks WearOS watches due to Google hardcoding 
> the use of the 8.8.8.8 DNS server. Another example is that Netflix doesn’t 
> work when routed through my VPN server since they know it’s a DigitalOcean 
> instance, but works fine without the VPN enabled. Another example is that 
> there’s often no reason to route data-heavy video apps through your VPN 
> server. Rather than turning the VPN on my phone off to use my wearable or to 
> watch something on my phone, I’d like to be able to opt those apps out of 
> using the VPN at all. I’m sure there are many more examples of apps that 
> simply don’t need to go through a VPN, as no confidential information is 
> passed through them.

This sounds like a generally useful feature.

> My proposal is to add another Fragment that’s just a list of all apps 
> installed on the phone with check boxes next to them. If the checkbox is 
> checked, that app will be routed through Wireguard. If not, it will be free 
> to bypass the VPN. Naturally, all apps will be default to being checked.

If you base the UI on DialogPreference or MultiSelectListPreference, Android
will take care of persisting the setting for you, and it would be easy to add to
the settings page.

> This is an easy change to make for the GoBackend implementation using 
> VpnService.Builder.addDisallowedApplication(), but would likely 
> be pretty complicated to add to WgQuickBackend. Perhaps this is something 
> that would only be possible for GoBackend users.

For WgQuickBackend, we'd need to modify the set_users function[1] in the
wg-quick "script" to take a dynamic list of user IDs instead of hard coding it.
PackageManager should provide us the UIDs of other applications. I'm not sure
the best way to communicate the ID list from the app to the script. Jason, 
thoughts?

> Any thoughts on this? I have everything working locally by simply adding 
> these two hardcoded lines to GoBackend.java:
> 
> builder.addDisallowedApplication("com.netflix.mediaclient"); 
> builder.addDisallowedApplication("com.google.android.wearable.app”);
> 
> but I would like to make this more configurable and available to the rest of
>  Wireguard users if you’re agreeable to it. Thanks.

Thank you,
Samuel

[1]:
https://git.zx2c4.com/WireGuard/tree/src/tools/wg-quick/android.c?id=dfd9827d5b08c506522bb3762cd3b0dbac640bbc#n291
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Android app and command line

[Samuel Holland]

Hello,

On 03/12/18 20:51, Jacob Schooley wrote:
> There is an option in the Android app to enable wg and wg-quick, which will be
> extremely useful to me as most of my VPN stuff is taken care of with Tasker.
> There are two major bugs with this however.

Thanks for the report!

> One is that the app doesn't automatically update the status of wireguard, so 
> the
> switch inside the app won't flip if I use wg-quick up or down until I swipe 
> off
> and reopen the app, and the quick settings toggle won't change.

I've looked into this, and it is unfortunately quite difficult to do. The app
can register to receive notification about network changes, but unfortunately
there's no* way for the app to tell the Android connectivity service that the
WireGuard tunnel exists, so Android can track its state. Even then, wg-quick on
the command line wouldn't easily be able to tell the app about _new_ tunnels.

*without using reflection to access internal framework classes.

> The other is that if I run wg-quick up, then try to bring it down through the
> app or the quick settings toggle, it says "Error bringing down tunnel: Unable 
> to
> configure tunnel (wg-quick returned 2)." So as of now it really doesn't work
> well with tasker because I can't bring it down manually if I need to.

Hmm, that might actually be a bug. I'll look into that.

In the meantime, have you considered using Tasker to kill the app every time you
use wg-quick? Android will restart it and the quick tile will update, plus it
will refresh the state of all known tunnels within the app.

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

Re: Allowed IPs Toggling

[Samuel Holland]

Hello,

On 03/15/18 13:39, Steve Gilberd wrote:
>> Allowed IPs is like a routing table; you can't have two routes for the same
> set of IPs
> 
> If this is the case, then wireguard does not have proper routing support.
> 
> Normally, routing tables allow both multiple and overlapping routes present.
> When making routing decisions, the most-specific route is chosen (e.g. a /29 
> is
> higher priority than a /24 which overlaps with it). If there are two identical
> routes of the same size, then the one with the lowest routing metric is used.
> 
> I can understand not allowing identical routes of the same size, as wireguard
> doesn't really have a concept of metric (although it could be useful for 
> backup
> links). However, it really should allow overlapping routes of different sizes.
> There's no ambiguity with routing decisions, and it's a standard feature that 
> I
> would normally expect any IP routing stack to have.

WireGuard *does* support overlapping ranges of AllowedIPs on different peers. It
doesn't support having *identical* ranges of AllowedIPs on different peers,
which was the situation here. (You're correct, there's no concept of a metric.)

> Cheers,
> Steve

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

Re: Lineage OS (Android) Support

[Samuel Holland]

Hello,

On 03/13/18 06:15, Paul wrote:
> On So, Mär 11, 2018 at 7:42 PM, Paul  wrote:
>> Hi all,
>>
>> I'm new to the list and hope this wasn't discussed in length here before. If
>> so, please give me a direction, I couldn't find anything related.
>>
>> For the last days I tried to find a Lineage OS [1] compatible kernel with
>> wireguard included, sadly there is none. Instead of installing a custom
>> kernel, could Lineage include the < 4000 lines of code in their build root?
>> Have there been any efforts on this?
>>
>> Thank you very much for all further information.
>>
>> Best regards,
>> Paul Spooren
>>
>> [1] http://lineageos.org/
> 
> I asked the Lineage OS maintainer of my current phone and he responded to use
> the native VPN interface of Android. Are there any plans on that?

Yes, support for using the Go implementation[1] with VpnService is in the works.
The same app will support both the native and userspace implementations. It will
prefer the native implementation if root access and the kernel module are
available, and fall back to using VpnService otherwise.

>> https://developer.android.com/reference/android/net/VpnService.html
>>
>> That has many pros:
>> 1. runs on any Android 4.0+ device (NO root required)
>> 2. all VPN code (except network interface of course) is running in userspace
>> (in case of exploitation only VPN app is compromised)
>> 3. decoupled from OS and easy to upgrade

Using the native implementation has its own benefits. It will generally be
faster and more battery-efficient, and it supports having multiple tunnels up
simultaneously. VpnService only allows one VPN to be active at a time.

> Thanks for all further information!
> 
> Best,
> Paul

Regards,
Samuel

[1]: https://git.zx2c4.com/wireguard-go/
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Allowed IPs Toggling

[Samuel Holland]

Hello,

On 03/15/18 10:31, Gianluca Gabrielli wrote:
> I was setting two peers on the server, but every time I re-add one of these 
> two the other one is shown with (none) on "allowed ips" field. Of course that
> blocks communications with that peer. If I try to re-add it, then the other
> peer loses its configuration, same problem.

Allowed IPs is like a routing table; you can't have two routes for the same set
of IPs, or WireGuard doesn't know which peer to send the traffic to. You want to
have non-overlapping Allowed IP ranges. This usually means that the range of
Allowed IPs is smaller than the host's subnet. For example:

Host A:
IP configuration for WireGuard interface: 192.168.123.1/24
Allowed IPs for Host B: 192.168.123.2/32

Host B:
IP configuration for WireGuard interface: 192.168.123.2/24
Allowed IPs for Host A: 192.168.123.1/32

The IP configuration tells the kernel which IP ranges are accessible via the
WireGuard interface. The Allowed IPs tell WireGuard, which _subset_ of those IPs
is associated with each peer.

> Cheers,
> Gianluca

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

Re: WireGuard root-less support for android

[Samuel Holland]

Hello,

On 11/06/17 22:38, Aurélien Chabot wrote:

I worked on a set of change to add root-less support of WireGuard for
android. The solution I choose is to use the wireguard-go library 
inside the android application. Golang as a mechanism to export some 
native binding quite easily to java. The set of patch need some 
feedback but it's actually working well. I'd like to know if you 
think this is a good direction to take for the android application.


Thanks for your contribution! This is definitely the direction we want
to work toward; the Go implementation is much more accessible to
non-rooted devices. I had assumed we would have to run wireguard-go as a
separate process (my only experience with Go-on-Android is syncthing[1],
which pretends its Go binary is a native library[2]). If we can run
wireguard-go in process, that would be much better!

[1]: https://github.com/syncthing/syncthing-android
[2]: 
https://github.com/syncthing/syncthing-android/blob/master/make-syncthing.bash


The patch are in the thread but I used a submodule to integrate the 
wireguard-go library inside the wireguard-android so at least this 
need to be change with the official url if it's get merge.


Also, your patch 2 won't work as-is with the upstream version since it
won't have the same commit hash.

You can also find the set of change on my github : 
https://github.com/trishika/wireguard-android 
https://github.com/trishika/wireguard-go


I've started looking through your Java changes, and they're generally
looking good. The actual wireguard-go glue can't be merged until after
the changes to the other repository (hooray submodules!), but I'll go
ahead and try to integrate your service abstraction layer. That way I
can reuse it for switching the kernel-space interface from wg-quick to
wg proper (an existing to-do item).


Aurélien

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

Re: Issue, WireGuard on a PaX kernel

[Samuel Holland]

Hello,

On 04/23/17 09:53, saeidscorp wrote:

I've been having troubles using WireGuard on Gentoo hardened/PaX
kernel. I have set up WireGuard on regular kernels several times, but
on a PaX kernel it causes the kernel to panic.

All steps of interface addition and configuration using wg tool work
well, but as soon as the first packet goes through the interface, it
crashes the whole system.


You didn't mention your kernel version, so I assume you're using the
latest stable hardened-sources. The panic is a known issue for 4.8,
caused by a combination of bugs in the upstream kernel and the
grsecurity patch. You can resolve it by either downgrading to 4.7 or
upgrading to 4.9.

See this thread[0] for more information.

Regards,
Samuel

[0] https://www.mail-archive.com/wireguard@lists.zx2c4.com/msg00385.html
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Instability during large transfers

[Samuel Holland]

Hello,

On 03/01/17 16:44, Samuel Holland wrote:

Is there anything else I can do to debug this? Enable some kernel
debugging option? Try a vanilla kernel? Try a newer kernel?


I've upgraded to vanilla (kernel.org) Linux 4.9.15, and while I've been
unable to trigger the same panic so far, I'm getting a similar linked
list corruption warning. This time, instead of failing to pass data once
the warning hits, some packets are coming in out of order with 3000-5000
ms latency. Attached is the dmesg output, kernel config, and ping logs
for inside the VPN. The actual link latency between peers is around 10ms.

As I still haven't been able to reproduce this issue on another machine,
I cannot rule out hardware issues, but this exact machine worked fine
for a year straight (2x 6 months uptime) using OpenVPN. So I'm looking
at either WireGuard or padata as the cause.

The kernel has linked list debugging turned on.



I upgraded again to 4.9.16, and enabled every debug and self-test option
that I could find that seemed relevant. The stack traces and symptoms
still look similar. Except now when it panics (instead of just a
warning), I don't get a log; the netconsole just suddenly cuts over to
the next boot.

You can also see how it stops sending keepalive packets once the
warnings hit.

At this point, unless you want me to try something, I'm going to stop
sending logs. I'm not very familiar with the kernel's
timer/workqueue/crypto subsystems, so there's not much debugging I can
do on my own until I have time to do research (and I have no idea when
that will be). But if you can't reproduce the issue, then it will be
rather difficult for you to debug as well.

I'd still like to get this fixed, and I'll gladly help any way I can.

Thanks,
Samuel Holland


warning_4.9.15.config.xz
Description: application/xz


warning_4.9.15.dmesg.xz
Description: application/xz


warning_4.9.15.dmesg_secondboot.xz
Description: application/xz


warning_4.9.15.vpn_ping.xz
Description: application/xz


warning_4.9.16.dmesg.xz
Description: application/xz
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Instability during large transfers

[Samuel Holland]

On 02/17/17 07:36, Jason A. Donenfeld wrote:

Thanks very much for the excellent debugging output. I'll try to
reproduce this as well on my systems.


I assume you have not been able to reproduce this issue.


The stack trace does indicate that the OOPS is happening in padata,
not in wireguard, so I wonder if this is some bug caused either by
grsecurity or by something else that was then fixed, but since your
kernel is a bit old (4.7.10) maybe the fix didn't make it. In either
case, I'll try to reproduce on that kernel and on newer kernels and
will get back to you.

I presume you have most PaX options turned on?


Since this is on 4.7.10 (that is pre-4.9), this is not related to the
other bug recently reported.

I have disabled all grsecurity/PaX options in my kernel config
(attached) and was able to trigger the bug again. This is with WireGuard
commit f97b7e34bda436ac4572697a8770837eec7470b6 and debugging enabled.
Again attached is the dmesg.

I used the same SSH cat /dev/zero | dd of=/dev/null as before. This time
I got "192656101376 bytes (193 GB, 179 GiB) copied, 41643 s, 4.6 MB/s"
before the connection was broken.

Interestingly, when the firewall came back up, I again had the issue
where devices were continuing to handshake, but no data went through
(and I could confirm this with the wireguard debug output in dmesg).

I was unable to reproduce this issue with a spare laptop (ThinkPad
X220), even after leaving it running for about three days. Since the
router has a rather weak Atom CPU (http://ark.intel.com/products/78866),
I suspect maybe a race condition due to the high load might be involved?

Is there anything else I can do to debug this? Enable some kernel
debugging option? Try a vanilla kernel? Try a newer kernel?


Thanks, Jason


Thanks,
Samuel Holland


panic_grsec_disabled.config.gz
Description: application/gzip


panic_grsec_disabled.dmesg.gz
Description: application/gzip
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Instability during large transfers

[Samuel Holland]

Hello,

On 02/17/17 07:36, Jason A. Donenfeld wrote:

The stack trace does indicate that the OOPS is happening in padata,
not in wireguard, so I wonder if this is some bug caused either by
grsecurity or by something else that was then fixed, but since your
kernel is a bit old (4.7.10) maybe the fix didn't make it. In either
case, I'll try to reproduce on that kernel and on newer kernels and
will get back to you.


There do not appear to be any relevant changes to padata in the past few
years, and grsecurity doesn't look like it affects padata much, but that
doesn't rule it out:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/?qt=grep=padata
https://grsecurity.net/changelog-test.txt


I presume you have most PaX options turned on?


Attached is my config.gz (it's the same on all machines).


Thanks,
Jason


Thanks,
Samuel



config-4.7.10-hardened.gz
Description: application/gzip
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [RFC] Handling multiple endpoints for a single peer

[Samuel Holland]

Hello,

On 01/08/17 16:49, Jason A. Donenfeld wrote:

However, this doesn't shine any light on the hardest problem: how to
update the list of addresses in a memory-bounded fashion. Right now,
if you receive an encrypted packet, the endpoint of that peer is
updated to the src address of that packet. With multi-endpoint,
which endpoint is updated? Is it simply appended to an ever-growing
list of recent endpoints? How to keep this clean and manageable?


I think there should be a distinction between endpoint addresses
provided in explicit configuration and those discovered through roaming.
Presumably, users put those addresses in the configuration file because
they expect them to be relatively stable. So I think those endpoints
should always be remembered.

As for addresses learned from roaming, a simple solution is some form of
aging. If the endpoint is changing because the machine is physically
moving (e.g. to a different wireless network), it's not likely that
previous address:port combinations will work again in the future, except
for a few common locations (home, work). So there's not much reason to
remember more than the last few. On the other hand, consider a
fixed-location user whose IP only changes when the router reboots every
few months. In that case, there's no chance of even the last one or two
endpoints being reused. So a time-based aging seems more appropriate.
Assuming (for illustration) you pick an endpoint every handshake, then
"this endpoint hasn't been chosen in the last 50 handshakes" means it's
okay to forget about.

So: 1) always keep manually added endpoints, and 2) only keep a few
roaming endpoints, and drop them when they are unused for a while.


As a separate point, I have a use case that I haven't seen discussed
yet. I have a WireGuard peer at Site A with a public IP. I have two
peers, a desktop and a laptop, at Site B, both behind NAT. Both of them
are configured with the machine at Site A as their only peer. Often I
take the laptop offsite, and then traffic between the desktop and laptop
goes through Site A. Good. However, when I have them on the same local
network, I'd like them to communicate directly (avoiding the round trip
to Site A).

The problem is that, if I add the desktop and laptop as peers to each
other, they stop sending traffic through Site A at all. Thus, when they
are _not_ on the same network (so behind two different NATs, as opposed
to no NAT) they cannot communicate at all.

It would be nice to get the desktop and laptop able to directly
communicate (which is what we're discussing mostly in this thread), but,
as a fallback, it would be nice to be able to say "if you can't
handshake with the peer for this internal IP, send their traffic through
the peer with the next larger enclosing subnet of allowed IPs. Then the
peer with the public IP and the allowed IPs of 0.0.0.0/0 could act as a
hub for peers behind stricter NATs.


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

Kernel Panic

[Samuel Holland]

Hello,

I'm getting a reproducable kernel panic with WireGuard snapshot 20161129
and Gentoo's hardened-sources 4.8.11 about one minute after boot
(persistent keepalive is set to 25 seconds). Netconsole output is
attached from three consecutive panics. For the first, since I have the
interface start on boot, I had to rmmod wireguard to enable netconsole,
and modprobe it again to prompt the panic. For the second two I was able
to repeat my commands fast enough to catch the panic happen on its own.

Regards,
Samuel
6,785,188154370,-;netconsole: network logging has already started
6,786,197345837,-;wireguard: WireGuard experimental-0.0.20161129 loaded. See 
www.wireguard.io for information.
6,787,197345997,-;wireguard: Copyright (C) 2015-2016 Jason A. Donenfeld 
. All Rights Reserved.
4,795,225469782,-;[ cut here ]
2,796,225472396,-;kernel BUG at crypto/scatterwalk.c:77!
4,797,225474985,-;invalid opcode:  [#1] SMP
4,798,225477551,c;Modules linked in:
4,799,225477595,+; wireguard(O)
4,800,225477622,+; iwldvm
4,801,225477643,+; mac80211
4,802,225477739,+; snd_hda_codec_hdmi
4,803,22541,+; snd_hda_codec_generic
4,804,225477804,+; i915
4,805,225477822,+; snd_hda_intel
4,806,225477849,+; snd_hda_codec
4,807,225477874,+; iwlwifi
4,808,225477898,+; snd_hwdep
4,809,225477921,+; snd_hda_core
4,810,225477947,+; cfg80211
4,811,225480566,+; thinkpad_acpi
4,812,225480593,+; snd_pcm
4,813,225480615,+; nvram
4,814,225480634,+; rfkill
4,815,225480654,+; snd_timer
4,816,225480744,+; input_leds
4,817,225480769,+; mei_me
4,818,225480789,+; led_class
4,819,225480812,+; snd
4,820,225480831,+; mei
4,821,225480850,+; intel_gtt
4,822,225480874,+; [last unloaded: wireguard]
4,823,225480911,+;
4,824,225483628,-;CPU: 0 PID: 0 Comm: swapper/0 Tainted: G   O
4.8.11-hardened #1
4,825,225486483,-;Hardware name: LENOVO 4290AD6/4290AD6, BIOS 8DET72WW (1.42 ) 
02/18/2016
4,826,225489355,-;task: 81e05a00 task.stack: 81e0
4,827,225492211,c;RIP: 0010:[]
4,828,225492275,+; [] scatterwalk_map_and_copy+0xdc/0xe0
4,829,225495162,-;RSP: 0018:c9003778  EFLAGS: 00010246
4,830,225498051,-;RAX:  RBX: 0010 RCX: 
0024
4,831,225500939,-;RDX: 0410 RSI:  RDI: 
4100394c
4,832,225503811,-;RBP: 0001 R08: 0001 R09: 

4,833,225506683,-;R10: c9003788 R11: 2e3bfb2e R12: 
ea0008430780
4,834,225509566,-;R13: c900394c R14: c900394c R15: 
c9003788
4,835,225512461,-;FS:  () GS:88021e20() 
knlGS:
4,836,225515343,-;CS:  0010 DS:  ES:  CR0: 80050033
4,837,225518254,-;CR2: 002c963d72d0 CR3: 01f67000 CR4: 
000606f0
4,838,225521123,-;Stack:
4,839,225523978,c; 0a3fc2490e75ef00
4,840,225524023,+; 001745e901e0860b
4,841,225524053,+; ea0008430782
4,842,225524082,+; 001000c0
4,843,225524111,+;
4,844,225526973,c; 
4,845,225527016,+; 
4,846,225527045,+; 0002
4,847,225527074,+; 
4,848,225527102,+;
4,849,225529985,c; 
4,850,225530028,+; 
4,851,225530057,+; c900398c
4,852,225530087,+; c9003a50
4,853,225530114,+;
4,854,225532937,-;Call Trace:
4,855,225535766,c; 
4,856,225535814,-; [] ? 
chacha20poly1305_encrypt_sg+0x423/0x550 [wireguard]
4,857,225538747,-; [] ? iwl_trans_pcie_tx+0xd64/0x12d0 
[iwlwifi]
4,858,225541716,-; [] ? packet_create_data+0x398/0x690 
[wireguard]
4,859,225544705,-; [] ? packet_send_queue+0x220/0x670 
[wireguard]
4,860,225547694,-; [] ? __list_add+0x16/0x40
4,861,225550640,-; [] ? packet_send_queue+0xb3/0x670 
[wireguard]
4,862,225553559,-; [] ? 
noise_handshake_begin_session+0xce7/0xf90 [wireguard]
4,863,225556518,-; [] ? dev_hard_start_xmit+0x92/0x1e0
4,864,225559482,-; [] ? __dev_queue_xmit+0x4f2/0x5b0
4,865,225562444,-; [] ? ip6_finish_output2+0x17e/0x470
4,866,225565413,-; [] ? ipv6_confirm+0x56/0x110
4,867,225568372,-; [] ? nf_iterate+0x54/0x70
4,868,225571314,-; [] ? ip6_output+0x3a/0xf0
4,869,225574248,-; [] ? ip6_fragment+0x980/0x980
4,870,225577203,-; [] ? NF_HOOK_THRESH.constprop.22+0x2a/0xa0
4,871,225580158,-; [] ? compat_ipv6_setsockopt+0xb0/0xb0
4,872,225583106,-; [] ? ndisc_send_skb+0x18e/0x2d0
4,873,225586071,-; [] ? addrconf_rs_timer+0x104/0x150
4,874,225589061,-; [] ? ipv6_get_lladdr+0xb0/0xb0
4,875,225592053,-; [] ? call_timer_fn+0x2b/0x110
4,876,225595031,-; [] ? run_timer_softirq+0x208/0x490
4,877,225598024,-; [] ? tick_sched_do_timer+0x30/0x30
4,878,225601022,-; [] ? tick_sched_timer+0x33/0x60
4,879,225604104,-; [] ? __hrtimer_run_queues+0xe8/0x260
4,880,225607105,-; [] ? __do_softirq+0xea/0x280
4,881,225610075,-; [] ? irq_exit+0x8c/0x90
4,882,225613018,-; [] ? smp_apic_timer_interrupt+0x39/0x50
4,883,225615985,-; [] ? apic_timer_interrupt+0x8b/0x90
4,884,225618849,c; 
4,885,225618889,-; [] ?