Files
TREK/wiki/Internal-Network-Access.md
T
Maurice 7da0080557 docs(wiki): bring the wiki in line with 4.0.0 (#2034)
* docs(wiki): correct the install and operations pages for 4.0.0

Quick Start passed docker an empty ENCRYPTION_KEY: an assignment prefix is not
expanded on the same command line, so the server silently generated its own key
instead of taking the one the page told you to set. The tag examples pinned to
the 3.x line, the documented tmpfs size did not match the shipped compose file,
and several .env values were described as reaching the container when compose
never interpolates them.

* docs(wiki): match the MCP reference to the registered surface

The scope table was missing the whole Collections group and the totals said 27
scopes across 13 groups where the code registers 29 across 14. The Cloudflare
link on the setup page pointed at an anchor on its own page instead of the
heading on Troubleshooting.

* docs(wiki): correct the plugin and admin pages

Three links to Plugin-Development carried a .md suffix, which does not resolve on
the wiki. The admin pages described tabs, permissions and storage behaviour that
had moved on.

* docs(wiki): bring the feature pages back in line with the app

Costs still documented the old panel, where categories could be added, renamed,
reordered and deleted; they are fixed now and the panel is a day-grouped ledger
with settlements. Trip sharing, journeys, maps, packing, reservations and the
account pages had all drifted in the same way.

* docs(wiki): cover the pages the first pass did not reach

The MCP catalog listed 168 of the 201 registered tools; the settlement tools and
rate_place were missing here and the Collections family from the addon page.
Several resource rows claimed a trips:* scope where the handler asks for
trips:read.

* docs(wiki): tighten the corrections a review picked apart

The audit-log resource is the row id, not the credential id; an admin password
reset does not bump password_version the way the page implied; and a few of the
new paragraphs described behaviour more confidently than the code supports.

* docs(wiki): fix what a last read-through caught

Costs shows every figure in your display currency, not the trip's, and an
expense with no payer still counts against the members it is split between.
Studio's cutoff is a 1024px viewport rather than phones alone, and the
Integrations tab is gated on the providers an admin has configured.

* docs(wiki): the last few the review caught

A passkey satisfies the MFA policy everywhere except the WebSocket handshake,
which still asks for TOTP, so a passkey-only account under that policy gets no
live updates. Mobile optimizes a day from two places, not three. The ctx.db row
carried an unescaped pipe that split the table, and the Backups table linked
with a wiki link whose pipe did the same.
2026-08-25 12:36:52 +02:00

5.2 KiB
Raw Blame History

Internal Network Access

TREK makes outbound HTTP requests when you configure integrations such as Immich or Synology Photos. By default, it blocks requests to private and local IP ranges to prevent server-side request forgery (SSRF) attacks. You need to allow internal network access when those services are hosted on your LAN.

Default behavior

TREK has two SSRF guards, both in ssrfGuard.ts. Which one applies depends on the call site, not on who configured the URL.

The strict guard (safeFetch / safeFetchFollow, built on checkSsrf) covers most outbound traffic — Immich, Synology Photos, AirTrail, notification webhooks, ntfy, Unsplash, and place lookups. It resolves the hostname to an IP address before allowing the connection and blocks loopback, link-local and private ranges. Only the private ranges open up, and only with ALLOW_INTERNAL_NETWORK=true. The two tables below describe this guard.

The relaxed guard (safeFetchAdminConfigured, also exported as safeFetchLlm) covers endpoints that are expected to live on your own network: OIDC (discovery, token, userinfo, JWKS), the LLM providers behind the AI Parsing addon (a local Ollama or any OpenAI-compatible endpoint), and plugin OAuth token exchanges. It deliberately permits loopback and LAN targets, so a model server on localhost or an identity provider on your LAN works without ALLOW_INTERNAL_NETWORK. It still resolves every hostname, re-checks every redirect hop, and always blocks link-local and cloud-metadata addresses (169.254.0.0/16, the full fe80::/10, and the AWS and Alibaba metadata addresses).

Always blocked (no override possible)

Under the strict guard, these ranges are blocked regardless of any setting:

Range Description
127.0.0.0/8, ::1 Loopback
0.0.0.0/8 Unspecified
169.254.0.0/16, fe80::/16 Link-local / cloud metadata endpoints
::ffff:127.x.x.x, ::ffff:169.254.x.x IPv4-mapped loopback and link-local

The IPv6 link-local rule here matches the fe80: hextet only, which is narrower than the nominal fe80::/10 prefix (fe80:–febf:). In practice that is the same set of addresses, since RFC 4291 link-local addresses are always fe80::/64. The relaxed guard covers the whole /10.

Blocked unless ALLOW_INTERNAL_NETWORK=true

Range / Hostname Description
10.0.0.0/8 RFC-1918 private
172.16.0.0/12 RFC-1918 private
192.168.0.0/16 RFC-1918 private
100.64.0.0/10 CGNAT / Tailscale shared address space
fc00::/7 IPv6 ULA
IPv4-mapped RFC-1918 variants e.g. ::ffff:10.x, ::ffff:192.168.x
*.local, *.internal, localhost hostnames mDNS / internal DNS suffixes (e.g. Docker service names, LAN hosts) and the literal localhost

The hostname localhost is matched at the hostname stage too, but it normally resolves to a loopback address (127.0.0.1 or ::1), which the always-blocked loopback rule catches first — so under the strict guard it is blocked no matter how ALLOW_INTERNAL_NETWORK is set. On a host that maps localhost somewhere else, the hostname rule still applies and it stays blocked unless ALLOW_INTERNAL_NETWORK=true. The relaxed guard allows localhost outright, which is what makes a local Ollama the supported default for AI Parsing.

*.local and *.internal hostnames are permitted when ALLOW_INTERNAL_NETWORK=true — the guard still resolves them to an IP and enforces all IP-level rules, so any such hostname that resolves to a loopback or link-local address remains blocked regardless.

When to enable

Set ALLOW_INTERNAL_NETWORK=true when a service reached through the strict guard — Immich, Synology Photos, AirTrail, or a notification webhook — is hosted on your local network and you need TREK to reach it. You do not need it for a local or LAN Ollama, an OpenAI-compatible endpoint, an OIDC provider on your LAN, or plugin OAuth; those go through the relaxed guard and already work. Leave the flag off if only those need internal access, since turning it on widens the surface for every strict-guard integration at once.

See Environment-Variables for how to set environment variables.

Admin: Set ALLOW_INTERNAL_NETWORK=true in Environment-Variables before configuring Immich or Synology on a LAN.

DNS rebinding protection

Even with ALLOW_INTERNAL_NETWORK=true, TREK pins the DNS resolution to prevent rebinding attacks. When the guard checks a URL, it resolves the hostname once and records the IP. The outbound connection is then made directly to that IP using a pinned dispatcher (via undici), so the hostname cannot re-resolve to a different address between the check and the actual request.

Audit log

When a user saves an Immich URL that resolves to a private IP, TREK records an immich.private_ip_configured entry in the Audit-Log including the URL and the resolved IP address. AirTrail does the same with airtrail.private_ip_configured. Synology Photos does not emit an equivalent event.

See also