nettica/nettica-client repository overview

⁠Nettica

Nettica is a global VPN service provider that allows customers to connect all their devices wherever they are: on-prem, in the cloud, or multiple clouds.

⁠In the Wild

Nettica now proudly announces secure cross-server OAuth2 authentication, enabling the Nettica "In the Wild" Ecosystem. It lets you securely embed services directly into a customer's self-hosted private network. You can use this container as a base for your offering. You'll need to use a shell script to launch the Nettica Client in the background while your app runs in the foreground. The Nettica Client has been hardened to run in a potentially hostile environment; your application should, too. The reason to use this as your base is it gets you "in-network" automatically. The other more important reason is that this container will run in your service enclave or, if approved, on the Nettica edge.

Visit Nettica⁠ for assistance configuring and using this container.

docker pull nettica/nettica-client:latest

SERVER=https://my.nettica.com
DEVICE=device-...
APIKEY=device-api-...
PORT=30000

docker run --rm -d --cap-add NET_ADMIN --cap-add SYS_MODULE --sysctl net.ipv4.conf.all.src_valid_mark=1 -e NETTICA_SERVER=${SERVER} -e NETTICA_DEVICE_ID=${DEVICE} -e NETTICA_API_KEY=${APIKEY} -p ${PORT}:${PORT}/udp nettica/nettica-client

Required and optional environment variables:

⁠Notes

• The existing Nettica service code will authenticate and launch a container in the customer's network. You must write your Dockerfile, configure the container with any additional environment variables, and launch it through Nettica Services (a feature of the Nettica VPN Server).
• The customer's browser makes the Nettica VPN API calls on both their Nettica VPN Server and the one providing the service (eg, the Nettica Admin⁠). The container should be stand-alone and should not rely on Internet access. It is something to keep in mind when designing your offering.
• Ultimately, you have full control over your services. Deleting the container will end a customer's service.
• The Nettica Client must run as root to configure WireGuard. Your service can run with lower privileges
• A thorough security review of your service must be made to ensure arbitrary commands cannot be made inside the container. This is to prevent escape to the enclave⁠. Note that the article expects you've already been compromised but not how you were compromised initially. Here are some simple examples of what not to do: don't install SSH in the container. Don't install curl.
• It is unnecessary to set --cap-add SYS_MODULE on a properly configured service host, eliminating the above risk. WireGuard is in the kernel by default, eliminating the need to load the module. If it's not in your kernel, upgrade.
• While the container may run in your enclave, a malicious customer has some access to it through the Nettica VPN API and whatever surface area you expose. It is also trivial to update their Nettica MongoDB database directly and attempt to propagate configuration changes through service updates. It is imperative that the NETTICA_SERVICE_HOST environment variable is configured when launching a container. This is set by default in the existing implementation.
• Expect additional preventative security measures to be taken; update your container images frequently to pick up the latest updates to Nettica and the Alpine base.
• There is no deb/rpm install for the Nettica VPN Server. You must pull and build from source⁠, or install the pre-built version in AWS⁠.

In the Wild service is currently Beta software.