Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Android Businesses Security IT

Securing Android For the Enterprise 136

Orome1 writes "While many companies use IPsec for secure remote access to their networks, no integrated IPsec VPN client is available on Android. Apple has already fixed this shortcoming in iOS, in part, because it wanted make the iPhone attractive for businesses. The Android operating system doesn't just lack an integrated IPsec VPN client, it also makes installing and configuring third-party VPN software quite complicated. IPsec VPN clients have to be integrated into the kernel of each device, and the client software has to be installed specifically for a memory area. This means that the firmware of each Android smartphone or tablet has to be modified accordingly. Until a 'real' IPsec VPN client is available, Android users can use their devices' integrated VPN clients based on PPTP or L2TP, which is deployed over IPsec. A 'real' IPsec VPN connection, however, is more secure because it encrypts data prior to authentication."
This discussion has been archived. No new comments can be posted.

Securing Android For the Enterprise

Comments Filter:
  • Oh (Score:5, Funny)

    by deep9x ( 1068252 ) on Wednesday January 04, 2012 @02:14AM (#38582494) Homepage
    I really thought this article was going to be about Data.
    • Man, I logged in to make this exact joke, but I didn't expect it would be first post!!!!

  • by geekylinuxkid ( 831805 ) on Wednesday January 04, 2012 @02:17AM (#38582504) Journal
    Android needs some sort of remote wipe software to make it even remotely feasible for most businesses. For example, the government requires remote wipe, and some sort of encryption. Until Android has a solution for these two, the VPN-less capability is moot.
    • by afidel ( 530433 ) on Wednesday January 04, 2012 @02:28AM (#38582552)
      There are MDM's that provide those capabilities, heck just hook most Android phones up to any ActiveSync compatible server or service and you get basic remote wipe. If it weren't for the fact that we provide Citrix for remote access the limitations on getting most Android devices working with ASA would have been a serious redmark against adoption, but as it stands the huge number of usability problems we ran into trumped everything else. Android is great as a geek OS, and fairly good for a consumer OS (my wife likes her Optimus V just fine), but the persistent issues like WiFi clients that randomly failed to work or the email clients that just stopped receiving email from the Exchange server and required a device wipe and resync to reestablish communications to the weird certificate errors we would get all made it so we were not going to foist it as a platform on our users. We offered them iOS or Blackberry and 2/3rds chose to stay on Blackberry for the superior core email capabilities. Personally I'm still on my Android test device because for me the small nagging flaws are outweighed by a physical keyboard (big plus over an iphone) and huge selection of applications and a decent browser (big win over Blackberry).
    • by BulletMagnet ( 600525 ) on Wednesday January 04, 2012 @02:29AM (#38582558)

      Android needs some sort of remote wipe software to make it even remotely feasible for most businesses. For example, the government requires remote wipe, and some sort of encryption. Until Android has a solution for these two, the VPN-less capability is moot.

      Like this? [good.com]

    • by Anonymous Coward on Wednesday January 04, 2012 @02:30AM (#38582564)

      Remote wipe has apparently been supported via activesync since android 2.2

    • Already there (Score:5, Informative)

      by Namarrgon ( 105036 ) on Wednesday January 04, 2012 @03:55AM (#38582924) Homepage
      Exchange-based remote wipe support was added in Android 2.2 [android.com]. Encrypted storage and password policies were added in Android 3.0 [android.com]. Full-device encryption was added in Android 4.0 [android.com], along with an API for third-party VPN solutions, and IPsec support for the built-in VPN client.
      • Re: (Score:2, Funny)

        The way it works is
        Server hey mr phone do you support activesync remote wipe?
        Phone sure do (ha ha ha ha)
        Server ok thank you, what about password policy?
        Phone sure whatever you want sweetie

        There are market apps they respond with yes and then bin the request
        So .... It does not count.

        • by Rich0 ( 548339 )

          So, that is true of every device that exists, and will ever exist, unless you use trusted computing and have no local exploits. Certainly this can be done on the iPhone and every other commercially-available smartphone.

          You're basically talking about DRM, and that is theoretically impossible to implement perfectly, though in some cases it can be made reasonably difficult to bypass.

    • Re: (Score:2, Informative)

      by Weezul ( 52464 )

      Android has by-far the best cryptography suite [guardianproject.info] amongst all phone/tablet OSs, well unless your running vanilla Linux on a tablet.

      • by Anonymous Coward
        About your sig:

        The Christian religion has been and still is the principal enemy of moral progress in the world.

        You must just love the Muslims and Hindus then. After all I never see any corruption in countries where they are in the majority.

    • by Anonymous Coward

      Why would you even store sensitive data on a remote device at all ?

      Who needs "remote-wipe" if all I have is a couple of photos of the cute lady at In and Out ?

      I'm in healthcare and we are prohibited from storing sensitive data on our laptops. Why should Android devices be any different ?

      • You are correct, folks shouldn't be storing sensitive data on a portable device of any kind. Our laptops are required to be encrypted using a FIPS 140-2 certified product to prevent loss of any information because not everyone follows the "don't store sensitive data on your laptop" policy.

        With our blackberries we have access to our intranet, I guess the remote wipe feature would be helpful if someone happened to crack a password in less than 6 attempts and gain access to our intranet and possibly other int

      • by jon3k ( 691256 )
        HIPAA does not prohibit the storage of sensitive data on laptops and other mobile devices, it just requires you to secure data at rest.
      • by bgat ( 123664 )

        Why would you even store sensitive data on a remote device at all ?

        Who needs "remote-wipe" if all I have is a couple of photos of the cute lady at In and Out ?

        I'm in healthcare and we are prohibited from storing sensitive data on our laptops. Why should Android devices be any different ?

        Android devices AREN'T different, actually.

        Part of the confusion is buzzword-compliance, part is a desire by competitors to cast Android-based devices in a "not for professionals" light, and the rest is just addressing users who email, etc. sensitive data around and thereby bypass the no-sensitive-data-on-the-device mandate. (Such bypasses are almost irresistible in situations where you have poor connectivity back to the remote server where the sensitive data is normally kept).

        Finally, unless you want to t

    • As the other poster said, MDM is your best bet. ActiveSync works for basic remote-wipe capabilities, but has a specific caveat. For a device to connect to the server and receive a remote-wipe command, the credentials it uses have to be correct, which is contradictory to the whole "reset the user's password after a device is stolen" policy. Having said that, MDM is a difficult area to research without running through three books' worth of marketing/spam.
    • Android needs some sort of remote wipe software to make it even remotely feasible for most businesses. For example, the government requires remote wipe, and some sort of encryption. Until Android has a solution for these two, the VPN-less capability is moot.

      The Google Apps Device Policy [android.com] app supports password policies and remote wipe, and Ice Cream Sandwich supports full-device encryption (I turned it on for my own ICS phone, took about an hour to encrypt the 16GB internal storage partition plus two or three reboots).

  • SSH is all you'll ever fucking need. You can do anything you need over SSH, including a true VPN or just VPN-like functionality. And it's as secure as it gets.

    I manage all of my servers from my android devices, and have done so for a long time. What the hell is this guy complaining about?

    Regarding the guy talking about the remote wipe ... well, that's a stupid concept. A lost/stolen phone usually doesn't have network access, and even if you do it as a deads man switch, it's not really secure. Just encrypt w

    • The activsync rules include remote wipe capability anyway.
      Android supports that...

    • by thegarbz ( 1787294 ) on Wednesday January 04, 2012 @03:48AM (#38582892)

      Stupid article is stupid because the *current* version of Android actually has full native IPSec support. I wish this is just a case of Slashdot being late to post, but TFA is dated Jan 3rd 2012 so it must just be a blogger who's not up with the times.

      • by Xugumad ( 39311 ) on Wednesday January 04, 2012 @07:19AM (#38583728)

        > *current* version of Android actually has full native IPSec support

        Do you mean Ice Cream Sandwich? In which case, to be fair it's not what you'd call in widespread use yet... (I have never seen anyone with an ICS device IRL, or heard of anyone having one)

        • I'm running Gingerbread and have a VPN option with PPTP, L2TP, & OpenVPN. Could be a CyanogenMod feature but I don't think so.
          • by csnydermvpsoft ( 596111 ) on Wednesday January 04, 2012 @09:27AM (#38584478)

            I'm running Gingerbread and have a VPN option with PPTP, L2TP, & OpenVPN. Could be a CyanogenMod feature but I don't think so.

            OpenVPN is a Cyanogenmod addition: [source] [wikipedia.org]

            • Yes, I'm sure that many large corporations will welcome your jail-broken phones running custom kernels(*) with open arms. They will also provide mileage reimbursements for commuting to the office on your flying pig.

              *ignoring the fact that this feature could be easily integrated into the stock vanilla build because drumroll that's what CM was built from
        • That doesn't make "Android" any less "ready for the Enterprise", though does it? The Enterprise in question could go out and buy up a hundred Galaxy Nexuses to give out to its staff, regardless of how many are currently floating around in the wild.
        • Time to leave that cave...on Mars. I've got one. Updates for last year's phones are going to start rolling out this quarter. The next wave of tablets will be ICS.

          If "IT" is just now starting to look at this, it'll be 6-12 months before anything happens, by which time, ICS will be mature. You have to keep that lead time in mind when trying to shift a major segment of your user base to a new platform. It'll never happen overnight and it often has to be synced to contract dates and such. If you build you

        • Do you mean Ice Cream Sandwich? In which case, to be fair it's not what you'd call in widespread use yet...

          And just what do you think an enterprise is going to look at when rolling out a new device? An obsolete phone from last year? There are ICS devices on the market, there's actually been three minor updates to ICS already since the first device has been released.

          The fact is that this blog is saying that the enterprise won't take up Android because of lack of VPN, whereas the current advertised wonderboy of the Android world features the latest software which has the said feature.

          Not only that but there have b

      • by AJH16 ( 940784 )

        It does not have CISCO IPSEC support. This is likely what the blogger was referring to when he mentions integrated IPSEC client. There are alternatives with a tun.ko capable kernel and third party VPN software, but it is a rather large pain to configure on most devices and impossible on many without custom roms. I've been trying to get it working on my GNEX but support for authenticators seems to be lacking in the third party clients that I have found.

    • No SSH may be all you need, but when the corporate IT decrees that you're not getting past the firewall except via $officalsolution you need $officalsolution. It's great how many of you guys work in some perfect little paradise where you chose all the IT solutions to be most useful for your personal preferences; but most of us work for companies, and outside of our box have little or no influence on how it's all setup. I guestimate that 85-90% of the people on this site are at least somewhat beholden to s

  • OpenSSH (Score:5, Informative)

    by 1s44c ( 552956 ) on Wednesday January 04, 2012 @02:25AM (#38582540)

    Use OpenSSH. You can tunnel TCP over SSH, it works very nicely on iphones and nokia n900's. I've not tested it on android but It should work.

    The very last thing anyone should be doing is bridging their networks to a mobile phone.

    • +1 this brother

    • "The very last thing anyone should be doing is bridging their networks to a mobile phone", which sadly is exactly what the corporate IT droids want to do, because any simple solution like OpenSSH must be bad...
      • Re:OpenSSH (Score:5, Interesting)

        by jimicus ( 737525 ) on Wednesday January 04, 2012 @07:29AM (#38583786)

        because any simple solution like OpenSSH must be bad

        The problem with OpenSSH - indeed the problem with most of these "simple" solutions is that they're only simple from the perspective of the IT department. They utterly fail the Marcus test.

        (Before you ask - "Marcus" is a hypothetical employee. He is a man of perfectly normal intelligence but relatively little in the way of computer skills. If you're expecting him to do anything clever with his computer such as connect to the corporate network remotely, you need the instructions to be as short as possible, as easy to follow as possible with the bare minimum of extra boxes to tick or dialogs to fill in. Anything that gets in the way of that is a Bad Thing. If your instructions for Marcus are 30 steps spread across 6 pages of closely-typed text with no illustrations, he's got precisely zero chance of following them.)

        • ...little in the way of computer skills.

          An employee needing corporate network access who has ``little in the way of computer skills'' shouldn't be accessing the network.

          If all they need is email, I'm sure a corp can provide a web-based ssl thing for that. If they need to read docs, I'm sure a web-based ssl doc thing (like an in-house version of google docs) would work. But to put a computer illiterate employee "on the network" from a remote location is just stupid (and yes, we've all been there; still doesn

          • An employee needing corporate network access who has ``little in the way of computer skills'' shouldn't be accessing the network.

            If all they need is email, I'm sure a corp can provide a web-based ssl thing for that. If they need to read docs, I'm sure a web-based ssl doc thing (like an in-house version of google docs) would work.

            How would they access those "web-based SSL things"? Are you proposing that they be hosted somewhere other than the corporate network? Regardless of where they're hosted, they'd need to be open to the world. VPNs are useful for adding an additional layer of security between sensitive services (including web-based email) and the world. Making the needed services public defeats the point.

    • This! I have used it on Android and it does work.

    • Re:OpenSSH (Score:5, Informative)

      by Karma's A Bitch ( 2482188 ) on Wednesday January 04, 2012 @04:14AM (#38583012)

      Hi, new poster here but have been lurking for about a decade -- but as fucked up as IPSec is, there are some important benefits:

      * IPSec tunnels your traffic over an unreliable datagram protocol (either IP protocol ESP or over some UDP port -- I forget the number). This avoids the performance problems of running a reliable protocol (TCP) over another reliable protocol (TCP). Some time since I looked at this, but IIRC, retransmits in the upper protocol kill you. Probably not too bit a problem if you aren't running significant traffic.

      * IPSec is processed in kernel mode which improves processing performance. This isn't as important on the client which is only handling one tunnel as it is on the gateway which is handling many connections and where the CPU load could be important. Disadvantage is that a bug in IPSec is a bug in kernelspace.

      * Of course anyone doing something like this should terminate the IPSec connection on a network outside their LAN and should also consider blocking comms between indials.

      Just wish whoever designed IPSec had done a proper job.

  • by daern ( 526012 ) on Wednesday January 04, 2012 @02:37AM (#38582606)

    "Proper" Cisco VPN support (i.e. with group usernames and passwords) was added in 4.0 (Ice-Cream Sandwich) and works very well indeed. Be aware that there appears to be a bug in 4.0.1 and 4.0.2 on the GSM Galaxy Nexus which cause it to reboot as soon as you pass data over a VPN, connected via 3G...wifi works fine.

    I'm running an AOSP (kang) 4.0.3 here and this has now been fixed. I believe the official 4.0.3 is just around the corner, so yey! This has been my top #1 feature request since Android day 1 and I bought the GN specifically because of it. Yey Glooge!

    Daern

    • by maccodemonkey ( 1438585 ) on Wednesday January 04, 2012 @02:46AM (#38582642)

      ""Proper" Cisco VPN support (i.e. with group usernames and passwords) was added in 4.0 (Ice-Cream Sandwich) and works very well indeed. Be aware that there appears to be a bug in 4.0.1 and 4.0.2 on the GSM Galaxy Nexus which cause it to reboot as soon as you pass data over a VPN, connected via 3G...wifi works fine."

      You say "works very well." I don't think it means what you think it means.

      • by Anonymous Coward

        I think they know exactly what it means ... the Galaxy Nexus is due to be updated to 4.0.3 in which ... it works very well. IN .01 and .02 it has a 3G but wifi works fine. So yes ... they knew what they were saying and said it. Friggin troll.

      • by daern ( 526012 ) on Wednesday January 04, 2012 @03:56AM (#38582926)

        ""Proper" Cisco VPN support (i.e. with group usernames and passwords) was added in 4.0 (Ice-Cream Sandwich) and works very well indeed. Be aware that there appears to be a bug in 4.0.1 and 4.0.2 on the GSM Galaxy Nexus which cause it to reboot as soon as you pass data over a VPN, connected via 3G...wifi works fine."

        You say "works very well." I don't think it means what you think it means.

        To clarify: It works very well indeed, but in 4.0.1 and 4.0.2 it only works with WiFi. Apparently, the 4.0.2 LTE version works fine on both WiFi and cellular connections.

        In 4.0.3 it works very well on both WiFi and 3G and is a monumentally excellent feature to be added :-)

        • It works very well indeed, but in 4.0.1 and 4.0.2 it only works with WiFi.

          If it was simply nonfunctional in 3G, you'd have some justification for this statement. Something that *crashes the whole phone* when you try to use it in 3G cannot, under any standards, be said to "work very well."

  • by Anonymous Coward

    I am doing IPSec on my stock ICS phone right now.

  • by ryanov ( 193048 ) on Wednesday January 04, 2012 @03:06AM (#38582714)

    My University doesn't support Android phones because there's no at-rest encryption (or at least they say there isn't -- I personally don't want one anyway and so haven't investigated).

    • Re:Not the problem (Score:4, Informative)

      by thegarbz ( 1787294 ) on Wednesday January 04, 2012 @03:45AM (#38582882)

      It's not standard as part of Android (or at least it wasn't in 2.0 - 2.3), there is however the option on the AOSP port of ICS (4.0.3) to do full device encryption, so that may be a standard feature now.

      That said there are many phones who have supported this for a long time, but the feature was added by the vendor and not a default function of Android itself.

    • by aarner ( 901356 )

      "Securing Android for the Enterprise" = "How may we break your device today?"

      So I bought a Droid-X about a year ago. Pretty happy with it. Then I hooked it up to Corporate Sync (exchange email server). A few PITA issues brought on by corporate security paranoia, but otherwise livable. (They forced a screen lock after 3 minutes with a minimum 6-digit PIN). Mildly irritating, but tolerable.

      Then some even more paranoid actor in our security theater / department found out that they could force full-device

  • There *is* a stock IPSec (Cisco) client for Android, though it lacks a lot of functionality. Ice Cream Sandwich release addresses those failings [phandroid.com]. As for connecting to a non-Cisco IPSec device, well, that's a different kettle of fish of another color, if you will.

  • The Android operating system doesn't just lack an integrated IPsec VPN client

    someone should actually do come fact checking before posting these stories.
    http://en.flossmanuals.net/basic-internet-security/ch050_vpn-on-android/ [flossmanuals.net]

    • by thsths ( 31372 )

      You seem to be under the mistaken impression that "Slashdot is news for geeks". A mistake that is easy to make, I admit.

      In my experience, Slashdot is more likely than not misinformation for the masses.

    • The Android operating system doesn't just lack an integrated IPsec VPN client

      someone should actually do come fact checking before posting these stories. http://en.flossmanuals.net/basic-internet-security/ch050_vpn-on-android/ [flossmanuals.net]

      But wouldn't fact checking drive away the shills and their sock puppets? Besides - despite all the evidence to the contrary - it must be true. Surely SoulFree wouldn't publish bullshit media releases [businesswire.com] disguised as "stories".

      After all the referenced author author has modestly announced his company are front-runners for the 2012 (my how time flies) Security Products Global Bullshit, sorry I mean, Excellence Award.

      Though I'm betting McAffee and Windows 95 might beat them (like a rented mule).

  • by Anonymous Coward

    We reviewed Android and iOS for a very large, very well known global company. After a lot of research Android was pretty much laughed out of the room. Any corporation that uses it for their issued device and has information to protect is not paying attention.

    1. Android has next to nothing in the way of large scale management and configuration tools.
    2. The OS itself is highly insecure allowing all sorts of application and OS interactions regardless of resource usage or malware possibilities.
    3. Google ro

  • a) Since when did "proper vpn" equal somethings that is "Cisco compatible"? I run IPsec/L2TP to my Juniper ScreenOS fw just fine b) I don't think L2TP over IPsec is particulary insecure. L2TP authentication/setup is also secured by IPsec transport mode. The article says that the authentication is not protected, which is wrong, since the authentication occurs first by IPsec Certificate or PSK and then by L2TP username/pw (which is protected by IPsec SA). http://en.wikipedia.org/wiki/Layer_2_Tunneling_Pro [wikipedia.org]
    • by Skapare ( 16644 )

      So how does IPsec in tunnel mode communicate the user credentials to the internal servers being accessed?

  • by rdebath ( 884132 ) on Wednesday January 04, 2012 @04:08AM (#38582982)

    IPSec was designed as an add-on for IPv6 back in the '90's and backported to IPv4. Unfortunately, it wasn't one of the well tested parts of the standard with many years of experience behind it, instead it was a recognition than encryption would become more important, and hopefully ubiquitous.

    But nothing has happened. Instead of becoming the normal way to encrypt data across the internet it's been sidelined to enterprise VPNs were it does quite well because of the very long protocol documentation it has. This is perfect for breaking the finger pointing crap that is so common in that environment. For general use encryption is still done at the application level.

    I think the worst problem is the usual suspect: key distribution. There is no reasonable way of ensuring that the right key data gets to the right clients. Though I had hopes for DNSSEC...

    But the problem here isn't that. The problem is the original expectation that ALL data would become encrypted. Because of this they inserted the encryption into the middle of the IP stack (a shim if you will) which sometimes converts TCP/IP packets into TCP/IPSec/IP packets without changing the IP addresses or routing or anything else. Because of this design decision the exact version/variant of the IPSec protocol HAS to exist in the kernel binary. You can't work around this.

    Every other VPN solution does it the right way. Actually creating a Virtual Private Network Adaptor for a Virtual Private Network Wire onto a Virtual Private Network. So you actually have a visible private network and you can see the routing and you can enforce firewall rules (or reverse path rules). What's more because of this every single one of them can easily be altered to work purely in userspace repurposing whatever virtual adaptor may be available on the platform be it PPP/SLIP/TAP or someone else's VPN adaptor. With this the horrific complexity that is IPSec can be avoided because you can run two versions of the VPN client on the same machine preserving compatibility by keeping old (put patched) versions of the software rather than creating a rats nest of compatibility hacks within the standard itself.

    The end result, IPSec is avoided unless somebody "requires" this enterprisey solution AND will be paying for it.

    • Some of the problems you're describing have to do with Transport Mode. Tunnel Mode encapsulates the whole IP packet, and creates an actual shared private network between your endpoint and the VPN server. If you enable UDP encapsulation it also traverses uncooperative NAT.

      Tunnel Mode can be done in userspace since it's able to spit out complete packets on a TUN interface. Basically it's everything you want, except overly complicated and hard to figure out in the way that any too-generalized system tends t

  • by gru3hunt3r ( 782984 ) on Wednesday January 04, 2012 @05:24AM (#38583234) Journal

    This article is out of date the following IPsec VPN options are available on a Google Nexus Galaxy from Verizon running Android ICS (4.0)

    IPsec XAUTH PSK
    IPsec XAUTH RSA
    IPSEC Hybrid RSA

    Android 4.0 supports standard IP sec gateways as well as Cisco's proprietary Xauth -- and unlike apple the android release does NOT require a company go out and buy a new Cisco Pix running IOS 7.0 or higher like the Apple iPhone 4 does (Iphone doesn't support xauth rsa profile).
    This little .. ahem, oversight on the iPhone made it so our company chose NOT to reimburse employees for iPhones since they can't be used for work -- so at least for our company if employees want reimbursement for phones, they need to purchase a device that's compatible.

    While I'm ranting-- I figured I'd also say that I wish either vendor apple/cisco natively supported OpenVPN so I could kill off my IPSec VPN I'd be thrilled, and the first vendor who does will receive the "recommended device" status for our employees.

    IPSec is my last choice, not my first - it's not well suited for modern day deployments anyway since it doesn't work through some NAT gateways (at many hotels), and it *never* works [by design] if two people on the same network are connecting to the same endpoint from behind the same nat firewall (ex: two employees at the same coffee shop both trying to do their work.. or a husband wife who both work for the same company trying to concurrently connect to their own home network)

    As NAT becomes more and more common (aren't we out of IPv4 addresses?) IPsec will cede way to more flexible solutions like OpenVPN.

    • VpnService is a base class for applications to extend and build their own VPN solutions. In general, it creates a virtual network interface, configures addresses and routing rules, and returns a file descriptor to the application. Each read from the descriptor retrieves an outgoing packet which was routed to the interface. Each write to the descriptor injects an incoming packet just like it was received from the interface. The interface is running on Internet Protocol (IP), so packets are always started wit

    • it *never* works [by design] if two people on the same network are connecting to the same endpoint from behind the same nat firewall

      That's true of Transport Mode, but Tunnel Mode (where entire IP packets are encapsulated instead of just the data) deals with that situation just fine. If you enable UDP encapsulation it also traverses uncooperative NAT.

    • There are basically two phones with ICS support (the Nexus and Nexus S) and combined they make up maybe 1 or 2% of all active Android phones (actually, I'm being generous here, the Android platform version graph shows 0.6%). So for all intents and purposes Android "still" doesn't have proper IPSec support. Or, put another way, more than 98% of Android phones don't have IPSec support. And it will take a good year or two before a simple majority of Android phones are running 4.0 or later.

      • by afidel ( 530433 )
        I think even two years is being generous, the plurality of devices being offered by carriers *today* are not slated to receive ICS which means for most users purchasing right now they won't get ICS+ until their contract expires in two years.
    • by jon3k ( 691256 )
      A "new" PIX? Cisco hasn't sold PIX for 4 years, it was replaced by the ASA line. And neither PIX or the ASA line have _ever_ run IOS.
  • by JAlexoi ( 1085785 ) on Wednesday January 04, 2012 @06:54AM (#38583598) Homepage
    Since the release of ICS, users are able to roll-out their custom VPN solutions. I bet OpenVPN is in the works.
    http://developer.android.com/reference/android/net/VpnService.html [android.com]
  • VPN Client API (Score:4, Informative)

    by robmv ( 855035 ) on Wednesday January 04, 2012 @07:14AM (#38583702)

    This is false, since Android 4.0 there is an API to add new VPN clients [android.com] without need to build kernel modules

    Enhancements for Enterprise

    VPN client API

    Developers can now build or extend their own VPN solutions on the platform using a new VPN API and underlying secure credential storage. With user permission, applications can configure addresses and routing rules, process outgoing and incoming packets, and establish secure tunnels to a remote server. Enterprises can also take advantage of a standard VPNclientbuilt into the platform that provides access to L2TP and IPSec protocols.

  • Out of date and biased. Would prefer more technical details as well - seems very generic in certain areas. Boo.

  • It's open source, can port forward, can use pubkey auth (shared key auth) and doesn't require you to "modify" kernels or root the device.

    http://code.google.com/p/connectbot/ [google.com]

  • In preliminary testing, we've been able to get some Android devices connected using Juniper VPN. It does appear there are some variations depending on device and version of Android that is running, but in most cases things do appear to work well. The only issue some of the power users have is that the Pulse client needs to have fairly significant access to the device to install correctly...

  • MS does get it and once they get WP7 fully working, it's going to be on most of the corporate phones as it'll include an Exchange Client, Remote Wipe, Can be locked down by an Active Directory Server tighter then a Black Berry. Simply put, Apple and Google don't get the corporate culture and that's what keeps MS alive.

  • /bounces with excitement
    ah, fuckit, never mind.

  • If you use SonicWALL firewalls then check out NetExtender which they call a "layer 3 VPN client". I use it all of the time to connect to my work desktop from home on my ASUS Transformer and it works perfectly. They also have a version specifically for their SonicWALL Aventail SRA E-Class SSL VPN Appliances.

If you have to ask how much it is, you can't afford it.

Working...