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 <ju.orth@gmail.com> 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