FPTN: a packet tunnel that disguises itself as HTTPS traffic

An L3 tunnel, not a proxy with a config file

FPTN is described as custom VPN technology, and the first technical decision that follows from that is that it tunnels raw IP packets rather than proxying HTTP requests. The tunnel encapsulates and transmits IPv4 and IPv6 packets over a secure connection to the VPN server.

That design has consequences. Because it operates at the network layer, anything the operating system can send, the tunnel can carry, including traffic from applications that have no idea a proxy exists. The cost is that routing and name resolution behaviour on the client become the user's problem, which is why the split tunnelling feature exists.

Split tunnelling gives granular control over routing policies: users define rules, based on domains or IP networks, that specify which traffic goes through the VPN tunnel, while everything else uses the direct internet connection. For a user on a partially restricted network, this is the difference between a VPN that works and a VPN that makes every other site unreachable.

The server performs Network Address Translation, and the roadmap includes user grouping into virtual LANs for peer-to-peer communication within the VPN. NAT plus tunnelling means the server is the single egress point, and grouping users into VLANs would let peers reach each other inside the server's address space without exposing them to the internet.

The project also filters unwanted traffic by protocol, naming BitTorrent as the example, which is a practical concession to running a shared exit node.

Three disguise mechanisms, and a server that only reveals itself to its own clients

The evasion layer is the heart of the project, and the documentation is unusually specific about it.

The server can identify FPTN clients during the TLS handshake by analysing the session_id, which the client can set using a special time-based method. If the client is not recognised as an FPTN client, the server acts as a transparent proxy and returns legitimate content for the requested domain. In other words, a probe that is not a real client gets what a normal website would return, which is a different kind of failure from a server that simply refuses the connection.

Three bypass methods are described as implemented. SNI spoofing sets a fake domain name in the TLS ClientHello, so traffic analysis systems observe what looks like a legitimate TLS connection while the traffic is actually routed to the VPN server. Obfuscation disguises the traffic as an already established TLS session, hiding the initial handshake. And Reality mode with SNI spoofing has the client connect with a spoofed Server Name Indication, receive a genuine TLS handshake response from the actual website it named, and then continue exchanging data with the VPN server inside that same connection.

That third one is the most interesting, because the first bytes on the wire are indistinguishable from a real visit to the named site. The desktop client includes an integrated SNI scanner utility, which is how a user finds a suitable domain to point at.

A mode for short-lived HTTPS connections is listed as under development, which suggests the authors are still working on the case where a client needs a very short connection and cannot afford to look like an established session.

Protobuf transport with padded packets

The transport between client and server is a proprietary protocol based on Protocol Buffers. Using a schema-based serialisation rather than a raw byte stream means the two ends share an explicit definition of the message shapes, which is a practical choice for a project with several client implementations in different languages.

On top of that, the protocol applies padding at the packet level: data packets are padded with random data to randomise traffic patterns and complicate analysis. This is a traffic-shaping measure rather than a security measure. It does not make the traffic unrecognisable on its own; it makes the sizes of packets less informative, which defeats a class of DPI heuristic that relies on packet length patterns rather than on signatures.

The server exposes a REST API for client authentication and for retrieving specific configuration settings. That split is sensible: authentication and configuration over ordinary HTTP semantics, data over the custom protocol.

Server-side behaviour includes a traffic shaper based on the Leaky Bucket algorithm, which allows per-user bandwidth and traffic policies to be configured granularly. The server also supports a multi-server architecture with a single master server that stores all user data and configuration, and it exposes system monitoring through Prometheus with dashboards in Grafana.

Users interact with the service through a Telegram bot, which is where the connection tokens come from and where the service can be managed.

Tokens replace configuration, and the client is deliberately small

Onboarding is the piece most consumer VPNs get wrong, and FPTN's answer is a token. A token is described as a specially generated configuration file containing all necessary settings for the system, which the user imports into the client application to begin using the service. No server address typing, no certificate handling, no manual profile setup.

The client itself is minimal by design. It lives in the system tray, and clicking the icon opens a context menu. The Settings menu is where you add an access token, obtained by contacting the project's Telegram bot, pasted into the Add Token form and saved. After that, the available servers appear in the list and you connect.

