The latest articles on DEV Community by Mohammad Montazeri (@mohammad_montazeri_4a8180). https://dev.to/mohammad_montazeri_4a8180 https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4017588%2Fb1bf05ec-f027-491c-ac73-bbae6a7ed8b6.png https://dev.to/mohammad_montazeri_4a8180 en Mohammad Montazeri Mon, 06 Jul 2026 10:40:24 +0000 https://dev.to/mohammad_montazeri_4a8180/why-vpn-services-should-not-force-users-into-proprietary-apps-4e2n https://dev.to/mohammad_montazeri_4a8180/why-vpn-services-should-not-force-users-into-proprietary-apps-4e2n <h1> Why VPN services should not force users into proprietary apps </h1> <p>Most VPN services try to own the entire user experience.</p> <p>They provide the server, the account, the routing layer, and then force the user into a proprietary app.</p> <p>That approach can be convenient, but it also creates a form of vendor lock-in.</p> <p>For many users, especially technical users, the VPN client itself is not the problem. They already trust standard clients such as OpenVPN or operating-system-level VPN setup flows.</p> <p>The harder question is:</p> <blockquote> <p>Why should the VPN service also force the client?</p> </blockquote> <h2> Standard clients still matter </h2> <p>Standard VPN clients have several advantages:</p> <ul> <li>Users can understand what they are importing.</li> <li>Configuration files are portable.</li> <li>Setup is not tied to one vendor app.</li> <li>Technical users can inspect and manage their own connection flow.</li> <li>The VPN provider does not need to own every part of the user experience.</li> </ul> <p>OpenVPN <code>.ovpn</code> files are a good example of this model.</p> <p>The provider can generate the connection material, but the user can still import it into a standard OpenVPN-compatible client.</p> <h2> The service layer is still important </h2> <p>Avoiding a proprietary app does not mean removing the service layer.</p> <p>A VPN service can still provide:</p> <ul> <li>profile creation</li> <li>routing options</li> <li>credentials</li> <li>OpenVPN configuration downloads</li> <li>compatible L2TP/IPsec setup values</li> <li>active session visibility</li> <li>connection history</li> <li>quota and plan visibility</li> </ul> <p>The difference is that these features live in the dashboard and service layer, not inside a mandatory vendor-specific client.</p> <h2> The real distinction </h2> <p>The goal is not to replace OpenVPN or native VPN clients.</p> <p>The goal is to reduce vendor lock-in around the VPN service layer.</p> <p>A user should be able to use a standard client they already trust, while still getting a managed profile and dashboard experience.</p> <h2> When a proprietary app still makes sense </h2> <p>There are cases where a custom app is useful:</p> <ul> <li>non-technical users</li> <li>automatic server selection</li> <li>mobile onboarding</li> <li>advanced diagnostics</li> <li>kill-switch-style client behavior</li> <li>push-based account state updates</li> </ul> <p>But it should not always be the only option.</p> <p>Forcing every user into a proprietary app removes choice from users who already understand standard VPN clients.</p> <h2> What I’m building </h2> <p>I’m building Lisar Connect around this idea.</p> <p>Lisar Connect helps users create VPN connection profiles for standard clients such as OpenVPN and compatible L2TP/IPsec setup.</p> <p>The product focuses on profile creation, routing options, active sessions, connection history, and setup visibility — without forcing a proprietary VPN app.</p> <p>Website:<br> <a href="https://lisar.io" rel="noopener noreferrer">https://lisar.io</a></p> <p>Public setup docs:<br> <a href="https://github.com/lisarconnect/lisar-connect-docs" rel="noopener noreferrer">https://github.com/lisarconnect/lisar-connect-docs</a></p> <p>Feedback is welcome, especially from people who already use OpenVPN or manage VPN setups.</p> vpn openvpn security networking