OverView OutPost

1. Open the vSphere Client (web interface)
2. Right-click the host or cluster > Deploy OVF Template...
3. Select Local file and choose the provided .ova file
4. Follow the wizard: name the VM, pick the datastore, select the network (VLAN/portgroup)
5. Click Finish and wait for the import to complete
6. Start the VM

1. Copy the provided .vhdx file onto the Hyper-V host
2. In Hyper-V Manager, create a new Generation 2 VM and, at the disk step, choose Use an existing virtual hard disk pointing at the .vhdx (the Import Virtual Machine action will not work — it expects an exported VM folder, not a bare disk)
3. Set the Secure Boot template to Microsoft UEFI Certificate Authority (Settings → Security) — the default Microsoft Windows template refuses to boot Linux:

   Set-VMFirmware "<vm-name>" -SecureBootTemplate MicrosoftUEFICertificateAuthority
   

4. Configure resources (2 vCPU, 2 GB RAM), connect a virtual switch, start the VM

Generation 1? Tell us before the build: a .vhd is provided instead (same procedure, no Secure Boot setting needed).

1. Open Prism Central > Compute & Storage > Images > Add Image
2. Upload the provided .qcow2 file, type Disk, place it on the target cluster
3. Go to Compute & Storage > VMs > Create VM
4. Configure: 2 vCPU, 2 GB RAM, and set the Boot Configuration to UEFI (the image is built for UEFI boot)
5. Attach a disk: Clone from Image > select the uploaded image
6. Add a NIC on the desired subnet/VLAN
7. Save and start the VM

Proxmox VE

1. Copy the provided .qcow2 file onto the Proxmox host
2. Create a VM without a disk: 2 vCPU, 2 GB RAM, BIOS: OVMF (UEFI) with an EFI disk (the image is built for UEFI boot)
3. Import the image:

   qm importdisk <vmid> ovsgw-*.qcow2 <storage>
   

4. Attach the imported disk, set it as the boot device
5. Connect a bridge, start the VM

KVM / libvirt (without Proxmox)

Create and start the VM straight from the image:

virt-install --name overview-outpost --memory 2048 --vcpus 2 \
  --disk /var/lib/libvirt/images/ovsgw.qcow2 --import \
  --osinfo ubuntu24.04 --boot uefi \
  --network bridge=br0 --noautoconsole

The 28 entries to declare, each on TCP 443 and UDP 3478:

derp1-all.tailscale.com
derp2-all.tailscale.com
derp3-all.tailscale.com
derp4-all.tailscale.com
derp5-all.tailscale.com
derp6-all.tailscale.com
derp7-all.tailscale.com
derp8-all.tailscale.com
derp9-all.tailscale.com
derp10-all.tailscale.com
derp11-all.tailscale.com
derp12-all.tailscale.com
derp13-all.tailscale.com
derp14-all.tailscale.com
derp15-all.tailscale.com
derp16-all.tailscale.com
derp17-all.tailscale.com
derp18-all.tailscale.com
derp19-all.tailscale.com
derp20-all.tailscale.com
derp21-all.tailscale.com
derp22-all.tailscale.com
derp23-all.tailscale.com
derp24-all.tailscale.com
derp25-all.tailscale.com
derp26-all.tailscale.com
derp27-all.tailscale.com
derp28-all.tailscale.com

This list is a snapshot. Tailscale adds and removes regions; the source is authoritative. To regenerate it:

curl -s https://login.tailscale.com/derpmap/default |
  python3 -c "import json,sys; [print('derp%s-all.tailscale.com' % k) for k in sorted(json.load(sys.stdin)['Regions'], key=int)]"

The regions span several continents: that is expected — the VM measures latency to every relay to pick the closest one. See the FAQ on this.

Three rules instead of six, and a single entry to maintain instead of thirty — provided your firewall accepts a wildcard FQDN object. FortiGate, Check Point and most UTMs do; Palo Alto and Cisco ASA do not.

All other outbound traffic: DENY.

The scope is unchanged — everything stays restricted to the tailscale.com domain — but the firewall tracks the DERP servers itself instead of making you keep the list current.