The desktop clients cover Windows, macOS and Linux, described as minimalist and focused on ease of use. Mobile clients cover Android with an iOS version under development. Underneath all of them sits libfptn, a cross-platform core library that implements the FPTN network protocol, connection management and data transmission for the tunnel. That separation is the important architectural choice: the protocol lives in a library, and each platform client is a thin shell over it.

The project also supports turning a Raspberry Pi or Orange Pi into a WiFi access point with the FPTN client installed, in which case every device on that network gets internet access through the tunnel. The instructions for that are in the repository under deploy/linux/wifi/. That is a genuinely useful deployment shape for a home or travel setup where the alternative is configuring a tunnel on every device.

Building it is a CMake and Conan job with a Python linting helper

The repository is a C++ project with a conventional multi-language build layout. At the top level there is a CMakeLists.txt, a conanfile.py, a `.conan/` directory holding the Conan configuration, a `depends/` directory, `src/` for the code, `tests/`, `deploy/` for deployment scripts, `docker-compose/` for containerised deployment, `sysadmin-tools/` for server side scripts, and `docs/`.

The tooling is described by the configuration files that are present. There is a `.clang-format` and a `.clang-tidy` for the C++ side, a `.cmake-format` for CMake files, and `cpplint.py`, Google's C++ style checker written in Python. The Python tooling is configured in pyproject.toml:

[tool.black]
line-length = 120
extend-exclude = '''
cpplint\.py
'''

So Black formats the Python with a 120 character line length, excluding the linting helper itself, and `cpplint.py` enforces the C++ style. The topics also list cpp17 and cpp20, and the code is C++.

Dependency management is Conan rather than a system package manager, with `renovate.json` at the root for automated dependency updates, and a `.github/` directory carrying the CI workflow whose badge appears in the README. There is also a `CLAUDE.md` file, which is the current convention for repository instructions aimed at coding agents.

The release history shows a steady cadence at a pre-1.0 version: 0.4.6 on 2026-10-03, 0.4.5 on 2026-09-12 and 0.4.4 on 2026-08-23. The repository is not archived and the last push was on 2026-10-03.

What operating the server side actually costs you

FPTN is a server plus clients plus a library, and the server is where the operational weight sits.

You run the server, you hold the user data, and the master server in the multi-server architecture is the single point that stores all user data and configuration. The traffic shaper enforces the bandwidth policies you set, and Prometheus plus Grafana give you the visibility to see what is happening. Users are managed through a Telegram bot, which is convenient for them and means your user management surface is a chat interface rather than an admin panel.

The security posture of that arrangement is worth thinking about carefully. A server that terminates obfuscated tunnels for your users, holds their tokens, and enforces their traffic policies is a high value target, and it sits exactly where the people using it expect the content to be. Anyone using FPTN to reach a blocked domain is trusting an operator with their traffic. The project is explicit that it hosts content on a Google Cloud Storage bucket for the project website, and the client and server are both yours to run, which is the point, but it does not remove the need to secure your own server.

The comparison to an off-the-shelf VPN protocol is the fair one. WireGuard or OpenVPN give you a well audited tunnel with no obfuscation at all, which is exactly why they are blocked in the places FPTN is aimed at. FPTN trades that audit surface and protocol simplicity for the ability to keep working where a standard client would be fingerprinted.

Editorial conclusion

Adopt FPTN if you are on a network that blocks or inspects VPN traffic and need routing control per domain or IP network rather than a full tunnel, and are prepared to operate the server side yourself. Do not adopt it if a standard WireGuard or OpenVPN setup already works on your network, since FPTN's own value is the obfuscation layer, and expect to run the server yourself because there is no hosted service described here. Verify first which disguise mode your network tolerates, that the SNI scanner in the desktop client finds a usable domain on your connection, and that the traffic shaping and Prometheus monitoring are configured before you rely on the multi-server setup.

Frequently asked questions

Official sources

1. fptn-project/fptn on GitHub
2. License: MIT
3. Project website
4. README
5. Releases