Request for classic confinement for symlex-vpn

  • name: symlex-vpn
  • description: SymlexVPN is a proprietary desktop VPN client for Ubuntu. It supports OpenConnect, OpenVPN, WireGuard, VPN server switching, DNS handling, routing, firewall protection, and kill-switch functionality.
  • snapcraft: PRIVATE
  • upstream: PRIVATE
  • upstream-relation: Kolpolok Limited owns, develops, and maintains SymlexVPN and is the publisher of this Snap.
  • supported-category: Access to host resources not currently exposed sufficiently by snapd for VPN, TUN device, routing, DNS, firewall, and kill-switch integration.
  • reasoning: The application requires a privileged background VPN service. The service must create and manage TUN devices, start OpenConnect/OpenVPN/WireGuard, modify host routes, configure DNS, apply and remove firewall rules, and enforce the kill switch. The desktop GUI communicates with this privileged service through a local socket. The currently available strict-confinement interfaces do not provide all the required operations for reliable VPN connections and clean server switching. Under strict confinement, VPN connection attempts can fail because the service cannot fully manage the host networking stack. The Snap contains a GUI application and a separate privileged symlexvpn-service daemon. Classic confinement is required so the VPN engine can perform the necessary host-level networking operations on normal Ubuntu desktop systems.

I understand that strict confinement is generally preferred over classic.

I’ve tried the existing interfaces to make the snap to work under strict confinement.

Note that snappy-debug can be used to identify possible required interfaces. See https://snapcraft.io/docs/debug-snaps for more information.

This request has been added to the queue for review by the @reviewers team.

This isn’t a supported category, the list can be found here:

Note that there are plenty VPN clients in the store already that function well in a strictly confined snap, what were the exact errors you got when trying your snap strictly confined with the available interfaces ?

Thank you for pointing that out. You are correct that our previous supported-category value was not one of the listed supported categories.

We also need to clarify that our strict-confinement testing was not complete, so the checkbox claiming that we had fully tested the existing interfaces was premature.

The current SymlexVPN implementation uses a privileged VPN service to manage TUN devices, OpenConnect/OpenVPN/WireGuard processes, routes, DNS, nftables firewall rules, and the kill switch. We will now test a strict-confinement build with the available interfaces and provide the exact failure logs and denied operations.

If the available interfaces are sufficient, we will move the Snap to strict confinement. If they are not, we will document the specific missing host-networking capabilities for further review.

1 Like