Suggestions & Concerns

edited April 2014 in Feedback
I'm putting this in feedback because it seems to fit best here.  First of all, great service, great price.  I love the security it provides at a lower cost than your competition.  I don't personally use it to torrent but from what I've seen, I could and that is great.

I primarily use your service as part of my Android devices, to secure traffic while at an open access point or an access point that I don't trust, even if it has WPA.  I do this at work, coffee shops, McDonald's, hotels, etc..  I would love the ability to configure rules, right now it is all or nothing.  I use my LAN at home to do work between computers, my Roku at my TV, and some file sharing within my LAN.  If I've got the VPN running, I can't do these things.  So at home, I don't want the VPN running.  I was using Avast! SecureLine which had the really awesome feature of letting me define rules, if I connected to any insecure network it would automatically start the VPN and when I went back to the cellular network or to a secured network it would stop the VPN.  I could also setup rules to automatically start the VPN if I connect to say, my neighbors network.  The easiest (for you) way to do something similar is allow Tasker to control your app.   There is an OpenVPN app that does this, basically I'd like to setup Tasker so that it can enable my VPN automatically and disable it again when I get home.

My second concern is you've got some issues with crashes.  About half the time when I tap on the key icon in the notification pulldown and tap "Disconnect" on the pop-up with my network stats on it, your app force closes.  It isn't huge because it still works, but it does make me tap the "I Trust this app" next time I want to turn on the VPN.

As a continued suggestion, I will soon have my laptop back from a friend and I'll be using your service on it as well.  I would like similar ability to automate the VPN connection and disconnection on my Windows machine as well.  I think this feature would bring you more users because the one HUGE problem with security of this type is the user has to keep it up.  This is a similar effect to backup.  Everyone knows they should backup but no one does until someone makes it automated.  No one would question the need to encrypt traffic, but no one does because there is little or no automation.  If you would fix the automation issues I would be able to get you at least 4 more regular subscribers who aren't technically savvy enough to want to deal with VPN manually, but who would do it if it were automated.

