Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
E
elphel-pbx
Project
Project
Details
Activity
Releases
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Board
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Charts
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
Elphel
elphel-pbx
Commits
3b7288db
Commit
3b7288db
authored
Mar 21, 2026
by
Andrey Filippov
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Add phone VPN option note
parent
db576539
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
41 additions
and
0 deletions
+41
-0
2026-03-21-phone-vpn-option.md
notes/2026-03-21-phone-vpn-option.md
+41
-0
No files found.
notes/2026-03-21-phone-vpn-option.md
0 → 100644
View file @
3b7288db
# 2026-03-21 Phone VPN Option
Possible future option: use a Pixel 7 / Lineage phone directly as a PBX endpoint
without a travel router.
## Feasibility
Yes, this is feasible if the phone connects through the existing office VPN
entry point on
`192.168.0.15`
.
Recommended model:
-
do not expose SIP directly to the public mobile internet
-
keep the PBX whitelist strict
-
use the phone as a VPN client first, then register a softphone to the PBX over the VPN
## Preferred design
1.
`192.168.0.15`
remains the VPN server side.
2.
Existing port-knocking remains the gate to open VPN access.
3.
The phone performs the knock, then brings up the VPN.
4.
A softphone on the phone registers to the PBX through the VPN only.
5.
The PBX whitelist allows the VPN subnet rather than any dynamic mobile or Starlink IP.
## Why this is preferred
-
mobile public IPs are dynamic and often behind CGNAT
-
VPN over outbound mobile traffic is much easier to control than public SIP exposure
-
PBX security stays based on a small allow list
-
the same design also fits future Starlink or roaming cases
## Limitation
This is a good model for the phone itself as a SIP endpoint.
It is not a good replacement for an analog ATA or desk-phone setup.
For a remote ATA, the travel router remains the better design.
## Current expectation for remote analog service
-
use the new Cisco ATA behind the GL.iNet travel router
-
connect the travel router to the office over VPN
-
later reintroduce extension
`119`
as
`PJSIP`
over VPN
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment