The Zero-Cost Fortress Phone

// Building a free PBX on GCP with Tailscale, Callcentric, and a Grandstream ATA //

I wanted a house phone. Not a cell phone, not a VoIP app, but a real, pick-up-the-handset, hear-the-dial-tone house phone — the kind my kids (ages 7 to 12) could use to call grandparents without needing a screen, a charger, or a YouTube rabbit hole. The problem: traditional landlines are dead, and the telcos want $30-50/month for something that should basically be free in 2025. So I built my own. On the Google Cloud free tier. With a VPN mesh. And an analog telephone adapter. And I made exactly zero of the decisions correctly on the first try.

This is the story of the Zero-Cost Fortress Phone — a project that took me through three SIP trunk providers, two driver architectures I didn’t know were different, a CPU steal time rabbit hole, a NAT masquerade bug that took tcpdump to find, and enough pivots to qualify as an agility course. If you’re here to follow along and build your own, every step is documented. If you’re here to laugh at my mistakes, there’s plenty of that too. Either way, by the end, I had a working household phone system that costs roughly $1.35/month and is invisible to the public internet.

The Dream: Why Build This?

Here’s the thing about having kids in the 7-12 age range: they need to make phone calls, but they shouldn’t have smartphones. Grandparents want to hear their voices. The school office needs a number to call. And sometimes you just want a phone that rings in the kitchen like it’s 1997 and the only thing waiting on the other end is your mom asking if you’ve eaten.

But landline service from the telco? That’s $30-50/month for something that costs approximately nothing to provide. VoIP providers like Vonage and Ooma charge $15-20/month. And all of them want you to use their hardware, their app, their ecosystem. I wanted out of all of it.

The requirements were simple: a phone that works like a phone, that my kids can pick up and dial, that rings when someone calls, that has voicemail, and that doesn’t cost me a car payment every year. Oh, and I wanted it to be secure — no SIP ports exposed to the internet, no attack surface for toll fraud, no trusting my home IP to the mercy of a dynamic DNS update.

What I ended up with is a system where a virtual machine on Google Cloud runs Asterisk and FreePBX, connects to a SIP provider through the public internet for PSTN access, and reaches my living room through a WireGuard-based mesh VPN called Tailscale — with no public SIP or RTP ports exposed anywhere. The analog phone on my desk connects through a Grandstream HT801V2 ATA, which registers to the PBX over the encrypted tunnel. The whole thing costs about what a cup of coffee costs per month.

The Architecture

Before we get into the build, let me show you what we’re building. This diagram represents the final, working architecture — not the first draft, which looked very different and had a certain Google Voice-shaped hole in it.

The key insight in this architecture is that the PBX lives in the cloud, but the phone lives on my desk. They’re connected by Tailscale, which creates an encrypted WireGuard tunnel between them. The PBX’s Tailscale IP (100.99.48.20) is the only SIP address the Grandstream ever sees — not the GCP public IP, not my home IP, not anything that shows up in a Shodan search. The GCP firewall only allows SIP/RTP traffic from the Tailscale CGNAT range (100.64.0.0/10). If you’re not on my Tailnet, you can’t even find the PBX’s VoIP ports.

The Arch Linux machine (kvm-host) serves dual duty: it’s both a hypervisor running other VMs and a Tailscale subnet router that advertises the home LAN (172.16.2.0/24) to the Tailnet. This means the PBX can reach devices on my home LAN without those devices needing Tailscale installed — which is critical because the Grandstream HT801V2 is a “dumb” SIP device that can’t run a VPN client.

Phase 1 — GCP Free Tier + Incredible PBX

Spinning Up the Cloud PBX

Google Cloud’s Always Free tier gives you one e2-micro VM per month in us-central1, us-east1, or us-west1. That’s 2 shared vCPUs (meaning you get 25% of a physical core on average) and 1 GB of RAM. It’s not a lot, but Asterisk doesn’t need a lot for a household PBX handling a couple of concurrent calls. The G.711 codec uses about 1% CPU per call. The math works — on paper.

