- Documented Access Control features (e.g., Device Approvals, Password Rotation, 2FA, Custom Login Pages). - Added detailed descriptions for Logs & Analytics (Access Logs, Request Logs, Action Logs). - Included configuration instructions and feature-specific notes for Pangolin Cloud and Enterprise Edition. Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
16 KiB
Documentation Index
Fetch the complete documentation index at: https://docs.pangolin.net/llms.txt Use this file to discover all available pages before exploring further.
Configure Sites
Configure Newt for connecting to Pangolin sites
Flags
Newt ID generated by Pangolin to identify the client.Example: 31frd0uzbjvp721
Example: h51mmlknrvrwv8s4r1i210azhumt6isgbpyavxodibx1k2d6
Example: https://pangolin.example.com
Example: 34534
Default: 1280
Default: 9.9.9.9
Options: DEBUG, INFO, WARN, ERROR, FATAL
Default: INFO
Default: 3s
Default: 5s
Example: /var/run/docker.sock
Default: false
Example: /tmp/healthy
Example: /path/to/updown.sh
Example: /path/to/blueprint.yaml
Default: false
Default: false (clients enabled)
Default: newt
Default: true
Default: false
Default: 127.0.0.1:2112
Default: false
Example: us-west-2
Default: false (accepts any cert)
Example: /path/to/client.crt
Example: /path/to/client.key
Example: /path/to/ca.crt
Example: /path/to/client.p12
Example: https://preferred.endpoint.com
Environment Variables
All CLI arguments can be set using environment variables as an alternative to command line flags. Environment variables are particularly useful when running Newt in containerized environments.
When both environment variables and CLI arguments are provided, CLI arguments take precedence. Endpoint of your Pangolin server (equivalent to `--endpoint`) Newt ID generated by Pangolin (equivalent to `--id`) Newt secret for authentication (equivalent to `--secret`) Port for the peers to connect to Newt on (equivalent to `--port`) MTU for the internal WireGuard interface (equivalent to `--mtu`)Default: 1280
Default: 9.9.9.9
Default: false
Default: INFO
Default: 3s
Default: 5s
Default: false
Default: false
Default: newt
Default: true
Default: false
Default: 127.0.0.1:2112
Default: false
Default: false
Loading secrets from files
You can use CONFIG_FILE to define a location of a config file to store the credentials between runs.
$ cat ~/.config/newt-client/config.json
{
"id": "spmzu8rbpzj1qq6",
"secret": "f6v61mjutwme2kkydbw3fjo227zl60a2tsf5psw9r25hgae3",
"endpoint": "https://app.pangolin.net",
"tlsClientCert": ""
}
This file is also written to when newt first starts up. So you do not need to run every time with --id and secret if you have run it once!
Default locations:
- macOS:
~/Library/Application Support/newt-client/config.json - Windows:
%PROGRAMDATA%\newt\newt-client\config.json - Linux/Others:
~/.config/newt-client/config.json
Docker Socket Integration
Newt can integrate with the Docker socket to provide remote inspection of Docker containers. This allows Pangolin to query and retrieve detailed information about containers running on the Newt client, including metadata, network configuration, port mappings, and more.
Configuration:
You can specify the Docker socket path using the --docker-socket CLI argument or by setting the DOCKER_SOCKET
environment variable. If the Docker socket is not available or accessible, Newt will gracefully disable Docker
integration and continue normal operation.
Supported values include:
-
Local UNIX socket (default):
You must mount the socket file into the container using a volume, so Newt can access it.
unix:///var/run/docker.sock -
TCP socket (e.g., via Docker Socket Proxy):
tcp://localhost:2375 -
HTTP/HTTPS endpoints (e.g., remote Docker APIs):
http://your-host:2375 -
SSH connections (experimental, requires SSH setup):
ssh://user@host
services:
newt:
image: fosrl/newt
container_name: newt
restart: unless-stopped
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
environment:
- PANGOLIN_ENDPOINT=https://example.com
- NEWT_ID=2ix2t8xk22ubpfy
- NEWT_SECRET=nnisrfsdfc7prqsp9ewo1dvtvci50j5uiqotez00dgap0ii2
- DOCKER_SOCKET=unix:///var/run/docker.sock
If the Docker socket is not available or accessible, Newt will gracefully disable Docker integration and continue normal operation.
Hostnames vs IPs
When the Docker Socket Integration is used, depending on the network which Newt is run with, either the hostname ( generally considered the container name) or the IP address of the container will be sent to Pangolin:
- Running in Network Mode 'host': IP addresses will be used
- Running in Network Mode 'bridge': IP addresses will be used
- Running in docker-compose without a network specification: Docker compose creates a network for the compose by default, hostnames will be used
- Running on docker-compose with defined network: Hostnames will be used
Docker Enforce Network Validation
When run as a Docker container, Newt can validate that the target being provided is on the same network as the Newt container and only return containers directly accessible by Newt. Validation will be carried out against either the hostname/IP Address and the Port number to ensure the running container is exposing the ports to Newt.
Validation is false by default. It can be enabled via setting the --docker-enforce-network-validation CLI argument
or by setting the DOCKER_ENFORCE_NETWORK_VALIDATION environment variable.
Updown Scripts
You can pass in an updown script for Newt to call when it is adding or removing a target:
--updown "python3 test.py"
The script will be called with arguments when a target is added or removed:
python3 test.py add tcp localhost:8556
python3 test.py remove tcp localhost:8556
Returning a string from the script in the format of a target (`ip:dst` so `10.0.0.1:8080`) will override the target and use this value instead to proxy.
You can look at `updown.py` as a reference script to get started!
mTLS Authentication
Newt supports mutual TLS (mTLS) authentication if the server is configured to request a client certificate. You can use either a PKCS12 (.p12/.pfx) file or split PEM files for the client cert, private key, and CA.
Option 1: PKCS12 (Legacy)
This is the original method and still supported.Requirements:
- File must contain:
- Client private key
- Public certificate
- CA certificate
- Encrypted
.p12files are not supported
Example:
newt \
--id 31frd0uzbjvp721 \
--secret h51mmlknrvrwv8s4r1i210azhumt6isgbpyavxodibx1k2d6 \
--endpoint https://example.com \
--tls-client-cert ./client.p12
Option 2: Split PEM Files (Preferred)
You can now provide separate files for:
--tls-client-cert-file: client certificate (.crtor.pem)--tls-client-key: client private key (.keyor.pem)--tls-client-ca: CA cert to verify the server (can be specified multiple times)
Example:
newt \
--id 31frd0uzbjvp721 \
--secret h51mmlknrvrwv8s4r1i210azhumt6isgbpyavxodibx1k2d6 \
--endpoint https://example.com \
--tls-client-cert-file ./client.crt \
--tls-client-key ./client.key \
--tls-client-ca ./ca.crt
NAT Traversal Tweaks
Newt supports NAT traversal to allow clients to connect directly to Newt sites without relaying through the Pangolin server, improving performance and reducing latency.
In some environment depending on the NAT type and firewall, you may need to tweak some settings to get optimal connectivity in the firewall itself. Take a look at these docs for some firewall changes you might be able to make.
Another option is to keep newt listening for client connections on a static port. This allows you to open a specific
port in your firewall for Newt client connections instead of random high ports. You can do this by setting the --port
flag or PORT environment variable and then opening this port in the your firewall to DNAT to Newt.