<li><ahref="#the-vpn-fails-with-auth-failed-or-immediately-disconnects-with-encryption-failed">The VPN fails with “Auth failed” or immediately disconnects with “Encryption failed”</a></li>
<li><ahref="#my-provider-returns-auth-failed-but-my-credentials-are-correct">My provider returns “Auth failed” but my credentials are correct</a></li>
<h3id="i-disabled-icloud-and-my-profiles-disappeared">I disabled iCloud and my profiles disappeared</h3>
<p>Starting from version 2.0.0, Passepartout relies on iCloud capability for profiles storage. Disabling iCloud toggle in iOS settings may result in a “No profiles” message, because the app would be unable to access the CloudKit store, even if it’s only local. This will be fixed soon by making iCloud support optional, as it may be a privacy concern for some users.</p>
<h3id="im-unable-to-add-my-wi-fi-to-trusted-networks">I’m unable to add my Wi-Fi to trusted networks</h3>
<h4id="190-ios">1.9.0 [iOS]</h4>
<p>If you see the “You are not connected to any Wi-Fi network.” message, it’s coming from a <ahref="https://forums.developer.apple.com/thread/123544">known iOS 13 bug</a>.</p>
<p>Until Apple fixes it, you may want to try these workarounds:</p>
<ul>
<li>Reboot the device</li>
<li>Reinstall the app from scratch</li>
</ul>
<p>Unfortunately neither is guaranteed to work. While extremely sorry for the inconvenience, I can’t do more than this about this iOS bug.</p>
<p>Anyway, you can follow <ahref="https://www.reddit.com/r/passepartout/comments/dt0fxy/read_this_if_you_cannot_add_your_wifi_to_trusted/">this Reddit discussion</a> for updates.</p>
<h4id="181-and-before-ios">1.8.1 and before [iOS]</h4>
<p>The effect of the new location access requirement in iOS 13 is the inability to trust the connected Wi-Fi network. The app will either trust a bogus “Wi-Fi” or “WLAN” SSID name, or present the alert “You are not connected to any Wi-Fi network.”.</p>
<p>To work around this issue:</p>
<ul>
<li>Trust the network while the VPN is enabled and connected through such network.</li>
<li>Upgrade Passepartout to the latest version (much, much better option).</li>
<h3id="i-had-purchased-this-app-before-yet-it-prompts-me-for-purchases">I had purchased this app before yet it prompts me for purchases</h3>
<p>Since iOS version 1.9.0, Passepartout switched to a freemium model, which means free to download with paid in-app purchases. Of course, those who purchased former versions of the app will retain full access to all features and providers. Most of the time the upgrade will be seamless. In some cases, however, it will take those users an extra step to restore app functionalities.</p>
<p>Any of the hints below will fix the issue 100% of the times:</p>
<ul>
<li>Kill and relaunch the app. This is preferred when you re-download the app from scratch.</li>
<li>When prompted for purchase, tap “Restore purchases”. You will only be asked for your Apple ID credentials, no money involved.</li>
</ul>
<p>If you still struggle, don’t hesitate to get in touch.</p>
<p>You should contact with your provider to double check if there is interest in being added to Passepartout. Beware that some may be concerned instead. Ultimately, you can submit your provider request for a viability review to <ahref="mailto:providers@passepartoutvpn.app">providers@passepartoutvpn.app</a>.</p>
<h3id="im-on-wi-fi-but-my-device-shows-im-connected-via-lte">I’m on Wi-Fi but my device shows I’m connected via LTE</h3>
<p>The Wi-Fi/LTE icon (replace LTE with any cellular signal) while on VPN has been broken since iOS 10 or the like. It’s something that Apple is unable to fix or doesn’t bother fixing.</p>
<p>You should do a simple test. Verify your data consumption with your LTE provider website, normally phone providers have that. Now, when on VPN and the LTE icon appears in spite of Wi-Fi, download a relevant chunk of data. You may then learn that the plan is unaffected, implying that you’re actually connected via Wi-Fi.</p>
<p>I haven’t found a workaround for this and it’s been there for almost two years. Yeah, it’s a shame.</p>
<p>Starting from iOS 12 (or 13?), iOS has restricted what apps can learn about Wi-Fi networks. Location access has become a requirement to access the SSID of the connected Wi-Fi, which is crucial to add it to trusted networks.</p>
<p>That’s why, starting from iOS app 1.9.0, Passepartout will prompt you for a location permission when trusting a Wi-Fi network. Make sure that location services (under “Privacy”) are enabled on your device, otherwise the app will be unable to ask the permission in the first place.</p>
<p>Historically, Passepartout has used a low MTU setting (1250 bytes) in order to maximize compatibility, at the cost of performance. iOS version 1.13.0 -and any macOS version- supports tunnel MTU customization. With this update, it sounded reasonable to also leverage a standard (higher) MTU (usually 1500).</p>
<p>If such change is making the app struggle in your environment, I encourage you to try lowering the MTU. You can easily do that by setting MTU to “Manual” in “Network settings”. You will then be able to pick something down to 1200 bytes. Decrease incrementally until you restore VPN operation.</p>
<h4id="compression">Compression</h4>
<p>Most of the time there could be a mismatch in compression framing. E.g. server is using LZO compression framing whereas the client is not, or vice versa. Sometimes the app gracefully shuts down with “Compression unsupported”, sometimes the error can be subtle and packet transmission could just fail silently, resulting in no data exchanged over the wire.</p>
<p>Therefore, make sure that compression directives are compatible between client and server before looking into routing issues. Also read the next FAQ entry, as it may be another cause of a dead data link.</p>
<p>Last but not least: make sure that you’re not experiencing a simple DNS issue. Try pinging a remote machine by IP address: if that works, then DNS is the culprit. This usually happens when your server, whatever the reason, doesn’t push public DNS servers to clients. There’s a quick workaround: enter “Network settings” in Passepartout, set “DNS” to “Manual” and add an explicit DNS server address. That should fix it.</p>
<h3id="the-vpn-fails-with-auth-failed-or-immediately-disconnects-with-encryption-failed">The VPN fails with “Auth failed” or immediately disconnects with “Encryption failed”</h3>
<p>This may happen when you rely on default OpenVPN encryption, which is normally Blowfish (BF-CBC). The algorithm, besides being unsupported by Passepartout, is also weak and therefore discouraged. In order to fix this issue, you must switch to AES encryption. Passepartout only supports AES, be it in CBC or GCM mode.</p>
<p>Set encryption explicitly in the server configuration, e.g.:</p>
<p>and the client wouldn’t need to change a thing, because the algorithm will be enforced by the server no matter what.</p>
<h3id="my-provider-returns-auth-failed-but-my-credentials-are-correct">My provider returns “Auth failed” but my credentials are correct</h3>
<p>Bear in mind that some providers require specific credentials for their direct OpenVPN servers. That’s why Passepartout, in those cases, has a convenient link in the bottom of the Account screen showing you where to find such credentials on your provider’s website.</p>
<h3id="my-personal-server-returns-tls-failed">My personal server returns “TLS failed”</h3>
<p>At some point, TunnelKit moved from OpenSSL to BoringSSL. The switch may disrupt older ciphersuites, thus resulting in “TLS failed” when verifying peer against the CA. Regardless of the error, you should upgrade your server certificates to a more modern standard (e.g. RSA no less than 2048-bit). Passepartout should also get past the “TLS failed” error once you perform the upgrade.</p>
<p>When missing, OpenVPN implies a Blowfish cipher, which is severely obsolete and unsupported. Passepartout requires that you set an AES cipher instead. For that to work, you must update your OpenVPN server and client configuration to use AES by explicitly setting a cipher (e.g. <codeclass="language-plaintext highlighter-rouge">cipher AES-128-CBC</code>).</p>
<p>Recent servers might still be pushing a modern cipher option (normally AES-GCM), but Passepartout enforces an explicit client <codeclass="language-plaintext highlighter-rouge">cipher</code> to avoid <ahref="#the-vpn-fails-with-auth-failed-or-immediately-disconnects-with-encryption-failed">another subtle issue</a>.</p>
<p>Due to easier interoperability, the app does not support external files in the .ovpn main configuration. That’s because more often than not, it may not make sense referring to relative paths in a mobile device environment. Think of the Mail app for example. The fix is straightforward though, say you have an external <codeclass="language-plaintext highlighter-rouge">ca</code> file:</p>
<p>The same applies to other settings like <codeclass="language-plaintext highlighter-rouge">cert</code>, <codeclass="language-plaintext highlighter-rouge">key</code>, <codeclass="language-plaintext highlighter-rouge">tls-auth</code> and <codeclass="language-plaintext highlighter-rouge">tls-crypt</code>. In the specific case of <codeclass="language-plaintext highlighter-rouge">tls-auth</code> with a key direction, like:</p>
<h3id="why-dont-siri-shortcuts-execute-in-the-background">Why don’t Siri Shortcuts execute in the background?</h3>
<p>Unfortunately Apple is guilty of not fixing a related bug. I mean, it’s been there for years -since iOS 9 with my first bug report dating back to 2017- without them caring at all. No feedback and not even a proper response. And of course, no progress.</p>
<p>This is one of the several threads remarking the issue:</p>
<p>Now, due to this bug, App Extensions can’t control VPN using custom protocols -Siri Intents Extension in this case, in order to run shortcuts in the background. Only native VPN protocols work (IKEv2, IPsec etc.).</p>
<p>In short, there’s really <em>nothing</em> I can do about it.</p>
<li>Explicitly added to the .ovpn configuration</li>
<li>Pushed from the server</li>
</ul>
<p>the default gateway is NOT changed. That is, your external IP won’t be the VPN’s IP. Double check the “Default gateway” entry in the “Configuration” page to see how your host profile looks like. On the other hand, the default gateway is always enforced for provider profiles.</p>
<p>This has been recently fixed in Passepartout 1.6.0 as it’s the standard OpenVPN behavior. Before 1.6.0, Passepartout erroneously assumed that all traffic should go through the VPN implicitly.</p>
<h3id="id-like-to-see-a-today-widget-in-the-notification-center">I’d like to see a Today Widget in the Notification Center</h3>
<p>The reason behind not providing a widget is exactly the same as Siri Shortcuts. A widget would still need to open the app, thus making it quite useless.</p>
<h3id="id-like-to-see-my-ip-address-in-the-app">I’d like to see my IP address in the app</h3>
<p>The reason why Passepartout does not present any personal information in app is <em>privacy</em>. Obtaining one’s IP address, regardless of being connected to a VPN or not, involves querying -and trusting- a third party service. Knowing such info is also of little use, given that most of the time you don’t want to share your VPN IP address and therefore link your identity to it. However, this feature might be introduced later as a diagnostic tool.</p>
<h3id="mullvad-ignores-my-custom-dns-settings">Mullvad ignores my custom DNS settings</h3>
<p>It looks like Mullvad “hijacks” DNS on default endpoints, making custom DNS settings irrelevant. In order to do custom DNS with Mullvad, make sure to explicitly pick the “Custom DNS” preset, which will let you connect to the UDP:1400 and TCP:1401 endpoints. These endpoints do support custom DNS servers instead.</p>
<p>Until version 1.7.0 for iOS, you will have to do a manual “Refresh infrastructure” in order to access the new preset.</p>
<p>Read the <ahref="https://github.com/passepartoutvpn/api-source-mullvad/issues/1">related report on GitHub</a>.</p>
<p>Passepartout is slightly different from OpenVPN Connect when it comes to DNS. Due to the ability of overriding network settings in general, Passepartout lets the user specify what DNS servers to pick without any ambiguity (“Read .ovpn”, “Pull from server” or “Manual”). On the other hand, OpenVPN Connect merges and uses both the servers defined in the .ovpn file (first) and those pushed as <codeclass="language-plaintext highlighter-rouge">dhcp-option</code> by the VPN server (last). With this in mind, you should now understand why DNS in some networks may behave differently than the official OpenVPN clients.</p>
<li><ahref="https://github.com/sponsors/passepartoutvpn"title="Become a Sponsor on GitHub"class="fab fa-github"></a></li>
<li><ahref="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=KBT3G3AC7S9CC&source=url"title="Support with a PayPal donation"class="fab fa-paypal"></a></li>
<li><ahref="https://twitter.com/keeshux"title="Follow the author on Twitter"class="fab fa-twitter"></a></li>
<!-- li><a href="https://www.producthunt.com/posts/passepartout-vpn" title="Passepartout on Product Hunt" class="fab fa-product-hunt"></a></li -->
The logo is taken from the awesome <ahref="https://www.iconfinder.com/iconsets/circle-icons-1"title="Circle Icons">Circle Icons</a> set by <ahref="https://www.elegantthemes.com/"title="Elegant Themes">Nick Roach</a>
