Multiple VPN connections on Android
Jason A. Donenfeld
Jason at zx2c4.com
Mon Apr 8 03:39:48 CEST 2019
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 at gmail.com> wrote:
> On 3/26/19 8:49 PM, mikma.wg at 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 at lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20190408/96c35c86/attachment-0001.html>
More information about the WireGuard
mailing list