The setup process is straightforward if you’ve ever used GCP before. Create a project, enable billing (required even for free tier — Google puts a $1 hold on your card to verify it), deploy an e2-micro VM with Debian 12 (Bookworm) and a 30 GB standard persistent disk. Both the VM and the disk fall within the free tier limits.

The Firewall: Lock It Down

Here’s where the “Fortress” part starts. I created exactly two GCP firewall rules. The first allows SSH from my home public IP only. The second allows all traffic from the Tailscale CGNAT range (100.64.0.0/10). That’s it. No public SIP ports, no public RTP ports, nothing for Shodan to find. The PBX is completely dark to the public internet for VoIP traffic.

Incredible PBX 2025 Installation

I used Ward Mundy’s Incredible PBX 2025 distribution, which bundles Asterisk 22, FreePBX 17, and a suite of preconfigured security tools (Fail2Ban, Travelin’ Man 3 IPtables firewall). The installer compiles Asterisk from source, which takes 25-40 minutes on the e2-micro’s shared vCPU. Go get coffee. Or lunch. Don’t interrupt it.

The Swap File (Don’t Skip This)

With 1 GB of RAM, the Linux OOM killer will eventually decide that Asterisk is expendable — usually at 3 AM on a Tuesday. A 2 GB swap file is mandatory, not optional:

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab
echo 'vm.swappiness = 10' >> /etc/sysctl.conf
sysctl -p

Setting swappiness to 10 tells the kernel to use RAM first and swap only as an emergency buffer. This is what you want for a VoIP server — you don’t want Asterisk’s memory pages getting swapped out during an active call.

Narrow the RTP Port Range

The default Asterisk RTP range of 10000-20000 is 10,000 ports. For a household PBX, I narrowed it to 100 concurrent channels (far more than we’ll ever need):

; /etc/asterisk/rtp.conf
[general]
rtpstart=10000
rtpend=10100

Whitelist Tailscale in the Incredible PBX Firewall

Incredible PBX includes its own iptables-based firewall (Travelin’ Man 3) that blocks all non-whitelisted IPs. You need to whitelist the entire Tailscale CGNAT range so any device on your Tailnet can reach the PBX:

/root/add-ip tailscale 100.64.0.0/10
/root/add-ip homelan 172.16.2.0/24

Phase 2 — The Callcentric Trunk (and the chan_sip Disaster)

This is the first major pivot in the project, and it’s entirely my fault. Let me tell you about it so you don’t make the same mistake.

The chan_sip vs. chan_pjsip Mistake

When I first set up the Callcentric trunk, I followed every guide I could find online. The problem? Most of those guides were written for chan_sip — Asterisk’s legacy SIP driver. My Incredible PBX 2025 system runs Asterisk 22 with chan_pjsip exclusively, which is a completely different configuration model with a completely different GUI.

The result was a guide that told me to add 40 alpha/bravo server entries to sip_custom_post.conf (a chan_sip concept that doesn’t exist in PJSIP), fill in a “PEER Details” text box (a chan_sip GUI element that doesn’t exist in the PJSIP trunk GUI), and use a “Register String” (a chan_sip mechanism replaced by structured PJSIP fields). I was essentially trying to configure a PJSIP system using chan_sip instructions, and of course nothing worked.

The Correct PJSIP Configuration

After scraping together information from Callcentric’s own PJSIP vanilla guide, the FreePBX community forums (specifically contributor Stewart1, who is a treasure), and the VoIP-info wiki, I arrived at a working PJSIP trunk configuration. Here are the critical settings that differ from the defaults:

After applying these settings, the trunk registered immediately:

I also whitelisted Callcentric’s IP ranges in the Incredible PBX firewall, which is critical — without it, inbound INVITEs from Callcentric’s servers are silently dropped:

/root/add-ip ip-callcentric1 199.87.144.0/21
/root/add-ip ip-callcentric2 204.11.192.0/22

Phase 3 — Tailscale: Making the PBX Reach the Living Room

Here’s the fundamental problem: the PBX lives in Google Cloud, and the phone lives on my desk. The phone is an analog device connected to a Grandstream HT801V2 ATA, which is a “dumb” SIP endpoint that can’t run a VPN client. I needed a way to bridge the PBX’s SIP/RTP traffic to the ATA without exposing any ports to the public internet.

