Wiredoor Ingress 1.8.0

Option A: AWS Marketplace console

• Open the SecureAnyCloud Hardened WireGuard VPN & VPN, Proxy and Remote Access AMIs listing on AWS Marketplace. Choose View purchase options, then Subscribe. One subscription covers every version in the listing.
• When the subscription is active, choose Launch your software.
• Choose One-click launch from AWS Marketplace, or Launch from EC2 Console for the full launch wizard. In Version, choose Wiredoor Ingress 1.8.0 on Ubuntu 24.04, then choose your Region.
• Pick an instance type (m5.large is recommended, and the software charge is $0.04 per vCPU per hour) and your key pair.
• Set the security group. The listing's default group allows SSH (TCP 22), HTTP (TCP 80), HTTPS (TCP 443) and WireGuard (UDP 51820) from anywhere. TCP 80 and 443 must stay open to your visitors, and UDP 51820 to your nodes. Restrict TCP 22 to your own IP address.
• Choose a subnet with internet access and a public IP. Leave the metadata defaults, because the image already requires IMDSv2. Then choose Launch.

Option B: AWS CLI

Run the following commands on your own workstation. They create a security group and then launch the instance. Replace the AMI ID with the one shown for your Region on the Marketplace launch page. Replace the VPC, subnet, key pair and address with your own.

SG=$(aws ec2 create-security-group --group-name wiredoor \
  --description "Wiredoor ingress" --vpc-id vpc-0123456789abcdef0 \
  --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 22 --cidr <your-mgmt-cidr>
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 80 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 443 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol udp --port 51820 --cidr 0.0.0.0/0
aws ec2 run-instances \
  --image-id ami-0123456789abcdef0 \
  --instance-type m5.large \
  --key-name my-key-pair \
  --security-group-ids "$SG" \
  --subnet-id subnet-0123456789abcdef0 \
  --associate-public-ip-address \
  --metadata-options HttpTokens=required,HttpPutResponseHopLimit=1 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=wiredoor}]'

HttpPutResponseHopLimit=1 is optional but recommended. It stops anything running inside a container on the instance from obtaining an IMDSv2 token at all, as an extra wall behind the firewall rule described above. The image itself already requires IMDSv2.

Connect as ubuntu with the key pair you chose:

ssh -i ~/.ssh/my-key-pair.pem ubuntu@<public-ip>

First boot finishes within a couple of minutes of launch. It generates the admin password and the TLS certificate, loads the Wiredoor container, applies the metadata guard and starts Wiredoor, which then creates its WireGuard server key.

Your details are in /root/wiredoor-credentials.txt, which only root can read:

sudo cat /root/wiredoor-credentials.txt

# Wiredoor 1.8.0 - generated on first boot (sac). Unique to this instance; keep it safe. WIREDOOR_URL=https://203.0.113.25/ WIREDOOR_USERNAME=admin@wiredoor.local WIREDOOR_PASSWORD=<28 random letters and digits> WIREGUARD_ENDPOINT=203.0.113.25:51820/udp TLS_CERT_SHA256=36:CD:EA:...(32 hexadecimal pairs)...:59:64:F0 ...

Three services make up the appliance: Docker, the metadata guard and Wiredoor itself. Check that all three are active:

systemctl is-active docker.service sac-wiredoor-guard.service wiredoor.service

active active active

Exactly these ports are open on the instance: SSH, and the three ports Docker publishes for the container. The local DNS resolver also listens, on loopback only.

sudo ss -tulnp | grep -E ':(22|80|443|51820) '

udp UNCONN 0 0 0.0.0.0:51820 0.0.0.0:* users:(("docker-proxy",...)) udp UNCONN 0 0 [::]:51820 [::]:* users:(("docker-proxy",...)) tcp LISTEN 0 4096 0.0.0.0:80 0.0.0.0:* users:(("docker-proxy",...)) tcp LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* users:(("sshd",...),("systemd",...)) tcp LISTEN 0 4096 0.0.0.0:443 0.0.0.0:* users:(("docker-proxy",...)) tcp LISTEN 0 4096 [::]:80 [::]:* users:(("docker-proxy",...)) tcp LISTEN 0 4096 [::]:22 [::]:* users:(("sshd",...),("systemd",...)) tcp LISTEN 0 4096 [::]:443 [::]:* users:(("docker-proxy",...))

Wiredoor's API (port 3000), its metrics endpoint and its log forwarder listen only inside the container. Confirm that the WireGuard interface is up inside the container:

sudo docker exec -u root wiredoor wg show wg0 | head -3

interface: wg0 public key: kQ4m...(44 characters)...= private key: (hidden)

Run wiredoor-credential-check to sign in through Wiredoor's own nginx the way the dashboard does. It checks that unauthenticated and forged requests are refused, that a wrong password is refused, and that your password works. The check uses two of the five sign-in attempts allowed per 10 minutes.

sudo wiredoor-credential-check

WIREDOOR_CREDCHECK_OK credential round trip through Wiredoor's nginx: 401 anonymous, 401 forged token, 401 wrong password, this instance's password mints a JWT that authenticates /api/auth/me

