From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C24EBC10F0E for ; Mon, 8 Apr 2019 01:40:26 +0000 (UTC) Received: from krantz.zx2c4.com (krantz.zx2c4.com [192.95.5.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id EBCFF20880 for ; Mon, 8 Apr 2019 01:40:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="TiX9kdDj" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EBCFF20880 Authentication-Results: mail.kernel.org; dmarc=pass (p=none dis=none) header.from=zx2c4.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=wireguard-bounces@lists.zx2c4.com Received: from krantz.zx2c4.com (localhost [IPv6:::1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 839bf199; Mon, 8 Apr 2019 01:37:28 +0000 (UTC) Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 3e59abc8 for ; Mon, 8 Apr 2019 01:37:26 +0000 (UTC) Received: from frisell.zx2c4.com (frisell.zx2c4.com [192.95.5.64]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 15150613 for ; Mon, 8 Apr 2019 01:37:26 +0000 (UTC) Received: by frisell.zx2c4.com (ZX2C4 Mail Server) with ESMTP id d4fea37d for ; Mon, 8 Apr 2019 01:16:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=zx2c4.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=mail; bh=2DE4Txee6vOHlvGu/ZvTzxNA+Fw=; b=TiX9kd DjmQobY/bCcvc3csL6jvxt9tDAwUGC55BQMpc1kLgr1TJWGK+UYXbs1sLRI4Jw6d 2owiNMVRDMc7vCLFUzEg+VyBQjz70JfHvzFN6e1gtqpJqeGURrN6LeJdJs4Sm9Eb WHW2Z54ZfDdDC07OSQigcdEuWqtwkEU60Wvd+YKC3ox4lNI5yj+t1m+K5u30kcaF RiuySl3KW+4K3XzvvDE3w9r4LJH1nFrjztYpD2AvrowcAWp6M7rhDTmEeFapJibB jIDrJXe0HJ9r+E0lO6fFk3JH/hLMCHQtAFYhd+EVrY9D70Vz499WOwm5VsKyFhq7 Z0H23M0+ZwvMqznw== Received: by frisell.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 8cd104d7 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO) for ; Mon, 8 Apr 2019 01:16:12 +0000 (UTC) Received: by mail-oi1-f181.google.com with SMTP id y84so9156574oia.12 for ; Sun, 07 Apr 2019 18:40:04 -0700 (PDT) X-Gm-Message-State: APjAAAWyzML7zrW+lttBItd2Y0ByOYUPaJWBu8jMzlkf8YwhGFWisNrB Fbr15UN8Fr5Q/GIn1UocFbOIVV0dAycSM8W57BY= X-Google-Smtp-Source: APXvYqxV/RmMpSmzS8uE5nzIpe2fVlfjyIN/qnItz3dqjuuzoMmalskTyHfWCMwwVA9VRjgtkCtnl4hrEZY5ToBkS3w= X-Received: by 2002:aca:e58b:: with SMTP id c133mr14291411oih.119.1554687602273; Sun, 07 Apr 2019 18:40:02 -0700 (PDT) MIME-Version: 1.0 References: <75dc1198-7727-f342-2756-a160f3f3f994@gmail.com> <911c5ed5-0bf8-80bb-cf15-7b2c6ee896fa@m7n.se> In-Reply-To: From: "Jason A. Donenfeld" Date: Mon, 8 Apr 2019 10:39:48 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Multiple VPN connections on Android To: Julian Orth Cc: WireGuard mailing list X-BeenThere: wireguard@lists.zx2c4.com X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2934158527919456010==" Errors-To: wireguard-bounces@lists.zx2c4.com Sender: "WireGuard" --===============2934158527919456010== Content-Type: multipart/alternative; boundary="00000000000045366a0585faea0c" --00000000000045366a0585faea0c Content-Type: text/plain; charset="UTF-8" That's an interesting point; in theory it's probably possible to multiplex into one tun device, provided the routes for each distinct wg interface don't overlap. On Sun, Apr 7, 2019, 19:37 Julian Orth wrote: > On 3/26/19 8:49 PM, mikma.wg@lists.m7n.se wrote:> > > On 2019-03-26 15:17, Julian Orth wrote: > >> Hello list, > >> > >> I'm currently using WireGuard on Android for two purposes: > >> > >> 1. Routing all traffic via a commercial VPN provider to protect myself > on > >> open wireless networks. > >> 2. Connecting to my home network. > >> > >> Unfortunately WireGuard on Android does not allow me to do both of these > >> things at the same time. I assume this is because VpnService [1] only > allows 1 > >> VPN connection at a time. > > > > Can't you add the peer for your home network to the same configuration > (tun > > device) as the peer for the commercial VPN provider? It seems a straight > > forward solution to me if you are okay with the IP addresses assigned by > the > > VPN provider. > > Using the same src IP is not going to work in my case. The VPN provider > might > also assign me a new IP and then I might have to reconfigure my home > network. > Not something I want to deal with. > > But this would also require me to share the same public key between my home > network and the VPN provider. For some reason this does not feel right to > me. On > the other hand, I use the same SSH key on multiple sites so maybe this > feeling > is not justified. > > My current provider allows me to generate the key pair locally and to only > send > them the public key. If they insistet on generating the keys on their > servers > and sending me the private key, then this solution would be impossible. > > > > >> > >> Has any thought been put into emulating multiple tun devices in user > space? > > > > I don't see why you would need multiple tun devices. > > By "emulating multiple tun devices" I did not mean emulating all of the > functionality of tun devices. Packets are processed as follows right now: > > 1. Kernel chooses the correct route and device > 2. Kernel sends the packet via the device > 3. If the device is a wireguard tun device: > a. Choose the peer and wrap the packet in a wireguard packet > b. Goto 1 with the original packet replaced by the wrapped packet > > What I suggest is emulating steps 1 and 2. An emulated tun devices would > therefore only have to consist of a set of assigned routes and an instance > of > the wireguard core that implements step 3. > > Let's say the Android app currently processes packets as follows: > > void process(packet) { > peer, packet := wireguard.process(packet); > peer.udp_send(packet); > } > > My suggestion is to change this as follows: > > void process(packet) { > seen_peers := { }; // a set > while (true) { > tap_dev := find_tap_dev(packet.dst); > peer, packet := tap_dev.process(packet); > if (seen_peers.contains(peer)) { > // routing loop > return; > } > seen_peers.add(peer); > if (find_tap_dev(packet.dst) == null) { > peer.udp_send(packet); > return; > } > } > } > > The Android tun device created via VpnService would then of course contain > the > union of all routes of the emulated tun devices. > > > It is possible to > add > > multiple IPv4 and IPv6 addresses to the tun device, but there may be a > problem > > with the source address selection. Linux allows specifying a preferred > address > > for each route, but it isn't possible in the Android API AFAIK. If you > have a > > rooted device then you can potentially update the routing tables with the > > preferred source address for each VPN route. > > I don't think routing should be necessary for this. Afaik, other VPN apps > already support using multiple tunnels at once. > > > > > /Mikma > > PS: Your mail was classified as spam by gmail. > _______________________________________________ > WireGuard mailing list > WireGuard@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/wireguard > --00000000000045366a0585faea0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That's an interesting point; in theory it's = probably possible to multiplex into one tun device, provided the routes for= each distinct wg interface don't overlap.

On Sun, Apr 7, 2019, 19:37 Juli= an Orth <ju.orth@gmail.com> = wrote:
On 3/26/19 8:49 PM, mikm= a.wg@lists.m7n.se wrote:>
> On 2019-03-26 15:17, Julian Orth wrote:
>> Hello list,
>>
>> I'm currently using WireGuard on Android for two purposes:
>>
>> 1. Routing all traffic via a commercial VPN provider to protect my= self on
>>=C2=A0 =C2=A0 =C2=A0open wireless networks.
>> 2. Connecting to my home network.
>>
>> Unfortunately WireGuard on Android does not allow me to do both of= these
>> things at the same time. I assume this is because VpnService [1] o= nly allows 1
>> VPN connection at a time.
>
> Can't you add the peer for your home network to the same configura= tion (tun
> device) as the peer for the commercial VPN provider? It seems a straig= ht
> forward solution to me if you are okay with the IP addresses assigned = by the
> VPN provider.

Using the same src IP is not going to work in my case. The VPN provider mig= ht
also assign me a new IP and then I might have to reconfigure my home networ= k.
Not something I want to deal with.

But this would also require me to share the same public key between my home=
network and the VPN provider. For some reason this does not feel right to m= e. On
the other hand, I use the same SSH key on multiple sites so maybe this feel= ing
is not justified.

My current provider allows me to generate the key pair locally and to only = send
them the public key. If they insistet on generating the keys on their serve= rs
and sending me the private key, then this solution would be impossible.

>
>>
>> Has any thought been put into emulating multiple tun devices in us= er space?
>
> I don't see why you would need multiple tun devices.

By "emulating multiple tun devices" I did not mean emulating all = of the
functionality of tun devices. Packets are processed as follows right now:
1. Kernel chooses the correct route and device
2. Kernel sends the packet via the device
3. If the device is a wireguard tun device:
=C2=A0 =C2=A0a. Choose the peer and wrap the packet in a wireguard packet =C2=A0 =C2=A0b. Goto 1 with the original packet replaced by the wrapped pac= ket

What I suggest is emulating steps 1 and 2. An emulated tun devices would therefore only have to consist of a set of assigned routes and an instance = of
the wireguard core that implements step 3.

Let's say the Android app currently processes packets as follows:

void process(packet) {
=C2=A0 =C2=A0 peer, packet :=3D wireguard.process(packet);
=C2=A0 =C2=A0 peer.udp_send(packet);
}

My suggestion is to change this as follows:

void process(packet) {
=C2=A0 =C2=A0 seen_peers :=3D { }; // a set
=C2=A0 =C2=A0 while (true) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 tap_dev :=3D find_tap_dev(packet.dst);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 peer, packet :=3D tap_dev.process(packet);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (seen_peers.contains(peer)) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // routing loop
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 seen_peers.add(peer);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (find_tap_dev(packet.dst) =3D=3D null) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 peer.udp_send(packet);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
}

The Android tun device created via VpnService would then of course contain = the
union of all routes of the emulated tun devices.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 It is possible to add
> multiple IPv4 and IPv6 addresses to the tun device, but there may be a= problem
> with the source address selection. Linux allows specifying a preferred= address
> for each route, but it isn't possible in the Android API AFAIK. If= you have a
> rooted device then you can potentially update the routing tables with = the
> preferred source address for each VPN route.

I don't think routing should be necessary for this. Afaik, other VPN ap= ps
already support using multiple tunnels at once.

>
> /Mikma

PS: Your mail was classified as spam by gmail.
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinf= o/wireguard
--00000000000045366a0585faea0c-- --===============2934158527919456010== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard --===============2934158527919456010==--