FortiOS ships an Internet Service (ISDB) object Tailscale-Tailscale, maintained by FortiGuard: it already contains the IP ranges and ports of Tailscale's infrastructure. This is the simplest and most robust route — no FQDN and no DERP server to track.

Web UI

1. Policy & Objects > Firewall Policy > Create New
2. Source: the VM's address object · Destination: switch to the Internet Service tab and search for Tailscale
3. Pick Tailscale-Tailscale, action ACCEPT, and disable deep SSL inspection

CLI (FortiOS 7.x)

config firewall address
    edit "OverView-OutPost"
        set subnet 192.0.2.10 255.255.255.255
    next
    edit "OverView-Egress"
        set subnet 51.15.222.156 255.255.255.255
    next
end

config firewall service custom
    edit "WireGuard-OverView"
        set udp-portrange 32768-60999
    next
end

config firewall policy
    edit 0
        set name "OutPost-Tailscale"
        set srcintf "dmz"
        set dstintf "wan1"
        set srcaddr "OverView-OutPost"
        set internet-service enable
        set internet-service-name "Tailscale-Tailscale"
        set action accept
        set schedule "always"
        set ssl-ssh-profile "no-inspection"
        set nat enable
    next
    edit 0
        set name "OutPost-WireGuard"
        set srcintf "dmz"
        set dstintf "wan1"
        set srcaddr "OverView-OutPost"
        set dstaddr "OverView-Egress"
        set service "WireGuard-OverView"
        set action accept
        set schedule "always"
        set nat enable
    next
end

Without ISDB — FortiOS also accepts wildcard FQDN objects in a policy's dstaddr field:

config firewall address
    edit "Tailscale-Wildcard"
        set type wildcard-fqdn
        set wildcard-fqdn "*.tailscale.com"
    next
end

Default settings that break Tailscale

This is the most common cause on FortiGate: the rule is correct, but a profile enabled by default cuts the flow.

Quick diagnostics

# Is the ISDB loaded? (size, version, number of entries)
diagnose internet-service id-summary

# Which ISDB object does a Tailscale IP actually belong to?
diagnose internet-service match root <TAILSCALE_IP> 255.255.255.255

# Which service matches a given protocol / port / IP tuple?
diagnose internet-service info root 6 443 <TAILSCALE_IP>

# Trace how the flow travels through the policies
diagnose debug flow filter saddr 192.0.2.10
diagnose debug flow show function-name enable
diagnose debug flow trace start 20
diagnose debug enable
# … then to stop:
diagnose debug disable
diagnose debug reset

# What does the FortiGate actually see going through?
diagnose sniffer packet any 'host 51.15.222.156' 4

If diagnose internet-service match does not return Tailscale-Tailscale for an IP of derp1-all.tailscale.com, the ISDB is too small or out of date: fix internet-service-database before touching the rules.

WireGuard port — Fortinet recommends randomising the WireGuard client port. That setting lives on the tailnet side: contact OverSOC support if direct connections never establish.

Two ways to designate the destination. The App-ID is preferable: PAN-OS does not accept a wildcard inside an FQDN object (*.tailscale.com is rejected), and an FQDN object only stores 32 addresses while controlplane.tailscale.com already publishes 16 IPv4 and 16 IPv6 records.

Option A — App-ID rule (recommended)

Web interface

1. Objects > Addresses > Add — create two address objects, each with a Description so the next administrator knows what they are:
   • OVS-OUTPOST, your OutPost's IP as a /32, e.g. 192.0.2.10/32 — OverView OutPost VM in the DMZ, source of all OverView traffic
   • OVS-OVERVIEW, 51.15.222.156/32, used as-is — OverView platform egress IP, peer of the direct WireGuard tunnel
2. Objects > Services > Add — create the service the second rule will use:
   • Name: SVC-WIREGUARD
   • Description: UDP port range used by the direct WireGuard tunnel between the OutPost and OverView
   • Protocol: UDP
   • Destination Port: 32768-60999
   • Source Port: leave empty. The OutPost picks its source port itself, so restricting it here would drop the tunnel
   • Session Timeout: Inherit from application
