¶ VPN Management
| Page | Description |
|---|---|
| Host parameters | Configure individual gateway settings, access control, and synchronization options. |
| Host registration | How gateways register and join the VPN network. |
| Host synchronization | Automatic topology synchronization between gateways and servers. |
| Site to Site | Permanent site-to-site VPN configuration between networks. |
| VPN On Demand | Automatic VPN connection on demand. |
| Groups | Manage host groups and security policies. |
¶ Weble VPN
Weble VPN is a peer-to-peer mesh VPN that connects gateways, servers, and end-users into a single private network over the public internet. Each host holds its own keys, authenticates every other host directly, and can route traffic to any other host on the mesh.
The network combines four ingredients:
- End-to-end encryption of every packet that leaves a host.
- Mutual authentication based on per-host public keys — there is no shared secret to leak.
- Layer 2 or Layer 3 transport, picked per VPN, so a site can extend an Ethernet segment or simply route IP between subnets.
- Multiple transport paths (direct UDP/TCP and several HTTP-based tunnels), tried in parallel so that the connection survives restrictive firewalls and proxies.
¶ Encryption
Each host owns an asymmetric key pair. When two hosts open a session, they use that key pair to authenticate each other and to negotiate a fresh symmetric key for the session — the long-term private key never leaves the host and the symmetric key is rotated regularly.
Bulk traffic is then encrypted with AES under the symmetric key, with each packet authenticated so that any tampering is detected and dropped. Key exchange uses Diffie-Hellman; identity is anchored in RSA / ECC keys signed by the Weble Cloud.
¶ Compression
VPN traffic can be compressed before encryption to reduce bandwidth on slow or metered links. Three algorithms are available:
| Algorithm | Trade-off |
|---|---|
| LZO | Very fast, modest compression ratio — the default for real-time traffic. |
| LZ4 | Slightly better ratio than LZO at similar speed. |
| Zlib | Higher ratio at the cost of more CPU — useful when bandwidth is the bottleneck. |
Compression is configured per host and is transparent to the protocols running on top of the VPN.
¶ TAP interface
Each VPN connection is exposed locally as a virtual network interface — a TAP interface, which behaves like a regular Ethernet card. Anything sent on this interface is encrypted, transmitted to the peer, and emitted on the peer's TAP interface; anything received works the same way in reverse.
Because a TAP interface emulates a full Ethernet NIC (Layer 2), it carries Ethernet frames with their MAC addresses — so VPN peers can be bridged into existing LAN segments and broadcast/multicast protocols (DHCP, ARP, mDNS, BACnet/IP discovery, etc.) keep working as if the peers were on the same physical wire.
When only IP routing is needed, the same interface can be operated in TUN (Layer 3) mode, which is lighter — Ethernet headers are dropped and only IP packets cross the tunnel.
¶ Layer 2 / Layer 3 support
Weble VPN can run at either layer, and the choice is made per VPN:
- Layer 2 (bridged) — the VPN behaves like a virtual Ethernet switch. Remote hosts share a single broadcast domain, which is what most field-bus and discovery protocols expect. Use this to extend an existing LAN to a remote site.
- Layer 3 (routed) — the VPN behaves like a virtual router between subnets. Lower overhead, no broadcast traffic, and easier to integrate with existing routing — at the price of losing Layer 2 features (broadcast, MAC-based access, link-local discovery).
¶ How the gateway connects to the VPN
When a Weble gateway joins the VPN, it does not pick a single connection method up front. It tries every available path in parallel and keeps the one that comes back first. The direct connection on port 655 is preferred when reachable; the other paths are tunnels designed to traverse restrictive networks.
At least one of the following outgoing flows must be allowed by the local firewall for the gateway to reach the Weble Cloud:
- TCP 655 + UDP 655 — direct connection (best performance)
- TCP 22 — SSH tunnel
- TCP 80 — WS, POLL or HTTP/2 tunnel
- TCP 443 — WSS or POLLS tunnel
¶ Direct connection (preferred)
The gateway opens a VPN session to the Weble Cloud on TCP 655 and UDP 655. This is the lowest-overhead path: traffic is encrypted natively and rides directly over IP, with no extra layer of encapsulation.
When the firewall allows it, this is always the path that wins the race.
¶ Tunnel methods (fallback)
When the direct path is blocked, the gateway falls back to a tunnel. Five tunnel methods are available; they all carry the same VPN traffic, but use different transports so that at least one of them is likely to slip through firewalls and proxies.
¶ WS / WSS — TCP 80 / 443
WebSocket-based tunnel. The gateway opens a regular HTTP connection, performs an Upgrade: websocket handshake, and then exchanges VPN frames bidirectionally as WebSocket frames over the same TCP connection.
- WS (TCP 80) is plaintext at the transport level — the VPN payload is still encrypted end-to-end.
- WSS (TCP 443) wraps the same exchange in TLS, so the traffic is indistinguishable from regular HTTPS.
WS / WSS works with any proxy or firewall that allows the WebSocket upgrade through.
¶ POLL / POLLS — TCP 80 / 443
HTTP long-polling tunnel. Used when an intermediate proxy strips the WebSocket upgrade or breaks long-lived connections. Two persistent HTTP requests run side by side:
- A POST request whose body carries outgoing VPN data — kept open and reissued whenever the gateway has more data to send.
- A GET request whose response carries incoming VPN data — kept open and reissued whenever the server has data to deliver.
- POLL (TCP 80) over HTTP.
- POLLS (TCP 443) over HTTPS.
POLL / POLLS is the most compatible fallback: any proxy that lets ordinary HTTP requests through will let it work, at the cost of slightly higher latency than WS/WSS or HTTP/2.
¶ HTTP/2 — TCP 80
HTTP/2 tunnel. A single TCP connection carries several multiplexed bidirectional streams. The gateway uses these streams to exchange VPN frames without having to keep separate POST/GET requests open as in POLL.
HTTP/2 offers lower latency than POLL while still going through any proxy that speaks plain HTTP.
¶ SSH — TCP 22
SSH-based tunnel. The gateway opens an SSH session to the Weble Cloud and uses local port forwarding to route VPN traffic through the SSH channel.
SSH provides its own encryption layer on top of the VPN's. This path is convenient on networks that allow outgoing SSH (port 22) but block almost everything else.
¶ Outgoing ports
For the gateway to be able to reach the Weble Cloud, the local firewall must allow at least one of the following outgoing flows:
| Direction | Protocol | Port | Service | Used by |
|---|---|---|---|---|
| Outgoing | TCP | 655 | VPN | Direct connection (preferred) |
| Outgoing | UDP | 655 | VPN | Direct connection (preferred) |
| Outgoing | TCP | 22 | SSH | SSH tunnel |
| Outgoing | TCP | 80 | HTTP | WS, POLL and HTTP/2 tunnels |
| Outgoing | TCP | 443 | HTTPS | WSS and POLLS tunnels |
Opening TCP 655 + UDP 655 alone is enough for the best performance. Opening TCP 443 alone is the most common compromise on restrictive networks: it allows the WSS or POLLS tunnel to establish a connection while looking like ordinary HTTPS traffic.