Updated Mac & Windows Client v.56 Released

Hey all!

We've just released updated versions of our Mac and Windows VPN applications, which you can find here:


SHA-256 Checksums:

installer_win.exe: 91eb5bd0381d48e8172d5fa48c7284b656c1953204f6c31ac51d2c45ae03cb30
installer_osx.dmg: 015d3e22d04e128cffcf62434c484719b16593bc29071fbb931c4dff5ccbfe62

Changes since v.55:
  • Allow localhost communication while connected to the VPN (apps that use this feature, such as iTunes, should now work) [Windows]
  • Allow communication with other hosts on the same network while connected to the VPN (e.g., connecting to your local printer should now work) [Mac]
  • Add "Small Packets" option to help connectivity on some networks (disabled by default)
We thank you for your continued support.

Sincerely,
PIA
    «13

    Comments

    • THANK YOU for fixing this from v.55!
    • The firewall is disabled for OS X (running 10.11.2) on this latest version along with the previous v.55, any ideas why this is happening and/or if this will get fixed?

      Steps to Reproduce:
      1) Turn on firewall in Settings
      2) Turn on PIA VPN Client
      3) Notice Firewall is now turned off
    • Add "Small Packets" option to help connectivity on some networks (disabled by default)

      Can someone explain how this works?  I would have thought smaller packets would increase latency, thus hinder throughput.

      Just curious.
    • Small packets, if I were to guess just tries to ensure that no protocol can manage to exceed 1500 for the MTU. If any packet on a normal system or device exceeds 1500 bytes size, it is broken at 1500 bytes and causes packet fragmentation to occur. This in turn can result in all manner of networking Hell.

      I would love to hear more details about this. If it works as I presume, what size does it use?
    • I can second that there is still an issue with the Firewall being disabled in OSX (10.10.5) when PIA is activated. This is a major issue that needs to be fixed.
    • Blocks outgoing connections to IP addresses assigned direct (non-VPN) connections in my routing table - e.g. my ISP's mail server.  OS X 10.11.2
      Gone back to V53
    • edited January 2016
      From Wikipedia...

      Large packets can be problematic in the presence of communications errors. Corruption of a single bit in a packet requires that the entire packet be retransmitted. At a given bit error rate, larger packets are more likely to be corrupt. Their greater payload makes retransmissions of larger packets take longer.

      Makes sense... what would cause an increase in bit error rate?

      Also interested in the packet size used when the small packet option is checked.
    • Just updated and I can now no longer use remote desktop to connect to the PC running the vpn.

      I am I missing a setting?
    • Same here with firewall being disabled, please fix ASAP!
    • PIA tech (Mike D.) reported that the disabling of the Mac OS X firewall by v.55 and v.56 of the PIA client is by design, indicating that the development team is aware of the affect that the client has on the OS firewall.

      Mike offered no defense of this configuration. However, he offered two alternatives: 1) use a different VPN client (e.g., Tunnelblick) or manually reenable the firewall after each OS boot.

      Mike reported that this configuration will be changed in future versions of the PIA client.
    • dsmurphy said:
      PIA tech (Mike D.) reported that the disabling of the Mac OS X firewall by v.55 and v.56 of the PIA client is by design...

      By design? Deliberately disable our OS firewall by design? What utter lunacy! Here all this time I thought it was just a bug. Now they're admitting to doing it on purpose? Wow!

      PIA, you're supposed to be a security company. How can you claim to have our security interests at heart while disabling our firewalls? This makes absolutely no sense.

      I mostly use Viscosity, so I don't have to worry about having my firewall being taken down without my knowledge or permission; but when I do use the PIA app I'm running v. 49. At least that version is reasonably stable and doesn't shut down your firewall. That's what I'd recommend to all OSX users do -- either don't use the PIA app at all, or if you do dial back to v. 49
    • edited January 2016
      I'm thinking PIA just needs to figure out how NOT to take down our firewalls (on the Mac) -- in the meantime, if you're on a Mac I've posted instructions on how to use an Automator Action to "shorten the process" to turning the firewall back on.

      Step 1.



      Y'all can figure out Automator, right? I'm just a dumb (old) farmboy & I figured it out.

      PIA Devs: Please don't turn off the firewall. How you got around 10.11 SIP (System Integrity Protection) is kind of spooky. Please don't do that.

      -Bad Uncle Leo

      PS. The pics are "Safe for Work"... Just click on 'em.


    • edited January 2016
      here's a video on how to use Automator





    • Installed v56 and I am confirming that issues with punkbuster and battlefield 4 are FIXED! Thank you PIA. And one note to developer Team:

      Like I said before, it will be a huge plus to VPN client itself if you will integrate a new option called "Gaming Mode" under "Small Packets" with instructions "Exclude origin, steam, uplay from VPN" something like here see the image :) Just a suggestion but I want this ( and many of gamers wants trust me )

      image
    • Yeah, anything to not block BF4/origin etc Worst xmas ever.
    • I updated from v53 to v56 and then I could not connect to the internet at all with pia running. If I disabled it I could connect. Installed back to v53 and I can connect again with pia enabled. Running Windows 7 Pro x64.
    • Hey all.

      I just wanted to clarify a few questions that i've seen some users asking here, about the new changes in v56.

      - The small packets option. What this does is changes the --mssfix directive in the .ovpn configuration to statically use 1250; this can help on some networks to improve stability, but isn't necessary in most situations. It was added as a way to improve overall functionality on some networks, where disconnections may be occurring intermitently; use of this feature may help to reduce or resolve that issue in some cases.

      - The firewall in Mac OS X. In order to guarantee security, we've had to change certain aspects of the code used to secure your service on MacOS. Part of these changes requires changing the state of the internal MacOS firewall during the app's operation. While the OS firewall is disabled, the connection's own security on the datastream immediately kicks in, and fully secures you while it's active. We're working to further expand upon these new changes, in order to eliminate their need to access/change the firewall's state; we hope to have a viable solution to avoid this short-term requirement, in a future build for our MacOS application. We apologize for the inconvenience in the interim, and appreciate your understanding and patience, while we continue work to keep your internet access completely secure and privatized at all times.

      Kindest regards,

    • edited January 2016

      Vulpes said:
      ..." We apologize for the inconvenience in the interim, and appreciate your understanding and patience, while we continue work to keep your internet access completely secure and privatized at all times."

      How about providing us with an "actually working" PIA software? ;-)
    • Vulpes said:
      Hey all.

      I just wanted to clarify a few questions that i've seen some users asking here, about the new changes in v56.

      - The small packets option. What this does is changes the --mssfix directive in the .ovpn configuration to statically use 1250; this can help on some networks to improve stability, but isn't necessary in most situations. It was added as a way to improve overall functionality on some networks, where disconnections may be occurring intermitently; use of this feature may help to reduce or resolve that issue in some cases.

      - The firewall in Mac OS X. In order to guarantee security, we've had to change certain aspects of the code used to secure your service on MacOS. Part of these changes requires changing the state of the internal MacOS firewall during the app's operation. While the OS firewall is disabled, the connection's own security on the datastream immediately kicks in, and fully secures you while it's active. We're working to further expand upon these new changes, in order to eliminate their need to access/change the firewall's state; we hope to have a viable solution to avoid this short-term requirement, in a future build for our MacOS application. We apologize for the inconvenience in the interim, and appreciate your understanding and patience, while we continue work to keep your internet access completely secure and privatized at all times.

      Kindest regards,

      Thank you for finally giving the answer to these questions, but next time it would be helpful to put notes like this in the release notes, and an answer to these questions sooner than later as support just gives a canned answer.
    • edited January 2016
      Vulpes said:
      Hey all.

      I just wanted to clarify a few questions that i've seen some users asking here, about the new changes in v56.

      - The small packets option. What this does is changes the --mssfix directive in the .ovpn configuration to statically use 1250; this can help on some networks to improve stability, but isn't necessary in most situations. It was added as a way to improve overall functionality on some networks, where disconnections may be occurring intermitently; use of this feature may help to reduce or resolve that issue in some cases.

      - The firewall in Mac OS X. In order to guarantee security, we've had to change certain aspects of the code used to secure your service on MacOS. Part of these changes requires changing the state of the internal MacOS firewall during the app's operation. While the OS firewall is disabled, the connection's own security on the datastream immediately kicks in, and fully secures you while it's active. We're working to further expand upon these new changes, in order to eliminate their need to access/change the firewall's state; we hope to have a viable solution to avoid this short-term requirement, in a future build for our MacOS application. We apologize for the inconvenience in the interim, and appreciate your understanding and patience, while we continue work to keep your internet access completely secure and privatized at all times.

      Kindest regards,

      John, thank you for the answer, but what others have said:

      - Please put big changes like this in the release notes so that users do not get "bitten"

      - You guys should NOT be changing the OS X App firewall state. Period. I now have iCloud bugs that I'm trying to chase down that did not exist in v.53 that exist now in .55-on. I don't see the point of "LAN Access & VPN? Shut off FW". Your App should not spawn bugs in other Apps -- shutting down a user's FW because "your pipe is secure" is a non-answer. I don't expect local LAN services to work when I'm on a secure pipe.

      - I don't trust the "our pipe is secure" bs. If PIA's pipe is so secure, why am I getting constant Cloudflare messages where I have to put in CAPCHAs at nearly every site I visit? "Contact the Admin"... well, that's you guys.

      Sorry for the tone of this post but again: If your solution involves REMOVING security like the Firewall (no other network App does this!! None!!) then you need to find another solution.

      - Bad Uncle Leo

      PS. Can your Devs actually *get* a Mac to develop on? Actually *build* an App that has an App ID? That doesn't put multiple versions of the App in /Applications *and* in ~/.pia_manager/ ?? Again, no other Apps or Devs do this. I love PIA. You guys need to improve.

      PPS. Yeah, I know, STFU Uncle Leo, just use Viscousity or TunnelBlick & VPN profiles.What about endusers? ¯\_(ツ)_/¯ 
    • Hi LeoofBorg,

      Where the Cloudflare issue is concerned this is due to certain PIA members using the VPN for spamming purposes causing CF to block these Ip's requiring the captcha phrases to ensure the user is not a robot.

      If you notice this happening then please contact our 24/7 live chat support so we can have the IP in question white-listed by CF to try to avoid this from continuing. 

      Cheers,
      PIA!
    • edited January 2016
      TinyTRex said:
      Hi LeoofBorg,

      Where the Cloudflare issue is concerned this is due to certain PIA members using the VPN for spamming purposes causing CF to block these Ip's requiring the captcha phrases to ensure the user is not a robot.

      If you notice this happening then please contact our 24/7 live chat support so we can have the IP in question white-listed by CF to try to avoid this from continuing. 

      Cheers,
      PIA!
      Thank you Jason... but can you guys send your current VPN addressblocks to Cloudflare?

      Basically every VPN node I use throws Cloudflare warnings or "breaks images or CSS" when they embed assets stored at CF.
    • edited January 2016
      Hi leoofborg,

      Thank you for the post!

      The issue isn't that we are not white listing the affected IP's, because we have been the issue is that they are continually being blocked even after being white listed, due to like I said earlier certain users and their activity while using our service.

      I assure you we are working on this issue and we are doing everything we can to try and have this issue rectified as quikcly as possible. 

      We appreciate your continued patience in this matter. 

      Sincerely,
      PIA
    • Would these additions if possible to be added

      1)  Create a small file that just contains the Port number when used on BitTorrent PIA capable VPN. This was promised by PIA Dev KYJelly in Sept 2014 https://www.privateinternetaccess.com/forum/discussion/comment/19922/#Comment_19922
      Read the thread to see the reason why, as it help automation in getting the posts update in Torrent and other apps.

      2)  If a user selects to NOT start the VPN when windows starts, then please do not add the launch to the Scheduler. I always start the VPN by clicking a shortcut on the desktop but PIA adds an entry into the Win Scheduler to run PIA at logon.

      3) The current action of launching the VPN starts Ruby in a Temp folder location. Could you an option to the settings to either launch Ruby the from a random temp folder or from the PIA_Manager folder in program files. Offering the fixed location will stop users having to modify the settings to allow Ruby though the firewall every it runs as the running from the temp folder requires setting a rule everytime.

      4) Show the Version number on the main settings page and also in the popup tooltip in the notification area on hover.

      5) Show in the settings page if an update is avaliable. It used to do  this but stopped seveal version ago, so now you will have thousdands of users with outdtaed and exposed VPN connections.

      These simple additions will greatly help users and also to devs.
    • Could I reinforce Peter Brown's remarks about version numbers and update notifications.

      4) VERSION NUMBER: The version number should be in at least these two important places:
      * In the metadata associated with the installer file, as is normal with almost all other .exe installer files.
      * At the top of the PIA settings page, in the same font.  It should show when in Simple Mode, not just in Advanced Mode, so that the top line would read:
      <icon> privateinternetaccess v. 56
      The Peter Brown's tooltop suggestion would also be very helpful, or it could be on the right-click menu.

      I spent 15 minutes looking for the version number the first time I needed it, and I eventually had to search the forum to get the clue about changing to Advanced Mode.

      There is the further problem that the present font, besides being tiny, hardly distinguishes between 5 and 6. Yesterday, after returning from holidays, I checked my version number, and couldn't tell when it was:
      v. 55 or v. 56 or v. 65 or v. 66. 
      I installed the new update v. 56, and could only barely discern that the two tiny digits were now different.

      5) UPDATES: Further to Peter Brown's request for update notification, I would also like a PIA webpage that straightforwardly lists the recent updates.  That page should give:
      * Versions numbers, in a black title font
      * The date each update was issued, in a black title font.
      * A short dotpoint summary of the main changes, perhaps with a link to a more detailed account of those changes.
      * A downloads button for the latest version.
      * A link to some recent earlier versions in case a bug or incompatibility emerges.
      It continues to amaze me how few software houses can put themselves in their users' shoes and write such a page.  RoboForm is almost there, apart from access to older versions:
      http://www.roboform.com/news-windows

      Also, we have already bought the product and appreciate it, so we don't need to be exposed to PIA advertising everywhere we go on the website.
    • Hi Guys !

      I love all the suggestions from everyone on how to make things better!

      I have collected up all of the suggestions given to us on how to make the product better, and I have compiled them into our wishlist for the devs to look at and see what can be implemented or improved upon!

      If you have any more suggestions feel free to pass them my way and I'd be more the pleased to ensure they are looked at!

      Hope everyone's doing well! Thank you all again for your continued support and dedication to PIA!

      Cheers !
    • edited January 2016
      PIA support,

      Can you please do something about marking and announcing new releases.  I had no idea client v.56 for windows existed.  I was suffering with major connectivity issues with v.53 since November/December (can't recall it's exact release date)

      Suffice it to say, If I had not done the "live help" with Steve in your CS department, I would have never known.  Thank you Steve for fixing my headaches with a simple recognition I wasn't using the newest client!!  Not everyone who uses your service logs in here to check.   Heck, I didn't until just minutes ago.

      Thanks!
    • Umm, do what? You know you are posting in a STICKIED THREAD on PIA's public forum where they formally announced the release of v.56 on January 6th, right? I don't see how they could have done a better job. You know people can pay for PIA in bitcoins, essentially anonymously and obtain a username to user on the site? PIA can't just contact all of their users by e-mail and say "yo, we have a new client". I think it's much more reasonable for them to expect you to check the forum once per week/month than it is for you to expect them to go out of their way to notify the user base in another fashion. But, alas, that is just my opinion.
    • They can do a better job of announcing it on the front page, and marking the download clients better, as many people above me have also pointed out.  There is no mention that I can see anywhere on the main website of the client version number, and a changelog; only here. So no, forums are not the best place.   Supplemental, sure, but a revision history page with links to current clients is not too much to ask.
    • We appreciate your concerns, joe_user2016, the version numbers for our application are listed on the Client Support page, right under the download for the specific operating systems. This page can be found at https://www.privateinternetaccess.com/pages/client-support/

      As for the change logs, if you weren't already aware, they are all available on our forums at https://www.privateinternetaccess.com/forum/categories/change-logs-etc . I understand what you mean about the visibility, and I will pass your concerns along to our Developer Team.

      Cheers!
    Sign In or Register to comment.