From: James R. <sj...@jd...> - 2012-02-07 23:02:09
|
Hi there, I was just wondering if anybody has seen the new Android 4.0 VPN API. It looks like a promising way to have a native Java OpenVPN solution on Android. http://developer.android.com/reference/android/net/VpnService.html There is a lot of interest in having an Android implementation of OpenVPN that does not require rooting the phone. Thanks, James |
From: Adriaan de J. <de...@fo...> - 2012-02-08 07:39:41
|
> -----Original Message----- > From: James Ring [mailto:sj...@jd...] > Sent: dinsdag 7 februari 2012 23:33 > To: ope...@li... > Subject: [Openvpn-devel] OpenVPN and Android 4.0 VPN API > > Hi there, > > I was just wondering if anybody has seen the new Android 4.0 VPN API. > It looks like a promising way to have a native Java OpenVPN solution on > Android. > > http://developer.android.com/reference/android/net/VpnService.html > > There is a lot of interest in having an Android implementation of > OpenVPN that does not require rooting the phone. > > Thanks, > James Hi James, I had a look at it a few months ago, and it looks really promising. It uses a tun device at its base. Network settings can be passed to There are a few tricky bits though: - The ABI expects a two-stage setup process: set up a control channel first for negotiation, then a call VpnService.Builder with the proper routing, DNS, addresses, etc. As far as I've been told by other developers, this is not how OpenVPN currently works. - We would need the management interface to export the routing and network parameters that need to be set, so that a surrounding android app can call the appropriate Java methods. - We would need a call in the management interface allowing the tun interface to be passed back into OpenVPN. None of these problems are impossible to solve, but they would take some refactoring of the OpenVPN main and connection code. Any input would of course be appreciated! Adriaan |
From: Gert D. <ge...@gr...> - 2012-02-08 08:10:13
|
Hi, On Wed, Feb 08, 2012 at 08:39:32AM +0100, Adriaan de Jong wrote: > - The ABI expects a two-stage setup process: set up a control > channel first for negotiation, then a call VpnService.Builder with > the proper routing, DNS, addresses, etc. As far as I've been told > by other developers, this is not how OpenVPN currently works. Unless I misunderstand something, this is *exactly* how OpenVPN works on the client side :-) - connect to server, figure out what we need to configure, then call init_tun(), add_route() etc. to configure interface and routing. Now, right now there is not a single "setup_stuff()" function but it's spread across interface init, interface ifconfig, route addition, etc. - but it shouldn't be too hard to build a set of "#ifdef ANDROID" functions that just gather this information and then pass it in one go to the API. > - We would need the management interface to export the routing > and network parameters that need to be set, so that a surrounding > android app can call the appropriate Java methods. Which very much sounds like the --service-pipe stuff that Heiko is building for Windows. openvpn.exe runs as unprivileged process, and when it wants to setup interfaces or routing, messages get sent via the service pipe to the (new) openvpn service that does the privileged operations. > - We would need a call in the management interface allowing the tun interface to be passed back into OpenVPN. Can't you just pass "--dev tun4" to OpenVPN? Or do you need to pass a file descriptor, handed to you by VpnService, instead of opening the tun inside OpenVPN? Maybe I don't fully understand how that API should be working. > None of these problems are impossible to solve, but they would > take some refactoring of the OpenVPN main and connection code. Any > input would of course be appreciated! Heiko's new service stuff already solves large parts of this :-) ... and for the rest, well, we'd need a volunteer that wants to *work* on this, not just ask for it... I don't have an Android device (and no time) so it wouldn't be me. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... |
From: James R. <sj...@jd...> - 2012-02-08 12:16:31
|
Hi Gert, On Wed, Feb 8, 2012 at 12:09 AM, Gert Doering <ge...@gr...> wrote: > Hi, > > On Wed, Feb 08, 2012 at 08:39:32AM +0100, Adriaan de Jong wrote: >> - The ABI expects a two-stage setup process: set up a control >> channel first for negotiation, then a call VpnService.Builder with >> the proper routing, DNS, addresses, etc. As far as I've been told >> by other developers, this is not how OpenVPN currently works. > > Unless I misunderstand something, this is *exactly* how OpenVPN works > on the client side :-) - connect to server, figure out what we need to > configure, then call init_tun(), add_route() etc. to configure interface > and routing. > > Now, right now there is not a single "setup_stuff()" function but it's > spread across interface init, interface ifconfig, route addition, etc. - > but it shouldn't be too hard to build a set of "#ifdef ANDROID" functions > that just gather this information and then pass it in one go to the API. > >> - We would need the management interface to export the routing >> and network parameters that need to be set, so that a surrounding >> android app can call the appropriate Java methods. > > Which very much sounds like the --service-pipe stuff that Heiko is > building for Windows. openvpn.exe runs as unprivileged process, and > when it wants to setup interfaces or routing, messages get sent via > the service pipe to the (new) openvpn service that does the privileged > operations. This sounds like a good way to go. I assume the service pipe can handle tearing down the tunnel as well. >> - We would need a call in the management interface allowing the tun interface to be passed back into OpenVPN. > > Can't you just pass "--dev tun4" to OpenVPN? Or do you need to pass a > file descriptor, handed to you by VpnService, instead of opening the tun > inside OpenVPN? > > Maybe I don't fully understand how that API should be working. Looks like you need to pass a native fd. OpenVPN would not be able to open the device itself. There looks to be a chicken and egg problem here though: the fd is returned by the VpnService.Builder.establish() method http://developer.android.com/reference/android/net/VpnService.Builder.html#establish() This needs to happen after a bunch of parameters are already known. Since OpenVPN would normally take care of negotiating these with the other end, it would seem that the tunnel fd is not available to OpenVPN in time to do this. Perhaps the user would have to configure the route, search domain, IP address and other parameters in advance of starting the VPN connection. That would suck. >> None of these problems are impossible to solve, but they would >> take some refactoring of the OpenVPN main and connection code. Any >> input would of course be appreciated! > > Heiko's new service stuff already solves large parts of this :-) > > ... and for the rest, well, we'd need a volunteer that wants to *work* on > this, not just ask for it... I don't have an Android device (and no > time) so it wouldn't be me. I'm raising my hand. This path sounds better than what I thought would be necessary (writing OpenVPN client implementation in Java). I'm also asking around here at Google to see if somebody with more experience with Android is interested in helping out. I'm sure there is sufficient interest on both sides (Android and OpenVPN) to get something working. This would make a niche segment of Android users very happy I'm sure. > gert Regards, James |
From: Gert D. <ge...@gr...> - 2012-02-08 18:22:53
|
Hi, On Wed, Feb 08, 2012 at 04:16:20AM -0800, James Ring wrote: > Looks like you need to pass a native fd. OpenVPN would not be able to > open the device itself. There looks to be a chicken and egg problem > here though: the fd is returned by the VpnService.Builder.establish() > method > > http://developer.android.com/reference/android/net/VpnService.Builder.html#establish() > > This needs to happen after a bunch of parameters are already known. > Since OpenVPN would normally take care of negotiating these with the > other end, it would seem that the tunnel fd is not available to > OpenVPN in time to do this. Perhaps the user would have to configure > the route, search domain, IP address and other parameters in advance > of starting the VPN connection. That would suck. You only need the *tunnel* FD to forward packets to the android networking stack. To connect to the OpenVPN server, you use a normal socket, which would have to be opened by OpenVPN - but that's a standard network operation which doesn't need special privileges. Right now, passing in the tun device file handle from an external source isn't something directly supported, but the open_tun() method is very platform specific anyway, so it's not unsolvable. [..] > > ... and for the rest, well, we'd need a volunteer that wants to *work* on > > this, not just ask for it... I don't have an Android device (and no > > time) so it wouldn't be me. > > I'm raising my hand. This path sounds better than what I thought would > be necessary (writing OpenVPN client implementation in Java). I'm also > asking around here at Google to see if somebody with more experience > with Android is interested in helping out. I'm sure there is > sufficient interest on both sides (Android and OpenVPN) to get > something working. This would make a niche segment of Android users > very happy I'm sure. This would be extremely cool! gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... |
From: James R. <sj...@jd...> - 2012-03-02 00:09:14
|
Hey Arne, On Thu, Mar 1, 2012 at 3:05 PM, Arne Schwabe <sc...@un...> wrote: > >>> ... and for the rest, well, we'd need a volunteer that wants to *work* on >>> this, not just ask for it... I don't have an Android device (and no >>> time) so it wouldn't be me. >> >> I'm raising my hand. This path sounds better than what I thought would >> be necessary (writing OpenVPN client implementation in Java). I'm also >> asking around here at Google to see if somebody with more experience >> with Android is interested in helping out. I'm sure there is >> sufficient interest on both sides (Android and OpenVPN) to get >> something working. This would make a niche segment of Android users >> very happy I'm sure. >> > Are you already actively working on this? Otherwise I would start working on > the feature. I have already some experience with the android sdk and ndk. I > think I would solve the problem of fd passing and so on by turning openvpn > into a JNI library. Unfortunately I haven't started anything. If you do get something you'd like to share, I'd be happy to try it out and contribute patches. > Arne > |
From: Arne S. <ar...@rf...> - 2012-04-05 20:22:50
|
Am 02.03.12 00:05, schrieb Arne Schwabe: > >>> ... and for the rest, well, we'd need a volunteer that wants to >>> *work* on >>> this, not just ask for it... I don't have an Android device (and no >>> time) so it wouldn't be me. >> I'm raising my hand. This path sounds better than what I thought would >> be necessary (writing OpenVPN client implementation in Java). I'm also >> asking around here at Google to see if somebody with more experience >> with Android is interested in helping out. I'm sure there is >> sufficient interest on both sides (Android and OpenVPN) to get >> something working. This would make a niche segment of Android users >> very happy I'm sure. >> > Are you already actively working on this? Otherwise I would start > working on the feature. I have already some experience with the > android sdk and ndk. I think I would solve the problem of fd passing > and so on by turning openvpn into a JNI library. > I have managed to hack a proof of concept together. (Screen shot here: http://plai.de/android/Bildschirmfoto%202012-04-05%20um%2021.00.57.png) The core VPN functionality already works. What needs to be done is proper error handling and configuration, espically integeration of Androids certificate Managment). Arne |
From: James R. <sj...@jd...> - 2012-04-06 18:12:18
|
Hey Arne, On Thu, Apr 5, 2012 at 12:19 PM, Arne Schwabe <sc...@un...> wrote: > I have managed to hack a proof of concept together. (Screen shot here: > http://plai.de/android/Bildschirmfoto%202012-04-05%20um%2021.00.57.png) > > The core VPN functionality already works. What needs to be done is proper > error handling and configuration, espically integeration of Androids > certificate Managment). This looks excellent! When can I try it out/hack on it? :) > Arne > Thanks, James |
From: Arne S. <ar...@rf...> - 2012-04-09 22:47:47
|
Am 06.04.12 20:12, schrieb James Ring: > Hey Arne, > > On Thu, Apr 5, 2012 at 12:19 PM, Arne Schwabe<sc...@un...> wrote: >> I have managed to hack a proof of concept together. (Screen shot here: >> http://plai.de/android/Bildschirmfoto%202012-04-05%20um%2021.00.57.png) >> >> The core VPN functionality already works. What needs to be done is proper >> error handling and configuration, espically integeration of Androids >> certificate Managment). > This looks excellent! When can I try it out/hack on it? :) > For all the impatient: http://plai.de/android/icsopenvpn.apk But remember this has pre alpha status. Connecting should work, but closing the connection or trying to connect a second time will probably not work. And don't look too close at the patch in the same directory there are still some hacks in the code I need to remove. Arne |
From: James R. <sj...@jd...> - 2012-02-08 12:47:47
|
Hey, On Wed, Feb 8, 2012 at 4:16 AM, James Ring <sj...@jd...> wrote: > Looks like you need to pass a native fd. OpenVPN would not be able to > open the device itself. There looks to be a chicken and egg problem > here though: the fd is returned by the VpnService.Builder.establish() > method > > http://developer.android.com/reference/android/net/VpnService.Builder.html#establish() > > This needs to happen after a bunch of parameters are already known. > Since OpenVPN would normally take care of negotiating these with the > other end, it would seem that the tunnel fd is not available to > OpenVPN in time to do this. Perhaps the user would have to configure > the route, search domain, IP address and other parameters in advance > of starting the VPN connection. That would suck. Perhaps I wrote this too hastily. I wasn't thinking of how OpenVPN actually works. OpenVPN would: * open the connection (tcp or udp) to the remote end * negotiate session parameters * provide the Android Java wrapper with the session parameters via the service pipe * receive the file descriptor to use as the tun/tap device from the Android Java wrapper via the service pipe Another thing to think about would be whether the tunnel could be reestablished after the device wakes up from sleep. Regards, James |
From: Gert D. <ge...@gr...> - 2012-02-08 18:24:57
|
Hi, On Wed, Feb 08, 2012 at 04:47:35AM -0800, James Ring wrote: > Perhaps I wrote this too hastily. I wasn't thinking of how OpenVPN > actually works. OpenVPN would: > > * open the connection (tcp or udp) to the remote end > * negotiate session parameters > * provide the Android Java wrapper with the session parameters via the > service pipe > * receive the file descriptor to use as the tun/tap device from the > Android Java wrapper via the service pipe Exactly. The first three things are sort of "nearly done", the "receive file descriptor to use for tun/tap" would need to be implemented (tun.c, open_tun(), #ifdef ANDROID_MAGIC_VPN :-) ) > Another thing to think about would be whether the tunnel could be > reestablished after the device wakes up from sleep. Depending on the OpenVPN --ping parameter settings, it would reconnect to the server automatically - and then re-initialize the interface. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... |
From: James R. <sj...@jd...> - 2012-02-08 19:27:17
|
Hey Gert, On Wed, Feb 8, 2012 at 10:24 AM, Gert Doering <ge...@gr...> wrote: > Hi, > > On Wed, Feb 08, 2012 at 04:47:35AM -0800, James Ring wrote: >> Perhaps I wrote this too hastily. I wasn't thinking of how OpenVPN >> actually works. OpenVPN would: >> >> * open the connection (tcp or udp) to the remote end >> * negotiate session parameters >> * provide the Android Java wrapper with the session parameters via the >> service pipe >> * receive the file descriptor to use as the tun/tap device from the >> Android Java wrapper via the service pipe > > Exactly. The first three things are sort of "nearly done", the > "receive file descriptor to use for tun/tap" would need to be > implemented (tun.c, open_tun(), #ifdef ANDROID_MAGIC_VPN :-) ) I was thinking about this a little more. Presumably openvpn will be forked and exec'd before the file descriptor is available. Presumably openvpn could connect to a UNIX domain socket inside open_tun() if ANDROID_MAGIC_VPN is specified. Does other code within openvpn care whether the fd is a UNIX socket or a tun/tap device? I'm guessing there may be some ioctls it wants to perform on the device. Other than that, openvpn would be reading and writing IP packets with an encrypted payload and the Java wrapper would be responsible for forwarding the bytes between the UNIX domain socket and the actual tun device. Regards, James |
From: Fabian K. <fab...@le...> - 2012-02-08 20:30:07
|
Hi James, 2012/2/8 James Ring <sj...@jd...>: > On Wed, Feb 8, 2012 at 10:24 AM, Gert Doering <ge...@gr...> wrote: >> Exactly. The first three things are sort of "nearly done", the >> "receive file descriptor to use for tun/tap" would need to be >> implemented (tun.c, open_tun(), #ifdef ANDROID_MAGIC_VPN :-) ) > > I was thinking about this a little more. Presumably openvpn will be > forked and exec'd before the file descriptor is available. Presumably > openvpn could connect to a UNIX domain socket inside open_tun() if > ANDROID_MAGIC_VPN is specified. > > Does other code within openvpn care whether the fd is a UNIX socket or > a tun/tap device? I'm guessing there may be some ioctls it wants to > perform on the device. Other than that, openvpn would be reading and > writing IP packets with an encrypted payload and the Java wrapper > would be responsible for forwarding the bytes between the UNIX domain > socket and the actual tun device. Unless Android's Linux is stripped down in this respect, you can pass file descriptors over UNIX domain sockets. (The first google hit is [0]. The interface isn't beautiful, but it works nicely.) This would allow you to take the java wrapper out of the loop as far as the raw data shuffling is concerned. Cheers Fabian 0: http://www.lst.de/~okir/blackhats/node121.html |
From: Gert D. <ge...@gr...> - 2012-02-08 20:40:41
|
Hi, On Wed, Feb 08, 2012 at 11:27:10AM -0800, James Ring wrote: > > Exactly. The first three things are sort of "nearly done", the > > "receive file descriptor to use for tun/tap" would need to be > > implemented (tun.c, open_tun(), #ifdef ANDROID_MAGIC_VPN :-) ) > > I was thinking about this a little more. Presumably openvpn will be > forked and exec'd before the file descriptor is available. Presumably > openvpn could connect to a UNIX domain socket inside open_tun() if > ANDROID_MAGIC_VPN is specified. > > Does other code within openvpn care whether the fd is a UNIX socket or > a tun/tap device? I'm guessing there may be some ioctls it wants to > perform on the device. There aren't any ioctl()s (I'm aware of) for tun/tap devices, but blocking/non-blocking behaviour might be an interesting problem, and performance / battery usage won't be helped by copying the packet around another time... > Other than that, openvpn would be reading and > writing IP packets with an encrypted payload and the Java wrapper > would be responsible for forwarding the bytes between the UNIX domain > socket and the actual tun device. Don't show idea that to Jan-Just, he's already complaining that OpenVPN wastes too many CPU cycles... gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... |
From: Fabian K. <fab...@le...> - 2012-02-08 20:55:58
|
Hi Gert, 2012/2/8 Gert Doering <ge...@gr...>: > On Wed, Feb 08, 2012 at 11:27:10AM -0800, James Ring wrote: >> Does other code within openvpn care whether the fd is a UNIX socket or >> a tun/tap device? I'm guessing there may be some ioctls it wants to >> perform on the device. > > There aren't any ioctl()s (I'm aware of) for tun/tap devices, but > blocking/non-blocking behaviour might be an interesting problem, "The file descriptor is put into non-blocking mode by default to avoid blocking Java threads." [0] >> Other than that, openvpn would be reading and >> writing IP packets with an encrypted payload and the Java wrapper >> would be responsible for forwarding the bytes between the UNIX domain >> socket and the actual tun device. > > Don't show idea that to Jan-Just, he's already complaining that OpenVPN > wastes too many CPU cycles... So let's hope the fd passing I mentioned in my other mail works on Android. :) Cheers Fabian 0: http://developer.android.com/reference/android/net/VpnService.Builder.html#establish() |