Make udp/tcp and port more automatic

It is a nice feature in the desktop client to choose between udp/tcp and the ports. I find that differing public wifi needs different selections.

I propose an automatic determination of successful settings by trying all of the common settings and pick the first one that establishes a connection. Saving the result to a file based on SSID would speed up further connections.

Right now I am starting a list of wifi locations and what settings a need. A feature like this would make the client more useable.

Comments

  • Hello!

    This is actually something the app already does by polling servers for latencies; it does so over the different remote ports available. If it's not doing so for you, please email [email protected] to get a ticket started so we can investigate and thank you for being our customer!
  • I see the latency report has the ports and such. However, it doesn't seem to be detecting whether a connection can actually be made. For example, for some reason by home network doesn't work with udp, but it's trying a udp of 8080, and it won't connect.

    I was also at a fast food place and tried tcp auto and it wouldn't connect. Forcing to tcp/110 worked.

    I'll send an email and hopefully this can be figured out. I'm wondering if firewalls with deep packet inspection are causing issues. Simple connections for latency work, but it fails for the actual VPN.
  • edited August 2015
    From Support:

    Also, to clarify, "Connect Auto" does not auto select working ports on a given network. All "Connect Auto" does is choose the server locale with the lowest latency reading at that time. The connection port choice remains a manual process. Sorry for the confusion.


    Can you add a feature request for auto selection of udp/tcp and remote port? That would be very useful.

  • edited August 2015
    It may be a nice feature to have, but public networks are getting smarter. The better setup ones will work with just about anything at first, and that would screw up any "automation" of the TCP/UDP and port numbers.

    I have no wireless devices at all, but I would think the very first thing you should try is UDP with port 1194 and if that fails try TCP 443. If both fail then it is a crap shoot. Asking the network administrator may help, but may public networks do not have a public administrator to talk to.

    *Edit* Spelling corrected.
  • I'm not sure how the public wifi setup would defeat automation of finding a working configuration.

    There is a finite set of configurations in the current application. I'm proposing to try each one until a connection is made. If there were hundreds of configurations I'd see how that wouldn't be feasible.
  • How the public networks would be able to defeat automation is simple. Let me offer an example.

    1. You go to a place with public Internet access. You are connected at once.
    2. You attempt to connect to PIA. It for example tries TCP 8080.
    3. The network knows this is a port commonly used for proxies and VPNs, so it allows it initially.
    4. After enough time has been allowed to pass, the public network decided to forbid that connection and any from your MAC address that would use TCP 8080.
    5. Your system knows this was working, so it does not understand why it is not working now, and as such cannot correct it.
    6. You disconnect from PIA and try another connection with a different protocol and port. Say UDP on port 1194.
    7. The public network already has your MAC address recorded and will do exactly the same for any protocol and port you use. It is a cold hearted bitch of a network, but this is a measure to prevent abuse, so it does not care that you were locked out.

    You may ask why the network would do that? The answer is simple. The price of "Free" is often much higher than it would be if you paid for it. Public networks usually collect information for sale. (Not all, but many do.)

    And as more and more places adopt such Draconian policies, the value of Public Networks will become nothing at all unless you simply do not care that they are selling you out behind your back.
  • Point taken, although you are addressing the usefulness of PIA on a public network, not the automation proposal. Your argument holds regardless of whether PIA is finding the configuration or the user is making the configuration manually.

    This feature request is not limited to being useful on public networks. I may be using the word "public" loosely. I am considering any network that doesn't require authentication of some sort. For example, I am in a hospital right now on their "public" wifi, which probably is better categorized as "open". It is for the purpose of patients and guests, so the network really is paid for. Some companies offer wifi for employees'  own devices that is separate from the corporate wifi, so it's paid for.
  • Bear in mind that my argument is theoretical. It may not apply on any network you ever use, or it may in time become the rule rather than the exception.

    Even if your employer provides the network, they may object to the use of a VPN, and the protocol and port are certainly not the only ways to determine if you are using a VPN.

    No employer keeps employees that do not in turn earn the company money. And information is money and power. Just something to keep in mind.

    The longer you remain connected, the more obvious it becomes regardless of settings that you are using a VPN.
Sign In or Register to comment.