The answer is Tailscale — a WireGuard-based mesh VPN that creates encrypted tunnels between authenticated devices. Each device on the Tailnet gets an IP in the 100.64.0.0/10 CGNAT range, and all traffic between them is encrypted and authenticated through your identity provider.

Installing Tailscale on the GCP Instance

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
# Authenticate via the URL printed to terminal
tailscale ip -4
# Returns something like 100.99.48.20 — this is the PBX Tailscale IP

This IP (100.99.48.20) is the address the Grandstream ATA will use as its SIP server. Every device on the Tailnet can reach the PBX at this IP, and no one else can.

The Subnet Router: Reaching Devices That Can’t Run Tailscale

The Grandstream HT801V2 can’t run Tailscale — it’s a purpose-built SIP device with no ability to install software. So I needed one of my existing machines to act as a Tailscale subnet router, making the entire home LAN reachable from the GCP instance through the Tailnet.

My Arch Linux server (kvm-host, at 172.16.2.3 on the LAN) already runs Tailscale, so I reconfigured it as a subnet router:

# Enable IP forwarding
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

# Reconfigure Tailscale as subnet router
sudo tailscale up --advertise-routes=172.16.2.0/24

Then I approved the subnet route in the Tailscale admin console (login.tailscale.com/admin/machines → edit route settings → check the box for 172.16.2.0/24). This makes the home LAN reachable from the GCP instance, so the PBX can send RTP audio back to the HT801V2’s LAN IP.

NAT Settings in Asterisk

Even though Tailscale encrypts and tunnels the traffic, Asterisk still sees the HT801V2’s source IP (a 172.16.2.x address) as being on a different network from itself (a 10.128.x.x GCP VPC address). Without proper NAT configuration, Asterisk will direct RTP audio to the wrong IP, resulting in one-way audio. In the FreePBX GUI under Settings → Asterisk SIP Settings, I configured:

These local network entries tell Asterisk that any call from a 100.x, 10.128.x, or 172.16.2.x address is “local” and doesn’t need external NAT manipulation. This is critical for two-way audio through the Tailscale tunnel.

Phase 4 — Choppy Audio: CPU Steal Time and Strict RTP

With the trunk registered and the Tailscale tunnel up, I made my first test call. The audio was soooo laggy and choppy — to the point of being completely unusable. The call connected, the IVR played, but the audio came through in stutters and gaps, like the PBX was underwater and only occasionally surfacing for air.

What Is CPU Steal Time?

The GCP e2-micro uses a shared vCPU — Google schedules your VM’s execution time on physical cores alongside other tenants. When the hypervisor takes the CPU away from your VM to give it to another tenant, that’s called steal time. For most workloads (web servers, databases), brief CPU delays are invisible. For VoIP, they’re catastrophic.

Here’s why: Asterisk generates RTP audio packets on a strict 20ms cadence (50 packets per second for G.711 ulaw). If the hypervisor steals the CPU for even 50-100ms during an active call, Asterisk can’t send or process 2-5 RTP packets on schedule. The result is a gap in the audio stream — what you hear as “choppiness.” And because Asterisk on the e2-micro uses only 2-5% CPU, the hypervisor sees that low utilization and becomes more aggressive about taking CPU time away, making the steal time problem worse, not better.

A sysadmin on ServerFault documented this exact phenomenon: “This is a somewhat common issue with workloads that are both latency-sensitive and CPU non-intensive. The power management sees the very low CPU usage and assumes it can throttle the processor, even though it should not!”

The Fix: Disable Strict RTP

While CPU steal time was the underlying cause, there was a second contributing factor that was much easier to fix: Asterisk’s Strict RTP setting. Strict RTP drops RTP packets that arrive from an unexpected source IP or port. In a NAT environment with Tailscale in the path, the RTP source address seen by Asterisk may differ from what was negotiated in the SDP, especially if Tailscale’s relay path is involved.

Disabling Strict RTP was the immediate fix:

For the record, if steal time had been the only issue, the fix would have been upgrading from the e2-micro to the e2-small (~$7/month for 0.5 vCPU and 2 GB RAM). Ward Mundy explicitly recommends this: “We would encourage you to move up to the Standard machine type for consistent performance.” But in my case, disabling Strict RTP was enough to get clean audio on the free tier.

