00In short
A channel to the flip side
NII Iznanka builds an encrypted channel from your device to our server, a SPHERE. From there you go out to the internet from the SPHERE.
- Your provider and public Wi-Fi see only an encrypted stream to the SPHERE, with no site addresses or DNS requests
- Websites see the SPHERE’s address, not yours
- The channel protocol is built on AWG2 (AmneziaWG 2.0): WireGuard cryptography plus DPI masking
- Access comes from an NFVPN key: one for all your devices
01Protocol
Based on AWG2
Our protocol is built on AmneziaWG 2.0 (AWG2). It is an open-source fork of WireGuard that keeps its cryptography and speed but hides the traits deep packet inspection systems (DPI) use to recognize WireGuard.
Cryptography: same as WireGuard
| What | With |
|---|---|
| Key exchange | Curve25519, Noise IK pattern |
| Channel encryption | ChaCha20-Poly1305 |
| Hashes | BLAKE2s |
| Transport | UDP, one port per SPHERE |
Masking: what AWG2 adds
Plain WireGuard gives itself away by its gait: the handshake always has the same length, and service packets start with the same bytes. Such a channel gets cut without being decrypted. AWG2 breaks these traits:
| Technique | Parameters | What it does |
|---|---|---|
| Junk before the handshake | Jc, Jmin, Jmax | packets of random length that do not exist in the protocol are sent into the channel |
| Random size padding | S1 … S4 | service packets stop having one fixed length |
| Custom headers | H1 … H4 | message types do not match WireGuard; in AWG2 they are set as ranges |
| Signature packets | I1 … I5 | the start of a session looks like traffic of other protocols |
▸ Personal obfuscation
Every SPHERE has its own set of these parameters. It is born with the server and never repeats anywhere else: a fingerprint taken from one SPHERE is useless on the next.
Masking lives in the transport itself, so speed and latency barely change.
02A packet’s path
From the button to the website
- Drop-in. The app brings up an AWG2 channel to the chosen SPHERE: a masked handshake, then an exchange of encrypted packets.
- Inside the channel. All device traffic (or that of selected apps, if split tunneling is on) goes into the channel. DNS requests travel inside too and are resolved in the SPHERE.
- Exit. The SPHERE decrypts the packet and sends it to the internet from its own address. The reply comes back the same way.
- Evac. Disconnect and the channel is closed. The Kill Switch in the Windows client keeps traffic from leaking past the channel while it comes up.
03Who sees what
An honest table
| Who | Sees | Does not see |
|---|---|---|
| Provider, public Wi-Fi | that you are connected to a SPHERE address, the time and traffic volume | websites, DNS requests, contents |
| SPHERE | the address you connect from while the channel is open; where packets go (that is how any VPN works) | records nothing: no site addresses, no DNS requests, no contents |
| Website | the SPHERE’s address and everything you tell about yourself (account sign-in, cookies) | your real IP |
| Us | the key, the device list, traffic counters, email or Telegram ID | where you go and what you do there |
Details on data: terms of use.
04Key and devices
Pass NFVPN
- The key is issued by your account on the website (after email confirmation) or by the Telegram bot. It is one for all your devices
- The app sends the key over HTTPS in the request body, not the URL, so it does not end up in anyone’s logs
- On first connection the device is registered: the SPHERE generates its own WireGuard key pair for it
- Keys are stored encrypted on our side (AES-256-GCM), and the access key itself also as a hash
- “Reset devices” in your account or the bot revokes all pairs in every SPHERE at once. The key stays the same
05SPHERES
Our servers
- Every SPHERE is ours: rented, configured and firewalled by the NII Iznanka team. We do not resell someone else’s pool
- The SPHERE agent knows only device public keys and byte counters. DNS request collection is disabled and removed from it
- Speed is shared fairly: each device has its own cap so no one hogs the channel
- SPHERES do not know about each other: if one goes down, the others keep running and the app offers another
- SPHERE codes (1-1 AENSLAND, 1-2 MANDALA …) are the same on the website, in the bot and in the app
06Apps
Gear
| Platform | How it holds the channel |
|---|---|
| Windows | a service and the Wintun driver, Kill Switch, per-app exclusions |
| Linux | a single AppImage, the channel comes up via pkexec |
| Android | system VPN, split tunneling by app, drop-in on start |
| Steam Deck | a Decky plugin right in Game Mode |
| iPhone, iPad, Mac | an AWG configuration file from your account for a compatible client |
07Limits
What a VPN does not do
- It does not make you anonymous on sites where you are signed in to your account
- It does not protect against trackers and cookies in the browser
- It does not cure malware on the device itself
- It does not hide what you tell about yourself
08Security
Found a vulnerability?
Write to security@iznanka.tech: we will look into it and thank you. The same team does audits and pentesting for companies, more on the home page.