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 >