Phase 5 — The Grandstream HT801V2: Registering the Analog Phone

The Grandstream HT801V2 is a single-port FXS ATA (Analog Telephone Adapter). It has one RJ-11 phone jack and one Ethernet port. You plug an analog phone into the phone jack, plug the Ethernet into your LAN, and configure it to register to your PBX via SIP. The ATA converts the analog audio signals to RTP packets and back again.

Creating the PJSIP Extension

Before touching the HT801V2, I created a PJSIP extension in FreePBX for it to register against. The critical settings on the Advanced tab:

Configuring the HT801V2

The HT801V2’s web interface is at whatever IP it gets from DHCP. You can find the IP by picking up the connected analog phone and dialing *** then 02 — the IVR announces the current IP address. Then open that IP in a browser.

Here are the critical settings that differ from defaults, and why each one matters:

Phase 6 — “The Person You Are Trying to Reach Is Unavailable”

With everything configured, I called my Callcentric DID from my cell phone. The call went through the trunk correctly. The IVR played. But when the call was routed to extension 1001 (the HT801V2), I got: “The person you are trying to reach is unavailable.”

Investigation: The Asterisk CLI Trace

I fired up asterisk -rvvv and called again. The trace told the whole story:

The THISDIAL was set to an empty string because PJSIP_DIAL_CONTACTS(1001) returned nothing. This function resolves a PJSIP endpoint to its registered Contact URI — and when nothing is registered, it returns empty. The dial status was set to CHANUNAVAIL, and the “unavailable” message played.

The HT801V2 wasn’t registered. But why?

The Suspects

Before I identified the real cause, I went down a rabbit hole investigating a known FreePBX 17 bug. GitHub issue #758 documented that extensions created via the “Quick Create Extension” modal get PJSIP/3 instead of PJSIP/EXTENSION in the Asterisk database. I checked:

Not the bug. The database entry was correct. The extension was properly configured. The problem was that the HT801V2 simply couldn’t reach the PBX to register.

I tested from a computer on the same LAN:

But from kvm-host (the Tailscale subnet router), the same ping worked:

The subnet router could reach the PBX, but other LAN devices couldn’t. The missing piece: a static route on the Sophos XG firewall telling LAN traffic destined for the Tailscale CGNAT range (100.64.0.0/10) to go through kvm-host (172.16.2.3).

Phase 7 — The Sophos XG Static Route That Wasn’t Enough

I added the static route on the Sophos XG: destination 100.64.0.0/10, gateway 172.16.2.3 (kvm-host). I figured that would be it — the Sophos would forward Tailscale-destined traffic to kvm-host, kvm-host would send it into the Tailscale tunnel, and we’d be good.

I was wrong.

Traffic reached the Sophos (hop 1 = 172.16.2.1) and then died. The static route was there, but the Sophos wasn’t forwarding the traffic. Why?

Lesson: Sophos XG Routes ≠ Sophos XG Firewall Rules

Sophos XG is a stateful firewall. Having a static route only tells the Sophos where to send packets — it does NOT mean the Sophos will actually allow the traffic through. Every packet that traverses the Sophos must pass through the firewall engine, and if there’s no rule explicitly allowing LAN → 100.64.0.0/10, the traffic gets silently dropped.

This is the most important lesson about Sophos XG for anyone building network infrastructure: routes and firewall rules are separate. A route without a matching firewall rule means traffic gets silently dropped. No error, no log entry in the default view — just silence.

Creating the Firewall Rule

I created a firewall rule on the Sophos XG:

After adding the firewall rule, I tested again:

Progress! Traffic now reached kvm-host (hop 2 = 172.16.2.3), which meant the Sophos was correctly forwarding it. But then it died again at kvm-host. The Sophos firewall rule was fixed, but kvm-host wasn’t forwarding the traffic into the Tailscale tunnel.

Phase 8 — The nftables Masquerade Fix: The Final Boss

At this point, I knew the Sophos was forwarding traffic correctly to kvm-host, and kvm-host could reach the PBX directly (pings from kvm-host worked). But kvm-host wasn’t forwarding traffic from other LAN devices into the Tailscale tunnel.