Comments

  • When using the VPN, you should always be able to access local network resources.
    Could you check the device's routing table when you're on your LAN and connected to the VPN?

    PIA Manager, and probably also the smartphone app, should have a setting to connect automatically. Paired with the ability to access local resources regardless of VPN connection, it is the most basic and simplest form of automation.

    I do understand that configurability is a huge factor for power users, but for those users it also has to be working right. I myself don't want to live with the restrictions PIA Manager would set for me, so I use my own set of scripts to manage the VPN connections. PIA could probably include the features I use within their software, but there are already very good alternatives out there, and while competition is usually a good thing, it would take a lot of resources to actually make a difference, and I'd rather have them spend those resources elsewhere, like publishing the information needed to change default encryption settings with plain OpenVPN.

  • But I am unable to access local resources unless I expose them to the outside Internet.  That is the nature of being on a VPN, now I will say I'm not using a desktop to do this, I am using my Android devices.  All traffic outbound it encapsulated, encrypted, and send to the VPN gateway to be then carried out over the Internet from the end-point.  I am not sure how one would customize the routing table on the Android device or automate its use either.  If you know, that would be nice but as far as I know it may even require root which I don't have on both of my devices (one is rooted, the other has no rooting solution).

    Unless routing is specifically configured so that local traffic (in my subnet) is routed to the unencrypted interface (and from the unencrypted interface) then the device cannot discover or connect to local resources.  This also presents its own security risk as the LAN can be its own vector.

    As far as the usefulness and control of the automated connection process.  I agree, there is something to be said for every connection always encrypted but this may not be desirable for everyone.  Specifically low-tech users who are concerned mostly about open access points.  More control over the automation would be handy for a good many people.  Are you representing this company when you talk about the reasons why this isn't a good idea?  Giving people more options by adding support for the existing Tasker infrastructure (without the need to provide the automation themselves) does nothing but enrich the product.  Suggesting that if I don't like how it works I should use another solution hardly seems fair to the company or its profit margin.

    It sounds like you're a user with your own agenda for what you think they should be working on.  In that case, not to be rude, but responding to feedback to the company as  a third party with why you don't think that's what they should work on seems a bit off to me.
  • @VPN is a user here, just like you and I are.

    PIA has a few people that occasionally get involved in discussions here, but they would not mislead you like that.

    I could list the people who work for PIA here, but the way the forums work, they would get annoying messages telling them they were mentioned in a thread. So unless you really want that, I will abstain from listing them.

    As for the topic, I cannot really offer any help. I own only one PC, and have no mobile devices whatsoever, nor any 'droid devices either. But I am interested. Technically adept people are most welcomed here. Welcome to the forums! ;)
  • I did a little research and found that having the local network visible while connected to the VPN is uncommon. One OpenVPN app does it. No others do, I must assume that it is not as easy as it is on other platforms.

    I know Android has limitations on the routing commands and such, and the VPN API is limited in ways too. For now, the service does what I need if a little cumbersome.
  • Umm.

    OpenVPN itself does not modify local routes at all. And why should it? Local routes do not affect internet routing in any way, because all sensible providers drop packets from RFC1918 networks.

    I have no idea why mobile devices would or should not have access to a local network while having a VPN connection. If this is enforced by PIA's app, I'd view it as a bug, or at least a very misguided feature, and demand that it'd be changed.
    If it's a limitation of the OS, it might be best to use the OS' integrated VPN options and/or file a bug report.

    As far as automation goes, If mobile devices need something special, I really have no experience with it. Perhaps something better is available than I can imagine, and maybe it's as easy as a weekend of inserting API calls into the app's sourcecode. I guess I'm not really fit to comment on this specific issue.

    I'd still rather have them put their resources into stuff that benefits me instead of you. I think I could make an objective argument for information disclosure over feature programming, but let's just say I'm selfish. That will probably result in less arguing.

    I feel that posting in a public forum automatically invites third parties to comment.
  • First off, you're right.  Posting on a public forum does invite commenting.  And I can completely understand the selfish desire to have them work on what you want.  That's not a big deal.  As far as information disclosure vs feature programming, what exactly do you want them to disclose?  What have they kept hidden from you?  Well, perhaps - don't answer that, it gets away from the point of this post.

    Mobile devices are unique in many ways, the google API call isn't exactly like specifying a route via the route or netstat commands the way one would on a full Linux distribution.  I'm not sure why, but it is the way it is.  Something to do with not requiring root privileges which is needed to access the routing table directly.  The API call allows Android to maintain security over the device's routing table.  Exposing the routing table to every app in full is a dangerous proposition to security.  With it DNS calls, or any other calls can be routed anywhere.

    You clearly have no idea what you are talking about with networking.  But that isn't a surprise.  Networking is complicated and dealing with VPN's is a lot more so.  The local routing table is the routing table on your device that tells the device what gateway to send a packet to, if your device is going to send it locally (to your LAN) or if it is going to forward it through your router, or which router to send a packet to.  Local routing tables do not only impact the LAN, as you seem to think they do, they impact how the local device interacts with the network.  This is differentiated from the Router's routing table, or another device on the networks routing table.

    In this case, on my Mac or a Windows machine, the routing table normally has a link of what routers IP addresses should be used as gateways to the rest of the network.  For 99.9% of people in the world they have one router for their home LAN.  In a larger networking environment you may have multiple routers on your LAN that bridge subnets together.

    So, your router table lets your device do the following:
    App 1 says, please send a packet to 10.1.9.4.
    The device then says, ok, let me look how to get it there - I have 3 routers, 1 goes to 10.1.1.0 network and another goes to 10.1.8.0 network and another goes to network 10.1.9.0.  I'm going to send the packet over the link that goes to 10.1.9.0 (router is usually 10.1.9.1).
    This is done because the router table says any packet going to 10.1.9.0 with hostmask 255.255.255.0 (basically IP range 10.1.9.0-255 - including broadcast (.255) and network (.0) addresses which generally aren't used by most applications).

    In the case of a VPN, the computers local routing table is modified so that rather than sending traffic to your default Internet gateway at your local network (say 10.0.0.1) a tunnel is setup in software which responds to an IP address on a virtual network of say 5.1.2.1.  The computer is multi-homed and exists on both the virtual network and on the home network.  Then the computer can choose that packets originating locally (at the computer) can be routed to 5.1.2.1 if they aren't intended for the LAN.

    In this case you'd your routing table as follows...
    10.0.0.0/255.255.255.0 routes to 10.0.0.1 (router)
    0.0.0.0/0.0.0.0 routers to 5.1.2.1 (virtual network gateway)

    This isn't exact like it would be for a route or netstat command.  But the rules are evaluated in order, so matching the first rule goes to the LAN, everything else goes to the VPN.

    In the case of Android, the first line isn't there.  Thus all traffic goes into the VPN.  This has advantages and disadvantages.  10.0.0.0/255.255.255.0 requries to be routed locally by the router, but can't get there because the computer's local routing table automatically diverts all traffic.

    Of course an actual full routing table is more complicated and includes routers to and from the local device, as well as routings too and from the LAN and the Tunnel, etc.
  • As for what @VPN wants, he wants PIA to step up and tell us how to use the service as it is meant to be used. PIA had AES in their own client before OpenVPN had it. Now OpenVPN has it and they are implementing it in a way that is not supporting OpenVPN Clients. (PIA servers work for AES from the PIA client, but not from OpenVPN.)

    @VPN has been asking questions for years now. And with all due respect to you, he *DOES* know quite a bit about networking. Local does not mean the same thing to everyone. I remember arguing about locahost being a variable with any possible address. People argued it could only ever be 192.168.0.0 or 127.0.0.0 or some other nonsense that may as well be arbitrary.

    In the end, everyone who thought it was a static address was proven wrong. And while local routing is a whole different subject, remember that we are all running different systems. @VPN runs Linux only as far as I know, and sometimes is a bit puzzled by the questions of users of other OSes. (As I am myself.)

    Android is not the droid you were looking for...

    No. Pardon the Star-Wars pun. Android is not really the same as Linux in many ways. I cannot specify the ways, but Google has never been truly forthcoming about the OS.
  • Then let me apologize.  I didn't mean to come off as smug and condescending as that certainly was, @VPN, I apologize I didn't mean to be that way.  I would like to hear more about what you'd like them to tell you and why - but obviously not here.  If this supports private messages, please send me one as I would be interested in hearing about what your concerns are and why.

    As far as Android and such...  Yes, I think perhaps I'm expecting too much.  Though I know one of the OpenVPN apps in the Play Store will exclude the local network automatically from the routes it is certainly not standard.  I haven't tested the Windows side yet to see if I can access my LAN while the VPN is running but I will as soon as I get home though I suspect that I will be able to.

    I think the Android issue is a security measure on the part of the VPN API.  Since only one out of the 8 different Android apps I tested allow access to the LAN while connected to the VPN it seems to me that this is likely by design or that not enough people have a need for it.  I would still like automation, and it should be a fairly short bit of code to add Tasker support since all it really needs it a "Connect" and "Disconnect" option, nothing complicated.

    Is what you said about AES why when I tried to use the OpenVPN apps to specify to use AES it wouldn't work?
  • VPNVPN
    edited April 2014
    So, thanks Omni for defending me while I was watching Anime :)

    No worries. I've stopped being angry at people misunderstanding me on the internet a long time ago.

    About a year ago, PIA introduced an update to their desktop software client (across all supported OSs) which allowed to define the used encryption, authentication and verification methods that the VPN connection uses, i.e. encryption cipher and strength (I believe choices are None, Blowfish, AES128 or AES256), Authentication via RSA with different key sizes (don't know if any others are supported), and different HMACs (probably None,MD5,SHA*).
    Since the software internally uses OpenVPN for the connection itself, it should have been possible to use these settings with OpenVPN configuration files also.
    But it isn't, as you've noticed too, and users fail to understand why this is the case, because no information was offered even after asking explicitly.

    We have had, during the last 12 months or so, at least 5 threads on the forums about when and/or if the needed configuration settings will be provided by PIA. Especially the option to disable encryption could help router users to gain more speed with their limiting devices, or advanced users like me who'd like to be able to use the best crypto settings available while stil having full config access and scripting flexibility by using OpenVPN over the client software (not to mention that it's useless on headless machines).

    So, to conclude, apparently Android does things differently and routing is more limited, which makes it an important point to have more options regarding automated connecting and disconnecting. We learned that PIA doesn't always keep up with user's needs and that @VPN watches Anime.

    By the way, since you talked about the routing stuff so extensively, if you'd like I could show you the routing tables for my LAN router, which handles my ISP uplink and 3 concurrent VPN connections to different gateways, accessible via individual VLANs. I want to allow IP clients on my network to switch the used VPN tunnel (and country exit point) from a website, but haven't gotten around to it yet. But the routing works, so let me know if you'd like to see.
  • edited April 2014
    Then let me apologize.  I didn't mean to come off as smug and condescending as that certainly was, @VPN, I apologize I didn't mean to be that way.  I would like to hear more about what you'd like them to tell you and why - but obviously not here.  If this supports private messages, please send me one as I would be interested in hearing about what your concerns are and why.

    As far as Android and such...  Yes, I think perhaps I'm expecting too much.  Though I know one of the OpenVPN apps in the Play Store will exclude the local network automatically from the routes it is certainly not standard.  I haven't tested the Windows side yet to see if I can access my LAN while the VPN is running but I will as soon as I get home though I suspect that I will be able to.

    I think the Android issue is a security measure on the part of the VPN API.  Since only one out of the 8 different Android apps I tested allow access to the LAN while connected to the VPN it seems to me that this is likely by design or that not enough people have a need for it.  I would still like automation, and it should be a fairly short bit of code to add Tasker support since all it really needs it a "Connect" and "Disconnect" option, nothing complicated.

    Is what you said about AES why when I tried to use the OpenVPN apps to specify to use AES it wouldn't work?
    You do not owe us an apology, and I will accept it anyway and offer my own. I do not intend to be a jerk, but my nature requires it of me. (Not really, but I get away with more this way.)

    Yes, the AES stuff is undoubtedly the reason that it will not work. A while ago there was a few threads that discussed the issue, and we had hopes that it would be fixed soon after OpenVPN added the support for AES natively, but the threads died when a malicious user made an army of clone accounts and voted down every thread I or @VPN ever made a post in.

    I lost 1200 posts in one night. @VPN fared about the same if my memory is correct. And there were many other victims and many good threads lost as well. Thread voting was disabled, and the trolling has stopped. But the threads where this was discussed are gone for good now.

    But the last thing I recall was someone from PIA saying this was a thing they intended to fix. I could be remembering it wrong, but that is what I remember.

    *Edit* Ninja'ed by @VPN due to my slow key-pecking...
  • I wonder...  I was a programmer once, in a past life so to speak, and you said they had AES first.  I wonder if they've got some back end stuff that isn't OpenVPN compliant that they need and have a situation where they are programmed into a corner and have an update that seems simple to us - but isn't because of the infrastructure that needs to be updated.

    I know security companies spend a lot of time working out how to implement AES and other crypto schemes as to not introduce any holes.  It makes me wonder, if they found bugs and kinks and it is just taking longer to track them all down.  I don't know...  I just can remember many times when dealing with server/client stuff of programming myself into a hole where the standard changed or a standard was codified different from what I had done and it was like - SHIT - I have to reprogram every single tool I have and then I have to make sure they all work together.

    I'm not making excuses, just saying.
  • I wonder...  I was a programmer once, in a past life so to speak, and you said they had AES first.  I wonder if they've got some back end stuff that isn't OpenVPN compliant that they need and have a situation where they are programmed into a corner and have an update that seems simple to us - but isn't because of the infrastructure that needs to be updated.

    I know security companies spend a lot of time working out how to implement AES and other crypto schemes as to not introduce any holes.  It makes me wonder, if they found bugs and kinks and it is just taking longer to track them all down.  I don't know...  I just can remember many times when dealing with server/client stuff of programming myself into a hole where the standard changed or a standard was codified different from what I had done and it was like - SHIT - I have to reprogram every single tool I have and then I have to make sure they all work together.

    I'm not making excuses, just saying.
    That is pretty much what I suspect as well. Some seemingly trivial difference makes it all have to either be remade from scratch or replaced with vanilla OpenVPN on the server side. Just updating a thousand servers must be a brutal amount of work.

    I think the fact that the PIA client expects things to work one way that OpenVPN cannot accept or workaround is the problem. The servers are trivial compared to tens or hundreds of thousands of users running a hundred different versions of the custom PIA application.

    The client cannot force a user to update, and that may one day be required.
  • I guess Omni and me have had this disagreement for a while, though not aggressively of course. And that's not even a problem, because we're both just speculating ;)

    I don't think PIA has patched OpenVPN substantially. As far as I know, all the settings that PIA Manager offers for crypto are possible with OpenVPN itself, it's just that the servers don't accept them if we set them in the config files. You can see that other VPN companies offer the same settings, but natively for OpenVPN, not any client software.

    Even if they did modified OpenVPN in a way that's needed for these settings to work, I feel that they should still publish this information, so that all customers can make use of it. As it is now, OpenVPN users (everyone with VPN on a router) can't access crypto settings that PIA uses to advertise their service with. They don't explain this restriction when signing up. Some countries in the world might see this a fraudulent advertising.
Sign In or Register to comment.