3. Policies > Security > Add — tab by tab:
   • General: Name ALLOW-TAILSCALE, and a Description such as OverView OutPost: Tailscale control plane and encrypted relays. Remove with the OutPost VM.
   • Source: Source Zone is the zone the OutPost sits in, picked from your own zones, so it is rarely called dmz: it carries whatever name that segment has on your firewall. Source Address is the OVS-OUTPOST object created above. Leave Source User and Source Device on any, and Negate unchecked
   • Destination: zone untrust (your WAN zone), address Any
   • Application: add tailscale, tailscale-base, stun and ssl. PAN-OS lists what an application needs in the Depends On panel beside the list, and warns at commit when a rule is missing one: add whatever it shows there. Content releases currently pair tailscale with tailscale-base
   • Service/URL Category: application-default
   • Actions: Allow
4. Add a second rule for the direct tunnel, through the same tabs:
   • General: Name ALLOW-WIREGUARD, Description OverView OutPost: direct WireGuard tunnel to the OverView platform. Without it the traffic falls back to the relays.
   • Source: the same zone as the rule above, address OVS-OUTPOST
   • Destination: zone untrust, address OVS-OVERVIEW
   • Application: any
   • Service/URL Category: SVC-WIREGUARD
   • Actions: Allow
5. Move both rules above the rule blocking VPN / proxy categories (Move > Move Up, or drag them up the list)
6. Commit

Equivalent CLI

set address OVS-OUTPOST  ip-netmask 192.0.2.10/32 description "OverView OutPost VM in the DMZ"
set address OVS-OVERVIEW ip-netmask 51.15.222.156/32 description "OverView platform egress IP"
set service SVC-WIREGUARD protocol udp port 32768-60999 description "Direct WireGuard tunnel, OutPost to OverView"

set rulebase security rules ALLOW-TAILSCALE from dmz to untrust \
    source OVS-OUTPOST destination any \
    application [ tailscale tailscale-base stun ssl ] \
    service application-default action allow \
    description "OverView OutPost: Tailscale control plane and encrypted relays"

set rulebase security rules ALLOW-WIREGUARD from dmz to untrust \
    source OVS-OUTPOST destination OVS-OVERVIEW \
    application any service SVC-WIREGUARD action allow \
    description "OverView OutPost: direct WireGuard tunnel to OverView"

move rulebase security rules ALLOW-TAILSCALE top

Option B — if the tailscale App-ID is missing from your content release

Since an FQDN object cannot carry a wildcard, two object types have to be combined:

1. Objects > Addresses — one FQDN object per name: controlplane.tailscale.com, login.tailscale.com, log.tailscale.com, then one derpN-all.tailscale.com object per DERP region (live list). Group them under Objects > Address Groups.
2. Objects > Custom Objects > URL Category > Add — a TAILSCALE category containing *.tailscale.com/
3. In the rule: the address group as Destination, the custom category in the Service/URL Category tab

Things to watch

• NAT — Policies > NAT, on the rule applying to the VM, Translated Packet tab: translation type Persistent Dynamic IP and Port (PAN-OS 11.1.1 and later). On an older PAN-OS, create a dedicated Static IP NAT rule for the VM — with regular dynamic translation the source port is unpredictable and everything falls back to DERP relays.
• Decryption — Policies > Decryption: add a No Decrypt rule for OVS-OUTPOST. tailscaled rejects a re-signed certificate and enrolment fails.
• Security Profiles — the next trap once the rule is in place: traffic shows as allow in Monitor > Traffic yet the session is still cut. Check Monitor > Threat: a Vulnerability Protection or Anti-Spyware profile attached to the rule can reset it. Remove the profile for this rule.
• Signature of the block — an immediate RST after the ClientHello points to a reset-both action on a rule placed higher up, not to a closed port 443.

Quick diagnostics

# Does the rule actually match?
test security-policy-match from dmz to untrust source 192.0.2.10 \
    destination <TAILSCALE_IP> destination-port 443 protocol 6

# Are the FQDN objects resolved? (mapping, remaining TTL, last refresh)
request system fqdn show