Before you type the password, check that the certificate your browser receives is your instance's. Print its fingerprint on the instance.

sudo openssl x509 -in /etc/wiredoor/tls/cert.pem -noout -sha256 -fingerprint

sha256 Fingerprint=36:CD:EA:5A:...:B6:59:64:F0

Open https://<public-ip>/ in your browser. The browser warns that the certificate is self-signed. Open the certificate details and compare the SHA-256 fingerprint with the one above (and with TLS_CERT_SHA256 in the credentials file). Continue only if they match. Do not add the certificate to a trust store.

Sign in as admin@wiredoor.local with the password from the credentials file. The home page opens.

The Client / Nodes page lists the machines connected to this server. A new server has only Wiredoor's built-in local node, Wiredoor_Local, which is the server itself.

The Domains page lists the DNS names you publish services on. There are none yet.

On the machine whose services you want to publish (not on the EC2 instance), install the Wiredoor client (wiredoor-cli, https://github.com/wiredoor/wiredoor-cli) and connect it to this server.

In the dashboard, choose Create Node on the home page (or Add Client on the Client / Nodes page) and give the node a name. Copy the command that the node's page shows: wiredoor connect --url=https://<public-ip> --token=.... The token is a credential for that node, so treat it like a password. Wiredoor's documentation covers each platform: https://www.wiredoor.net/docs.

If you prefer a plain WireGuard client, choose Download Config on the node's page instead. The file contains the node's private key, so keep it on that machine only.

Nodes dial the address in WIREGUARD_ENDPOINT. The node appears as online in the dashboard once its tunnel is up.

On a connected node's page, choose Add Service for an HTTP service. Give it a name and the port the service listens on (on the node). Then give it either a path on this server (for example /grafana) or a domain (Step 8).

Wiredoor writes the nginx configuration and reloads it. The service is then reachable at https://<public-ip>/<path> or https://<domain>/.

You can limit each service to client IP ranges, give it an expiry, or protect it with an OAuth2 sign-in. Wiredoor runs oauth2-proxy for the sign-in once you configure a provider in /opt/wiredoor/.env.

To publish a service on a domain:

• Point the domain's DNS A record at the instance's public IP. Use an Elastic IP so the address does not change.

• Set ADMIN_EMAIL in /opt/wiredoor/.env to your own address, which is the Let's Encrypt registration contact. Then restart Wiredoor:

sudo nano /opt/wiredoor/.env
sudo systemctl restart wiredoor

• In the dashboard, choose Domains, then Add Domain, and choose Let's Encrypt for its certificate. Validation uses port 80, which this image answers for every domain.

The dashboard itself answers only on the instance's own addresses and names. To reach it on a domain too, add the name to /etc/wiredoor/admin-hosts (one per line) and restart Wiredoor.

echo "wiredoor.example.com" | sudo tee -a /etc/wiredoor/admin-hosts
sudo systemctl restart wiredoor

List the names the dashboard currently answers on:

sudo grep -o 'server_name [^_][^;]*;' /etc/wiredoor/nginx/default.conf

server_name 127.0.0.1 localhost 203.0.113.25 172.31.93.109 ec2-203-0-113-25.compute-1.amazonaws.com ip-172-31-93-109.ec2.internal;

Any other name on port 443 gets no answer. Test this with a made-up host name:

curl -ks -o /dev/null -w '%{http_code}\n' -H 'Host: not-this-server.example' https://127.0.0.1/ || true

000

Wiredoor can also publish raw TCP services on a range of public ports. This is off on this image, so only the four ports above are open. To turn it on:

• Add a port range, a list of single ports, or both to /opt/wiredoor/.env, for example TCP_SERVICES_PORT_RANGE=32760-32767.
• List the same ports in /etc/wiredoor/tcp-ports, one port or range per line (for example 32760-32767), so that the container publishes them.
• Open the ports in the instance's security group, then run sudo systemctl restart wiredoor.

The WireGuard endpoint in each node's configuration is the address that first boot found (VPN_HOST in /opt/wiredoor/.env). Attach an Elastic IP before you connect nodes. Then point Wiredoor at it and refresh the dashboard's host names:

sudo sed -i 's/^VPN_HOST=.*/VPN_HOST=<elastic-ip-or-dns-name>/' /opt/wiredoor/.env
sudo wiredoor-render-nginx
sudo systemctl restart wiredoor

Upstream Wiredoor forwards anything a node sends through the server. On this image, Wiredoor's own WireGuard rules, set at first boot, fence a node's traffic.

A node can reach other nodes and, if you select Send all internet traffic through the VPN for the node, the internet. It cannot open connections over the tunnel to the server itself (Wiredoor's API, metrics and log ports), to the metadata service, or to private address ranges (your VPC, the Docker network and this instance). Wiredoor's nginx still reaches every node to publish its services.

Show the rules inside the container:

sudo docker exec -u root wiredoor iptables -S FORWARD

-P FORWARD ACCEPT -A FORWARD -i wg0 -o wg0 -j ACCEPT -A FORWARD -d 10.0.0.0/8 -i wg0 -j DROP -A FORWARD -d 172.16.0.0/12 -i wg0 -j DROP -A FORWARD -d 192.168.0.0/16 -i wg0 -j DROP -A FORWARD -d 100.64.0.0/10 -i wg0 -j DROP -A FORWARD -d 169.254.0.0/16 -i wg0 -j DROP -A FORWARD -d 168.63.129.16/32 -i wg0 -j DROP -A FORWARD -i wg0 -j ACCEPT -A FORWARD -o wg0 -j ACCEPT

Connections that a node opens to the server itself over the tunnel are limited in the same way, to replies to Wiredoor's own connections and ping only:

sudo docker exec -u root wiredoor iptables -S INPUT

-P INPUT ACCEPT -A INPUT -p udp -m udp --dport 51820 -j ACCEPT -A INPUT -i wg0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -i wg0 -p icmp -j ACCEPT -A INPUT -i wg0 -j DROP

These rules are Wiredoor's own WG_POST_UP_SCRIPT / WG_POST_DOWN_SCRIPT settings in /opt/wiredoor/.env. Wiredoor stores them when it first starts.

If you want a node to reach something in your VPC, publish that VPC service through Wiredoor's local node instead (Step 7). The service is then subject to the same access rules as every other service.

Run wiredoor-imds-guard to show the firewall rules that drop everything containers send to the metadata addresses, with packet counters:

sudo wiredoor-imds-guard show

Chain DOCKER-USER (1 references) pkts bytes target prot opt in out source destination 0 0 DROP 0 -- * * 0.0.0.0/0 168.63.129.16 /* sac-wiredoor-imds */ 0 0 DROP 0 -- * * 0.0.0.0/0 169.254.0.0/16 /* sac-wiredoor-imds */ ...

Wiredoor cannot run without the guard. wiredoor.service requires sac-wiredoor-guard.service, and when Docker restarts, the guard is applied again before Wiredoor. A service whose target is the metadata address is refused when you create it, because Wiredoor cannot connect to it.

Docker, containerd and the Wiredoor unit are also denied the metadata service directly:

systemctl show -p IPAddressDeny docker.service containerd.service wiredoor.service

IPAddressDeny=169.254.169.254/32 fd00:ec2::254/128 168.63.129.16/32 IPAddressDeny=169.254.169.254/32 fd00:ec2::254/128 168.63.129.16/32 IPAddressDeny=169.254.169.254/32 fd00:ec2::254/128 168.63.129.16/32

wiredoor.service starts only after first boot has written /var/lib/sac/data/wiredoor.bootstrap-ready. Its preflight (/usr/local/sbin/wiredoor-preflight) refuses to start the container unless all of the following hold:

• The environment file is root-only and holds a real password.
• The end-entity certificate exists.
• The metadata guard is loaded.
• The pinned image is the one that was loaded.

The pinned image identity is in /etc/wiredoor/wiredoor.conf. List the loaded image:

sudo docker image ls --format '{{.Repository}}:{{.Tag}} {{.ID}}'

sac/wiredoor:1.8.0 d70dfa311b7a

Ubuntu's unattended upgrades install security updates daily, from the Ubuntu archive and from Docker's repository. The image adds Docker to the allowed origins in /etc/apt/apt.conf.d/51sac-docker-unattended. When Docker is upgraded, Wiredoor restarts with it and the metadata guard is applied again first.

The Wiredoor software itself never changes automatically. When SecureAnyCloud publishes a newer Wiredoor version in this listing, move to it by launching the new version and reconnecting your nodes.

Wiredoor's own log goes to the journal and to Docker's capped log:

sudo journalctl -u wiredoor.service --no-pager -n 5 | cut -c1-120

Find first-boot progress in sudo journalctl -u wiredoor-firstboot.service.

• Restrict TCP 22 in the security group to your own address. Keep TCP 80 and 443 open to your visitors and UDP 51820 to your nodes.
• Keep the admin password private. If you change it, use a long, random one (ADMIN_PASSWORD in /opt/wiredoor/.env, then sudo systemctl restart wiredoor).
• Treat node connection commands, access tokens and downloaded WireGuard configurations as secrets. Remove nodes you no longer use.
• Use domains with Let's Encrypt certificates for anything your users open in a browser.
• Launch with HttpPutResponseHopLimit=1 (Step 1, Option B) for an extra metadata wall.
• OAuth2 sign-in and go-jose advisory GHSA-mgcc-cww5-fp2q (CVE-2026-116587). The oauth2-proxy 7.15.5 on this image still links go-jose v3, which has no fix for this denial-of-service advisory. A crafted RSA key in a JSON Web Key Set (JWKS) can stall oauth2-proxy. On this image, oauth2-proxy does not run, and no identity provider, issuer or JWKS URL is configured until you set one up. If you enable OAuth2 for a service, point OAUTH2_PROXY_PROVIDER and any OIDC issuer or JWKS URL only at a trusted HTTPS endpoint that you control, or at your own identity provider. Never use an address that someone else can change, because only that provider's key set can trigger the advisory. SecureAnyCloud will publish a new version of this listing once oauth2-proxy moves off go-jose v3.
• Keep unattended upgrades on, so that Docker and the operating system stay patched.