I ran a series of diagnostics on kvm-host to figure out what was happening.

Diagnostic 1: IP Forwarding

Good — IP forwarding was enabled.

Diagnostic 2: Tailscale iptables FORWARD Chain

The last ACCEPT rule was there, so Tailscale was allowing forwarded traffic through the FORWARD chain.

Diagnostic 3: The tcpdump That Revealed Everything

This is the diagnostic that cracked the case. I ran tcpdump on the Tailscale interface while pinging from a LAN device:

There it was. The packets were entering the Tailscale tunnel with their original LAN source IP (172.16.2.4) — they were NOT being NAT’d. The PBX at the other end received these packets, but when it tried to reply, it had no route back to 172.16.2.4. The reply packets went nowhere.

Why Tailscale’s Default SNAT Didn’t Help

By default, Tailscale subnet routers have SNAT (Source NAT) enabled via the --snat-subnet-routes flag. But Tailscale’s SNAT only handles traffic coming from the tailscale0 interface (inbound from the Tailnet). It uses a packet mark (0x40000) to identify this traffic and applies masquerade in the ts-postrouting chain.

I checked the nftables ruleset:

This rule only matches packets with mark 0x40000 — which is set on traffic coming in from tailscale0 (the Tailscale → LAN direction). Traffic from the LAN going out to tailscale0 has no such mark and no masquerade rule. The packets enter the tunnel with their original source IP, the PBX can’t route replies back, and everything dies in silence.

The Fix: One nftables Rule

The solution is one nftables masquerade rule for LAN traffic going out to tailscale0:

sudo nft add rule ip nat ts-postrouting oifname "tailscale0" ip saddr 172.16.2.0/24 counter masquerade

This rule says: any packet from the 172.16.2.0/24 LAN going out the tailscale0 interface should have its source IP masqueraded to kvm-host’s Tailscale IP. Now the PBX sees the packets as coming from kvm-host’s Tailscale IP (which it can reach), and return traffic flows naturally.

To persist this across reboots:

sudo nft list ruleset > /etc/nftables.conf
sudo systemctl enable nftables

The Three-Part Fix Summary

Getting LAN devices to reach the PBX through Tailscale required three separate changes, each one building on the last:

Miss any one of these three, and the whole thing falls apart. The static route without the firewall rule: silently dropped. The firewall rule without the masquerade: packets arrive but replies never come back. All three together: a working, encrypted, zero-port-exposed VoIP path from the cloud to your living room.

The Real Cost

Not literally zero, but close enough that the “Zero-Cost Fortress Phone” name is still in the spirit of the thing. The one-time hardware cost for the Grandstream ATA pays for itself in about two months compared to a $20/month VoIP service.

Lessons Learned

Every project is really two projects: the one you planned and the one you actually built. Here’s what I learned from the delta between them.

1. Know Your SIP Driver

chan_sip and chan_pjsip are not interchangeable. They are two completely different SIP stack implementations with different configuration models, different GUIs, different file formats, and different troubleshooting commands. If your FreePBX says “Add SIP (chan_pjsip) Trunk,” you are using PJSIP, and every guide written for chan_sip (PEER Details, Register Strings, sip_custom_post.conf) will lead you astray. Check which driver you’re using before following any guide.

2. Routes ≠ Firewall Rules (Sophos XG)

On a Sophos XG, a static route tells the kernel where to send packets, but the firewall engine independently decides whether to allow them. A route without a matching firewall rule means silently dropped traffic — no error, no obvious log entry, just nothing. This is probably the single most counterintuitive thing about Sophos XG for people coming from consumer routers where “port forwarding” does both jobs at once.

3. Tailscale SNAT Is Asymmetric

Tailscale’s default SNAT (--snat-subnet-routes) only masquerades traffic coming IN from tailscale0 (marked 0x40000). Traffic from the LAN going OUT to tailscale0 has no masquerade. This works for the primary use case (Tailnet devices accessing your LAN), but it’s a trap when you’re routing LAN traffic to the Tailnet through a separate firewall’s static route. You need to add your own masquerade rule for the LAN→tailscale0 direction.

