Why I run a PBX in the lab
I run 3CX because telephony brings together identity, signalling, media, certificates, NAT and firewall policy. A phone can appear registered while calls still fail, so the project teaches end-to-end troubleshooting rather than a single application screen.
Screenshot evidence
What I work with
- Create and secure extensions
- Understand SIP registration and RTP media paths
- Test remote clients and encrypted authentication
- Tune pfSense rules and NAT behaviour
- Investigate one-way audio and failed call setup
- Keep management access separate from public SIP exposure
How this connects to my earlier case study
The existing 3CX behind pfSense case study documents a specific NAT and firewall troubleshooting scenario. This page explains the broader platform knowledge around running and maintaining the PBX itself.
Security focus
Telephony systems are frequently targeted for credential abuse. I use strong extension credentials, restrict management access, review logs and avoid publishing provider details, live numbers or current SIP endpoints.
Keep the management interface private, use strong administrator credentials, restrict firewall exposure and test inbound and outbound calls with a non-production number before wider use.
Use the vendor-supported 3CX installer or appliance image in an isolated lab VM, assign a stable address, complete the web-based setup wizard and configure extensions before adding any SIP trunk.