# Force a refresh (whole table — there is no per-entry refresh)
request system fqdn refresh

In Monitor > Traffic, the filter (addr.src eq 192.0.2.10) and (app eq tailscale) isolates the OutPost's traffic and names the responsible rule in the Rule column.

Per Tailscale, Check Point establishes direct connections with no special configuration. All that is left is the outbound rule.

Objects

The leading dot is required. FQDN unchecked means non-FQDN mode, which matches the domain and its sub-domains (controlplane., derp1-all.…). Checked, the object would only match tailscale.com and www.tailscale.com.

Rules

Things to watch

• Non-FQDN mode relies on reverse DNS lookups: if matching proves unreliable, replace the Domain object with individually named Domain FQDN objects.
• Exclude the OverView-OutPost source from HTTPS Inspection — TLS interception breaks Tailscale enrolment.

Quick diagnostics

# Dropped packets in real time, with the drop reason (Ctrl+C to stop)
fw ctl zdebug + drop | grep 192.0.2.10

# Kernel tables of the reverse-DNS resolver used by Domain objects
fw ctl multik print_bl dns_reverse_cache_tbl

# Restart the resolver if Domain objects stop matching,
# then reinstall the policy
killall wsdnsd

Logs live in SmartConsole, Logs & Monitor tab, filtered on the OverView-OutPost source.

ASA — network objects of type fqdn do not accept wildcards, and DNS resolution must work on the appliance itself.

dns domain-lookup outside
dns server-group DefaultDNS
 name-server 8.8.8.8

! 192.0.2.10 = your OutPost's IP — replace it with yours
object network OVS-OUTPOST
 host 192.0.2.10
object network OVS-OVERVIEW
 host 51.15.222.156

object network TS-CONTROLPLANE
 fqdn controlplane.tailscale.com
object network TS-LOGIN
 fqdn login.tailscale.com
object network TS-DERP1
 fqdn derp1-all.tailscale.com
! … one object per DERP region published in the derp map

object-group network TS-ALL
 network-object object TS-CONTROLPLANE
 network-object object TS-LOGIN
 network-object object TS-DERP1

access-list DMZ_OUT extended permit tcp object OVS-OUTPOST object-group TS-ALL eq 443
access-list DMZ_OUT extended permit udp object OVS-OUTPOST object-group TS-ALL eq 3478
access-list DMZ_OUT extended permit udp object OVS-OUTPOST object OVS-OVERVIEW range 32768 60999
access-group DMZ_OUT in interface dmz

Firepower / FTD — URL objects do accept wildcards. Create a .tailscale.com URL object and use it in the URLs tab of an Access Control rule instead of enumerating 28 FQDN objects.

Things to watch

• Without a dedicated NAT port opening, Cisco pushes the traffic onto DERP relays: functional, just slower.
• Cisco Umbrella (endpoint agent): no known workaround, traffic always uses relays.
• Do not enable SSL/TLS decryption on this flow.

Quick diagnostics

! ASA — simulate the flow through the policy
packet-tracer input dmz tcp 192.0.2.10 12345 <TAILSCALE_IP> 443 detailed

! Are the FQDN objects resolved?
show dns
show run object network

! Is the ACL actually traversed? (hit counters)
show access-list DMZ_OUT

On Firepower / FTD, the equivalent logs are under Analysis > Connection Events, filtered on the VM's IP.

Aliases

Create aliases of type Host(s) — pfSense/OPNsense aliases resolve FQDNs periodically, but do not accept wildcards:

Rules (DMZ interface)

Watch out — outbound NAT

By default NAT rewrites the source port, which prevents direct connections. Switch Firewall > NAT > Outbound to Hybrid or Manual mode, then tick Static Port on the rule covering the VM's IP. Enabling NAT-PMP or UPnP achieves the same result.

Quick diagnostics

# What does the alias actually contain after DNS resolution?
pfctl -t Tailscale_CP -T show

# States open from the VM
pfctl -ss | grep 192.0.2.10

In every case, a firewall that lets outbound TCP/443 through is enough for the OutPost to work.