4. tcpdump Is the Truth

When I was troubleshooting the routing issue, I spent time checking iptables rules, sysctl settings, and Tailscale configuration. None of it told me the real problem. Running tcpdump -i tailscale0 immediately revealed that packets were entering the tunnel with their original LAN source IP (172.16.2.4) instead of being NAT’d. The packet capture doesn’t lie — it shows you exactly what’s on the wire. When in doubt, tcpdump.

5. Strict RTP Can Break Audio Through VPN Tunnels

Asterisk’s Strict RTP setting drops packets from unexpected source IPs/ports. In a VPN tunnel scenario where the RTP source address may differ from what was negotiated in SDP (especially if the VPN path changes between direct and relay), Strict RTP will silently drop valid audio packets. Disabling it resolved choppy audio immediately, and the security tradeoff is acceptable when the PBX is behind multiple firewalls.

6. CPU Steal Time Kills VoIP on Shared vCPUs

The GCP e2-micro’s shared vCPU works fine for a PBX that spends 99% of its time idle. But the 1% of the time it’s handling an active call, any CPU steal time by the hypervisor creates gaps in the RTP packet stream that manifest as choppy audio. If you need consistent VoIP quality, a dedicated vCPU (e2-small at ~$7/month) is the minimum viable upgrade.

7. NAT Traversal on the ATA Should Be “No” When Using Tailscale

This is the most counterintuitive setting in the entire project. Normally, a SIP device behind NAT needs STUN or a public IP in its SDP so the PBX knows where to send RTP. But with Tailscale, the PBX can already reach the ATA’s LAN IP through the subnet router. Enabling NAT traversal causes the ATA to put the public IP in the SDP, which breaks audio because RTP must flow through the encrypted tunnel, not through carrier-grade NAT on the public internet.

References and Resources

Incredible PBX / Nerd Vittles

Ward Mundy’s Incredible PBX project is the foundation of this build. The installer script, the Travelin’ Man 3 firewall, and the comprehensive documentation at nerdvittles.com are what make deploying Asterisk on GCP feasible for mere mortals. His specific warning about e2-micro performance for VoIP (“don’t expect much more performance-wise than what you’d get with the original Raspberry Pi”) was prescient.

Callcentric PJSIP Vanilla Guide

Callcentric’s own Asterisk PJSIP configuration guide (callcentric.com/support/device/asterisk_pjsip) provides the canonical PJSIP settings for their service. I cross-referenced this with the FreePBX community forums, particularly contributor Stewart1, who provides detailed PJSIP guidance specific to FreePBX 17.

Tailscale Site-to-Site Documentation

Tailscale’s site-to-site networking documentation (tailscale.com/docs/features/site-to-site) covers the subnet router configuration, SNAT behavior, and the --snat-subnet-routes flag. The documentation is thorough but the asymmetric SNAT behavior (only masquerading traffic from tailscale0, not to it) is not prominently called out — you discover it through tcpdump.

FreePBX Community Forums

The FreePBX community forums at community.freepbx.org are an invaluable resource. The thread on Tailscale/PFSense/FreePBX integration, the Quick Create Extension bug discussion (GitHub issue #758), and Stewart1’s posts on Callcentric PJSIP configuration were all critical to solving problems in this project.

Grandstream HT801V2 Administration Guide

Available from grandstream.com/support/firmware. The VoIP-info forum thread on HT801 PJSIP configuration revealed the critical detail that the SIP server port must be appended to the server address (e.g., 100.x.y.z:5060) — the “Local SIP Port” field on the HT801V2 is for its own listener, not the server port.

ServerFault: Causes of RTP Jitter at the Server

The ServerFault thread documenting CPU steal time (ready time) causing periodic RTP jitter on VMware was the key insight for diagnosing the choppy audio issue. The specific observation that low CPU utilization makes hypervisors more aggressive about throttling — not less — explained why the e2-micro was particularly bad for VoIP despite Asterisk using only 2-5% CPU.

/* end of transmission */

built with: GCP free tier • Incredible PBX 2025 • Tailscale • Callcentric • Grandstream HT801V2 • stubbornness