Telnyx Compute: Network — Full Documentation

Complete page content for Network (Compute section) of the Telnyx developer docs (https://developers.telnyx.com). This file: https://developers.telnyx.com/development/llms/compute-network-llms-full-txt.md · Root index: https://developers.telnyx.com/llms.txt

Private Networks

Network Overview

Source: https://developers.telnyx.com/docs/network/overview.md

Introduction

Telnyx programmable networking allows users and their application to access Telnyx SIP and API endpoints without traversing the public internet, therefore offering a path with better latency and throughput. The SIP and API endpoints are:

api.telnyx.com
sip.telnyx.com and their regional counterparts
*.telnyxcloudstorage.com where * is all available storage regions, e.g. us-central-1

The users’ applications can reside in any one of the major hyperscalers, i.e. AWS, GCP, and Azure, or the users’ own data centers (as long as the user has a presence in Equinix.) This model is analogous to certain AWS concepts — From the “outside” world, a user can use a Direct Connect to connect to private resources (e.g. your EC2 instances) or public resources (e.g. S3). Though to AWS, the “outside” world is largely limited to their users’ on premise data centers.

API Concepts

Coverage

Coverage API enumerates all the supported products at each of Telnyx’s PoP. Before creating any resources, please ensure that

There is a PoP in the vicinity from where you want to connect, and
The desired resources are available at that PoP.

Equally important, depending on the resource, there are product specific coverage endpoints you must consult. Refer to the coverage guide for more detail.

Networks

It is a logically isolated virtual network. It is a pre-requisite for the creation of other elements. Refer to the network guide for more detail.

Gateways

It is a virtual node that facilitates traffic routing between your Telnyx network and an outside network. There are three types of gateways.

WireGuard Gateways (WGW); in the API, it’s named interface
Internet Gateways (IGW)
Private Wireless Gateways (PWG)

WireGuard Gateways

It is a virtual VPN concentrator implemented with the open source WireGuard protocol. It is similar to

Virtual Private Gateway in AWS
VPN Gateway in GCP
Virtual Network Gateway in Azure

Refer to the WireGuard Gateway guide for more detail.

Internet Gateways

It is an element that routes traffic to and from the internet, similar to Internet Gateway or NAT Gateway in AWS Refer to the Internet Gateways Guide

Private Wireless Gateways

It is a private packet gateway that concentrates, routes, and segments traffic for a group of SIMs. Refer to private wireless gateway guide for more detail.

Virtual Cross Connects

It is a virtual direct connection between a supported cloud provider and Telnyx. Refer to VXC guide for more detail.

Coverage

Source: https://developers.telnyx.com/docs/network/coverage.md

Generic Coverage

Individual networking resource availability is not universal across all Telnyx regions. Hence the user must ensure the desired resource is offered at the desired region. To this end, we offer a coverage API (GET /v2/network_coverage). The location parameter is hierarchical:

Parameter	Value
`region`	`EMEA`, `AMER`, `APAC`
`site`	a broad geographical area within the region, e.g. `ORD` in `AMER`
`pop`	a specific data center within the site, e.g. `CH1` in `ORD`
`name`	a human readable name, e.g. `Chicago IL, US`
`code`	the unique ID for the site, e.g. `chicago-il`

The available_services parameter is an array of all available resources that can be created at this specific location. Possible values are:

virtual_cross_connect
cloud_vpn aka wireguard interface aka wireguard gateway
private_wireless_gateway
public_internet_gateway

Here are some common usage patterns of this API.

Querying by the desired product

GET /v2/network_coverage?filter[available_services][contains]=cloud_vpn

Querying by the desired product with a location constraint

GET /v2/network_coverage?filter[available_services][contains]=cloud_vpn&filter[location.region]=AMER

Querying by the desired location

GET /v2/network_coverage?filter[location.region]=EMEA

Here is a sample response:

{
    "data": [
        {
            "available_services": [
                "virtual_cross_connect"
            ],
            "location": {
                "region": "EMEA",
                "site": "FRA",
                "pop": "FR5",
                "name": "Frankfurt, DE",
                "code": "frankfurt-de"
            },
            "record_type": "network_coverage"
        }
    ],
    "meta": {
        "total_pages": 1,
        "total_results": 1,
        "page_number": 1,
        "page_size": 25
    }
}

Virtual Cross Connects (VXC) Coverage

In the case of virtual cross connect (VXC) there are two terminating endpoints to every single connection: a cloud provider endpoint and a Telnyx endpoint. As a result, it’s insufficient to simply perform the coverage check. For example, the above API response only indicates that one end of the VXC can be terminated at the Telnyx’s FR5 PoP. It provides no information about the other terminating endpoint. To that end, we offer a VXC coverage API (GET /v2/virtual_cross_connects_coverage) to augment the generic coverage API. Here are some common usage patterns of this API. Querying by fixing Telnyx endpoint

GET /v2/virtual_cross_connects_coverage?filter[location.pop]=CH1

The response to the above query shows all the possible cloud provider endpoints at which a VXC, whose one end is terminated at Telnyx CH1 PoP, can be terminated. Querying by fixing cloud provider endpoint

GET /v2/virtual_cross_connects_coverage?filter[cloud_provider]=aws&filter[cloud_provider_region]=us-east-1

The response to the above query shows all the possible Telnyx endpoints at which a VXC, whose one end is terminated at us-east-1 of AWS, can be terminated. Here is a sample response:

{
    "data": [
        {
            "cloud_provider": "aws",
            "cloud_provider_region": "us-east-2",
            "location": {
                "region": "AMER",
                "site": "ORD",
                "pop": "CH1",
                "name": "Chicago IL, US",
                "code": "chicago-il"
            },
            "available_bandwidth": [
                50
            ],
            "record_type": "virtual_cross_connects_coverage"
        }
    ],
    "meta": {
        "total_pages": 1,
        "total_results": 1,
        "page_number": 1,
        "page_size": 25
    }
}

The available_bandwidth is in Mbps.

Networks Configuration

Source: https://developers.telnyx.com/docs/network/networks.md

A network instance is a prerequisite for the creation of all other elements. Here is a sample request:

Request sample

Don’t forget to update YOUR_API_KEY here.

POST /v2/networks HTTP/1.1
Host: api.telnyx.com
Content-Type: application/json
Authorization: Bearer YOUR_API_KEY
Content-Length: 40

{
  "name": "my_first_virtual_network"
}

Here is a sample response:

{
    "data": {
        "created_at": "2024-07-17T15:19:10.640289Z",
        "id": "58b42010-de88-4d9b-a164-d0b8170100bc",
        "updated_at": "2024-07-17T15:19:10.640289Z",
        "name": "my_first_virtual_network",
        "record_type": "network"
    }
}

API reference is available here.

WireGuard Gateway Setup

Source: https://developers.telnyx.com/docs/network/gateways/wireguard-gateway.md

On naming convention: in the API Reference, certain legacy documentations, and the Mission Control Portal, WireGuard Gateways are referred to as “Wireguard Interfaces”. In this guide and all guides under the “Networking” collection, the term WireGuard Gateway is used consistently. The devices that connect to it are referred to as WireGuard Peers or simply Peers

Introduction

WireGuard Gateway (WGW) is an element to which peers can connect and form a VPN over the public internet. It’s built on top of the WireGuard implementation.

Creating a WGW

Step 1: Create a Network

Follow this guide.

Step 2: Check for Coverage

Follow this guide. Use filter[available_services][contains]=cloud_vpn to look for a desired site at which to deploy the WGW. ashburn-va is chosen for the subsequent steps.

Step 3: Create a WGW

Using the network created from Step 1 and the chosen region from Step 2, create the WGW. Once a WGW is created on a specific network, it cannot be “migrated” to another one; it needs to be recreated on the other network. Double check the correct network_id is used in the following API request.

POST /v2/wireguard_interfaces HTTP/1.1
Host: api.telnyx.com
Content-Type: application/json
Authorization: Bearer XXX
Content-Length: 115

{
  "network_id": "91446ee3-9f6a-49ed-8d9b-1bd3e1529324",
  "name": "wgw-08071029",
  "region_code": "ashburn-va"
}

It’s not yet ready to be used immediately after the creation since its status is provisioning.

{
    "data": {
        "name": "wgw-08071029",
        "status": "provisioning",
        "public_key": "XXX",
        "created_at": "2024-08-07T15:29:52.068774Z",
        "network_id": "91446ee3-9f6a-49ed-8d9b-1bd3e1529324",
        "enable_sip_trunking": false,
        "id": "b6a10cb9-6c1a-40bd-96e3-d4f8eb2bd6c5",
        "region_code": "ashburn-va",
        "updated_at": "2024-08-07T15:29:53.493104Z",
        "region": {
            "code": "ashburn-va",
            "name": "Ashburn VA, US",
            "record_type": "region"
        },
        "record_type": "cloud_vpn",
        "endpoint": "64.16.243.3:5107",
        "server_ip_address": "172.27.0.1/24"
    }
}

endpoint denotes the publicly routable IP to which peers will connect over the public internet.
server_ip_address is the private subnet range the WGW and peers will use with WGW occupying the first usable IP.

Step 4: Wait for Status Transition

The expected time for status to transition to provisioned is approximately 5 minutes. You can poll the WGW to check for status.

GET /v2/wireguard_interfaces/b6a10cb9-6c1a-40bd-96e3-d4f8eb2bd6c5 HTTP/1.1
Host: api.telnyx.com
Authorization: Bearer XXX

Creating Peers

In the following example, a peer is created for the WGW from the previous section.

POST /v2/wireguard_peers HTTP/1.1
Host: api.telnyx.com
Content-Type: application/json
Authorization: Bearer XXX
Content-Length: 102

{
    "name": "mbp-local-peer",
    "wireguard_interface_id": "b6a10cb9-6c1a-40bd-96e3-d4f8eb2bd6c5"
}

In the response, you are given the key pair with which to configure your peer. private_key is only given to you ONCE in the creation API response. It must be stored by you.

{
    "data": {
        "name": "mbp-local-peer",
        "public_key": "ZZZ",
        "last_seen": null,
        "created_at": "2024-08-07T15:45:13.569576Z",
        "id": "7fc4c14e-ff94-4a97-b156-35f1feeb29b8",
        "wireguard_interface_id": "b6a10cb9-6c1a-40bd-96e3-d4f8eb2bd6c5",
        "updated_at": "2024-08-07T15:45:13.922425Z",
        "record_type": "wireguard_peer",
        "private_key": "YYY"
    }
}

Simpler still, you may use the following API to obtain the conf file template.

GET /v2/wireguard_peers/7fc4c14e-ff94-4a97-b156-35f1feeb29b8/config HTTP/1.1
Host: api.telnyx.com
Authorization: Bearer XXX

After inserting the private_key, you can import the conf file on the peer.

# Telnyx CloudVPN config. Target OS: Linux

[Interface]
PrivateKey = YYY
Address = 172.27.0.2/32

[Peer]
PublicKey = XXX
AllowedIPs = 172.27.0.0/24
Endpoint = 64.16.243.3:5107
PersistentKeepalive = 1

[Interface] refers to the local peer.

PrivateKey should have the value returned in the private_key parameter.
Address is the next available IP in the subnet range. In this case, since this is the first peer, it gets the next IP after the WGW.

[Peer] refers to the WGW created previously.

PublicKey is that of the WGW
AllowedIPs is the network this peer has access to. See this excellent explanation.
Endpoint is the publicly exposed IP to which peers can connect
PersistentKeepalive is a default parameter that can be ignored.

Configuring Peers

With the conf file, you can import that onto the host. Here are the environment specific guides:

Use Cases

In this section, we introduce 3 use cases that WGW can accommodate by itself.

Use Case 1: Multi-Cloud Network

WGW can be used as a VPN concentrator server to facilitate traffic between peers. In the following example, we will construct this architecture.

Peer in Cloud A is an EC2 instance in AWS.
Peer in Cloud B is a Droplet in DigitalOcean.

It will be demonstrated that it’s extremely trivial to set up a “multicloud” network.

Peer in Cloud A

This EC2 instance runs an apache server but only allows inbound SSH traffic.

As a result, it’s unreachable from the public internet.

user@localhost ~ % ping 34.201.0.189
PING 34.201.0.189 (34.201.0.189): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
^C
--- 34.201.0.189 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
user@localhost ~ % curl 34.201.0.189
^C

However, it’s connected to the WGW we created earlier.

ubuntu@ip-10-10-11-10:~$ sudo wg show
interface: peer1
  public key: Jt1zAJD6W2BZgOwtUsNY2KrMO0oRfUmfAEZGNEUZKiQ=
  private key: (hidden)
  listening port: 33174

peer: XYy8e5EKtE1F0fwwMgr792/9noYs53uRZBX5O3XJ4Eg=
  endpoint: 64.16.243.3:5107
  allowed ips: 172.27.0.0/24
  latest handshake: 14 seconds ago
  transfer: 124 B received, 596 B sent
  persistent keepalive: every 1 second

Peer in Cloud B

Similarly, this Droplet instance runs an apache server but only allows inbound SSH traffic.

As a result, it’s unreachable from the public internet.

user@localhost ~ % ping 161.35.112.164
PING 161.35.112.164 (161.35.112.164): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
^C
--- 161.35.112.164 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
user@localhost ~ % curl 161.35.112.164
^C

However, it’s connected to the WGW we created earlier.

root@ubuntu-s-1vcpu-512mb-10gb-nyc1-01:~# sudo wg show
interface: peer2
  public key: eAvskX/cBw10DpxPPcvItsFcBr2meAKOVgwFjysZnF4=
  private key: (hidden)
  listening port: 33951

peer: XYy8e5EKtE1F0fwwMgr792/9noYs53uRZBX5O3XJ4Eg=
  endpoint: 64.16.243.3:5107
  allowed ips: 172.27.0.0/24
  latest handshake: 4 seconds ago
  transfer: 124 B received, 308 B sent
  persistent keepalive: every 1 second

Cross Cloud Boundary

Despite of the firewall rule configs in the respective environments, Peer 1 is able to talk to Peer 2 over the WireGuard subnet. From Peer 1

ubuntu@ip-10-10-11-10:~$ curl 172.27.0.3
<!DOCTYPE html>
<html>
    <head>
        <title>I am the Droplet Peer in DigitalOcean</title>
    </head>
</html>

From Peer 2

root@ubuntu-s-1vcpu-512mb-10gb-nyc1-01:~# curl 172.27.0.2
<!DOCTYPE html>
<html>
    <head>
        <title>I am the EC2 Peer in AWS</title>
    </head>
</html>

This is readily extensible to peers running web services in various environments.

Use Case 2: Private Access to Other Telnyx Services

If a WGW is created with enable_sip_trunking, the WGW will enable routing for all Telnyx public API endpoints.

On the peer config, additional routes are added under AllowedIPs.

[Interface]
PrivateKey = XXX
Address = 172.27.0.2/32

[Peer]
PublicKey = jSSaLXXVEzYUM8N8IM+65YuuScL+Sf2DytZCdLhFSGo=
AllowedIPs = 172.27.0.0/24, 64.16.250.10/32, 64.16.250.11/32, 64.16.250.13/32, 103.115.244.145/32, 103.115.244.146/32, 185.246.41.140/32, 185.246.41.141/32, 192.76.120.10/32, 192.76.120.11/32, 192.76.120.31/32, 64.16.226.0/24, 64.16.227.0/24, 64.16.228.0/24, 64.16.230.0/24, 64.16.248.0/24, 64.16.249.0/24, 50.114.144.0/21, 185.246.41.128/25, 103.115.244.128/25, 64.16.239.98/32, 64.16.239.39/32, 64.16.239.82/32, 64.16.224.44/32
Endpoint = 64.16.243.15:5016
PersistentKeepalive = 1

As a result, traffic between a connected peer to Telnyx API, SIP, and Storage services will flow through the WGW (172.27.0.1) onto the Telnyx network as demonstrated below.

user@localhost ~ % traceroute sip.telnyx.com
traceroute to sip.telnyx.com (192.76.120.10), 64 hops max, 40 byte packets
 1  172.27.0.1 (172.27.0.1)  6.708 ms  7.726 ms  7.133 ms
 2  *^C
user@localhost ~ % traceroute api-direct.telnyx.com
traceroute to api-direct.telnyx.com (64.16.224.44), 64 hops max, 40 byte packets
 1  172.27.0.1 (172.27.0.1)  7.673 ms  6.239 ms  6.488 ms
 2  *^C
user@localhost ~ % traceroute us-central-1.telnyxcloudstorage.com
traceroute to us-central-1.telnyxcloudstorage.com (64.16.239.39), 64 hops max, 40 byte packets
 1  172.27.0.1 (172.27.0.1)  6.885 ms  6.898 ms  6.621 ms
 2  * *^C
user@localhost ~ % aws s3api list-buckets --profile "*.telnyxcloudstorage.com" --endpoint-url https://us-central-1.telnyxcloudstorage.com
{
    "Buckets": [
        {
            "Name": "bucket1",
            "CreationDate": "2024-03-26T17:54:09.271000+00:00"
        },
        {
            "Name": "bucket2",
            "CreationDate": "2024-03-26T16:51:51.967000+00:00"
        },
        {
            "Name": "bucket3",
            "CreationDate": "2023-11-29T13:50:59.837000+00:00"
        }
    ],
    "Owner": {
        "DisplayName": "xxx",
        "ID": "xxx"
    }
}

This arrangement is extremely useful in the case where we have to lock down public routing in the event of an extreme DDoS attack.

Use Case 3: Cross-Region Network

The previous architecture can be extended to the following one.

In this example ---

Site A is Telnyx Ashburn
Site B is Telnyx Amsterdam
Cloud A is AWS
Cloud B is Digital Ocean

Traffic between the two peers ride the Telnyx backbone between Ashburn and Amsterdam. Coming Soon.

Other use cases

See Global IP (Coming Soon)
See Internet Gateway (IGW) Guide
See Private Wireless Gateway (PGW) Guide (Coming Soon)

Costs

MRC for each WGW instance is $10.
Connected Peers are free of charge.

API References

WGW
Peers

Linux Configuration

Source: https://developers.telnyx.com/docs/network/wireguard-peer-config/linux.md

Prerequisite

You come from here and have a .conf file ready.

Step 1: Install WireGuard

ubuntu@ip-10-10-11-10:~$ sudo apt install wireguard

Step 2: Bring up the Interface

Assuming the correct config file is located at /etc/wireguard/peer1.conf

ubuntu@ip-10-10-11-10:~$ sudo wg-quick up peer1
[#] ip link add peer1 type wireguard
[#] wg setconf peer1 /dev/fd/63
[#] ip -4 address add 172.27.0.2/32 dev peer1
[#] ip link set mtu 8921 up dev peer1
[#] ip -4 route add 172.27.0.0/24 dev peer1

Step 3: Validating and Testing

ubuntu@ip-10-10-11-10:~$ sudo wg show
interface: peer1
  public key: Jt1zAJD6W2BZgOwtUsNY2KrMO0oRfUmfAEZGNEUZKiQ=
  private key: (hidden)
  listening port: 43548

peer: XYy8e5EKtE1F0fwwMgr792/9noYs53uRZBX5O3XJ4Eg=
  endpoint: 64.16.243.3:5107
  allowed ips: 172.27.0.0/24
  latest handshake: 1 minute, 28 seconds ago
  transfer: 92 B received, 2.86 KiB sent
  persistent keepalive: every 1 second

If another peer is connected to the network, it should be pingable.

ubuntu@ip-10-10-11-10:~$ ping 172.27.0.3
PING 172.27.0.3 (172.27.0.3) 56(84) bytes of data.
64 bytes from 172.27.0.3: icmp_seq=1 ttl=63 time=25.8 ms
64 bytes from 172.27.0.3: icmp_seq=2 ttl=63 time=25.6 ms
64 bytes from 172.27.0.3: icmp_seq=3 ttl=63 time=25.5 ms
^C
--- 172.27.0.3 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 25.493/25.610/25.751/0.106 ms

Next Steps

WireGuard Gateway (WGW) Guide outlines many use cases that may be valuable to you.

macOS Configuration

Source: https://developers.telnyx.com/docs/network/wireguard-peer-config/macos.md

Prerequisite

You come from here and have a .conf file ready.

Step 1: Install WireGuard Client

From here, choose and install the macOS client.

Step 2: Create a Tunnel

“Import Tunnel(s) from File…”

“Activate”

At this point, it should show “Status: Active”

Step 3: Validating and Testing

A connected peer should be pingable.

user@macbook-pro wireguard % ping 172.27.0.3
PING 172.27.0.3 (172.27.0.3): 56 data bytes
64 bytes from 172.27.0.3: icmp_seq=0 ttl=63 time=35.006 ms
64 bytes from 172.27.0.3: icmp_seq=1 ttl=63 time=32.528 ms
64 bytes from 172.27.0.3: icmp_seq=2 ttl=63 time=33.376 ms
^C
--- 172.27.0.3 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 32.528/33.637/35.006/1.028 ms

Next Steps

WireGuard Gateway (WGW) Guide outlines many use cases that may be valuable to you.

Windows Configuration

Source: https://developers.telnyx.com/docs/network/wireguard-peer-config/windows.md

Prerequisite

You come from here and have a .conf file ready.

Step 1: Install WireGuard Client

From here, choose and install the Windows Installer.

Step 2: Create a Tunnel

“Import Tunnel(s) from File…”

“Activate”

At this point, it should show “Status: Active”

Step 3: Validating and Testing

You can try pinging to/from a connected peer. If that does not work you can also try to set up a barebones http server and hit it from the connected peer (or vice versa). An example barebones server in python:

import socket

SERVER_HOST = "0.0.0.0"
SERVER_PORT = 8000

server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
server_socket.bind((SERVER_HOST, SERVER_PORT))
server_socket.listen(1)

while True:
    client_connection, client_address = server_socket.accept()
    request = client_connection.recv(1024).decode()
    response = 'HTTP/1.0 200 OK\n\nIt works!'
    client_connection.sendall(response.encode())
    client_connection.close()

Run the server in one peer (python3 server.py - assuming you saved the above example in a file named server.py) and reach it with a client / browser from the other peer:

$ curl --location 'http://172.27.0.4:8000/'
It works!

Next Steps

WireGuard Gateway (WGW) Guide outlines many use cases that may be valuable to you.

Internet Gateway (IGW)

Source: https://developers.telnyx.com/docs/network/gateways/internet-gateway.md

This is a beta feature

Introduction

Internet Gateway (IGW) is an element that routes traffic between your Telnyx network and the internet. It is intended to be used with certain other elements.

Creating an IGW

Step 1: Create a Network

Follow this guide.

Step 2: Check for Coverage

Follow this guide. Use filter[available_services][contains]=public_internet_gateway to look for a desired site at which to deploy the IGW. frankfurt-de is chosen for the subsequent steps.

Step 3: Create an IGW

Using the network created from Step 1 and the chosen region from Step 2, create the IGW. Once an IGW is created on a specific network, it cannot be “migrated” to another one; it needs to be recreated on the other network. Double check the correct network_id is used in the following API request.

POST /v2/public_internet_gateways HTTP/1.1
Host: api.telnyx.com
Content-Type: application/json
Authorization: Bearer XXX
Content-Length: 125

{
  "network_id": "5647b6cf-b204-42d6-9c63-f2fd12253113",
  "name": "my_first_igw",
  "region_code": "frankfurt-de"
}

It’s not yet ready to be used immediately after the creation since its status is provisioning.

{
    "data": {
        "created_at": "2024-08-01T14:36:39.938006Z",
        "region_code": "frankfurt-de",
        "name": "my_first_igw",
        "network_id": "5647b6cf-b204-42d6-9c63-f2fd12253113",
        "id": "06d65677-f1aa-43b6-8a6c-4f1abfe93754",
        "status": "provisioning",
        "updated_at": "2024-08-01T14:36:41.497785Z",
        "record_type": "public_internet_gateway",
        "public_ip": "64.16.243.172"
    }
}

Step 4: Wait for Status Transition

The expected time for status to transition to provisioned is approximately 10 minutes. You can poll the IGW to check for status.

GET /v2/public_internet_gateways/{{igw_uuid}} HTTP/1.1
Host: api.telnyx.com
Authorization: Bearer XXX

Use Cases

Use Case 1: Pure play VPN

Internet Gateway (IGW) can be used with WireGuard Gateway (WGW) to create a simple VPN service.

Set up an IGW
Set up a WGW and a peer.
On the peer, amend its config with:
- DNS — choose your resolver. In the following example, 8.8.8.8 is chosen.
- AllowedIPs — append with 0.0.0.0/0 so that reachability is beyond the private subnet.

Here is an example config of the peer.

[Interface]
PrivateKey = XXX
Address = 172.27.0.2/32
DNS = 8.8.8.8

[Peer]
PublicKey = YYY
AllowedIPs = 172.27.0.0/24, 0.0.0.0/0
Endpoint = 64.16.243.7:5022
PersistentKeepalive = 1

Deactivate and reactivate your WireGuard tunnel. You should see the IGW’s public IP showing up when you query what your public IP is.

user@localhost ~ % dig -4 TXT +short o-o.myaddr.l.google.com @ns1.google.com
"64.16.243.172"

Use Case 2: IGW + Private Wireless Gateway (PWG)

Coming Soon.

Costs

The monthly recurring cost (MRC) for each instance of IGW is $50.
Traffic is not currently metered in beta phase. We will meter traffic in GA phase.

API References

Private Wireless Gateway (PGW)

Source: https://developers.telnyx.com/docs/network/gateways/private-wireless-gateway.md

Introduction

Private Wireless Gateway (PGW) is an element that routes traffic between a group of Telnyx SIMs and other network elements. Refer to this guide for more information on PGW.

Creating a PGW

Step 1: Create a Network

Follow this guide.

Step 2: Check for Coverage

Follow this guide. Use filter[available_services][contains]=private_wireless_gateway to look for a desired site at which to deploy the WGW. Currently, Ashburn, VA is the only supported site. We are working on making more sites available.

Step 3: Create a PGW

Once a PGW is created on a specific network, it cannot be “migrated” to another one; it needs to be recreated on the other network. Double check the correct network_id is used in the following API request.

POST /v2/private_wireless_gateways HTTP/1.1
Host: api.telnyx.com
Content-Type: application/json
Authorization: Bearer XXX
Content-Length: 115

{
  "network_id": "f09e6854-fdef-4581-b3bc-63c2008fc4b5",
  "name": "pgw-08160937",
  "region_code": "ashburn-va"
}

It’s not yet ready to be used immediately after the creation since its status is provisioning.

{
    "data": {
        "assigned_resources": [
            {
                "count": null,
                "record_type": "sim_card_group"
            }
        ],
        "created_at": "2024-08-16T14:37:47Z",
        "id": "2280aa63-b9b8-4d8a-867a-ff153e5ec422",
        "ip_range": "100.64.199.0/24",
        "name": "pgw-08160937",
        "network_id": "f09e6854-fdef-4581-b3bc-63c2008fc4b5",
        "record_type": "private_wireless_gateway",
        "region_code": "ashburn-va",
        "status": {
            "error_code": null,
            "error_description": null,
            "value": "provisioning"
        },
        "updated_at": "2024-08-16T14:37:47Z"
    }
}

Step 4: Wait for Status Transition

The expected time for status.value to transition to provisioned is approximately 15 minutes. You can poll the PGW to check for status.

GET /v2/private_wireless_gateways/2280aa63-b9b8-4d8a-867a-ff153e5ec422 HTTP/1.1
Host: api.telnyx.com
Authorization: Bearer XXX

Step 5: Attach a SIM Group

The PGW is of little use when there is no SIMs are attached to it. Individual SIM must be added to a SIM group which then can be attached to the PGW. This is easily accomplished on the Mission Control Portal. PGW will show the SIM group after a successful attachment.

{
    "data": {
        "assigned_resources": [
            {
                "count": 1,
                "record_type": "sim_card_group"
            }
        ],
        "created_at": "2024-08-16T14:37:47Z",
        "id": "2280aa63-b9b8-4d8a-867a-ff153e5ec422",
        "ip_range": "100.64.199.0/24",
        "name": "pgw-08160937",
        "network_id": "f09e6854-fdef-4581-b3bc-63c2008fc4b5",
        "record_type": "private_wireless_gateway",
        "region_code": "ashburn-va",
        "status": {
            "error_code": null,
            "error_description": null,
            "value": "provisioned"
        },
        "updated_at": "2024-08-16T15:08:15Z"
    }
}

Use Cases

In the following examples, abbreviations are consistently used for brevity.

PWG = Private Wireless Gateway
WGW = WireGuard Gateway
IGW = Internet Gateway
VXC = Virtual Cross Connect

Use Case 1: PWG + WGW

We will construct this architecture which is useful when

Traffic to and from SIMs needs to be segmented and private, and
They do not need high bandwidth connection back to your internal service.

In the following example

The connected device is an iPhone.
It only has access to the peers attached to the WGW; there exists no default route for them.
Internal Service Peer is a Droplet on DigitalOcean that runs an toy Apache web server.
Admin Peer is a local host.

Detailed WGW and Peer setup guide can be found here. On both peers, ensure that both the WGW subnet and the PGW subnet are on the AllowedIPs of the [Peer] config.

[Peer]
PublicKey = XXX
AllowedIPs = 172.27.0.0/24, 100.64.199.0/24
Endpoint = XXX
PersistentKeepalive = XXX

From the internal service peer, we can see there is a route to the iPhone.

root@ubuntu-s-1vcpu-512mb-10gb-nyc1-01:~# traceroute 100.64.199.1
traceroute to 100.64.199.1 (100.64.199.1), 64 hops max
 172.27.0.1  21.591ms  21.000ms  20.677ms
 *  *  *
 *  *  *
 *  *  *
 100.64.199.1  885.269ms  179.245ms  171.923ms

From the iPhone, it has access to the internal service peer.

Use Case 2: PWG + WGW + IGW

The above architecture lacks a crucial functionality --- internet reachability. Though a workaround can be constructed by using one of the peers as an exit node for all default traffic, it’s far better to attach an IGW to the network.

Follow the procedure outlined in this guide to set up an IGW on the same network. At this point, the iPhone has internet reachability in addition to the WGW subnet and the PGW subnet.

In the above screenshots,

the iPhone’s wifi is turned off
its “Default Gateway IP” is 100.64.199.1 which is that of the PGW
its “External IP” is 64.16.243.172 which is that of the IGW
it can ping google.com

Roundtrip ping time is high since in this example, the PGW is in Ashburn US while the IGW is in Frankfurt DE.

Use Case 3: PWG + WGW + IGW + VXC

Currently, the PWG + WGW + IGW + VXC combination only works when WGW, IGW, and VXC are at the Frankfurt Site. We are working on expanding the coverage so it will work universally across all Telnyx sites. In the case where the user’s internal services reside in a cloud provider, the architecture can be augmented yet again. In this case, a VXC can be attached to the network to accommodate this scenario. In the following example, we will establish

a VXC from AWS eu-central-1
an EC2 in AWS eu-central-1 running a toy Apache server.

For detailed VXC guide on AWS and other providers, please refer to this collection of guides

In AWS’s VPC, we can see the routes from Telnyx’s public APIs AND the SIMs’ private IP ranges are advertised and propagated.

This is also validated by the traceroute output from within the EC2 instance. Latency is high as expected since the EC2 is in Frankfurt while the device is attached to a PGW in Ashburn.

ubuntu@ip-10-10-11-9:~$ traceroute 100.64.199.1
traceroute to 100.64.199.1 (100.64.199.1), 64 hops max
 169.254.237.21  0.916ms  1.091ms  1.079ms
 169.254.69.2  0.911ms  0.827ms  0.816ms
 169.254.69.1  1.398ms  1.347ms  1.338ms
 100.100.100.1  1.833ms  1.782ms  1.769ms
 100.65.72.1  120.938ms  120.001ms  119.756ms
 64.16.254.219  119.999ms  119.879ms  119.924ms
 64.16.254.71  119.758ms  119.691ms  120.006ms
 *  *  *
 169.254.208.167  119.488ms  119.552ms  119.599ms
 172.22.25.82  120.438ms  120.072ms  119.640ms
 100.64.199.1  274.343ms  252.264ms  246.660ms

Lastly, validate the connection from the device to EC2. Since the EC2 runs a toy Apache server, open up the HTTP port 80 for the SIM subnet.

From the iPhone, the server is clearly accessible via private IP.

Costs

The monthly recurring cost (MRC) for each instance of PGW is $100.
Additional costs on SIM and data are applicable as well. Consult this guide for more detail.

API References

VXC Introduction

Source: https://developers.telnyx.com/docs/network/vxc/intro.md

This guide first gives an overview of the product’s availability, costs, and the general API structure. Subsequently, it branches into cloud provider specific guides. The reader should only concern themselves with the section about the cloud provider that’s relevant to their use case.

Coverage & Availability

Source: https://developers.telnyx.com/docs/network/vxc/coverage.md

Refer to the coverage API to ensure the desired resource is offered at the desired region.

Pricing

Source: https://developers.telnyx.com/docs/network/vxc/cost.md

You will be charged by Telnyx AND your cloud provider. Telnyx charges an MRC for each VXC instance according to the following schedule, which may change at our discretion according to the general T&C. We can neither interpret nor advise how your cloud provider may charge your account. Please consult your cloud provider’s documentation.

AWS

Virtual Cross Connects	Monthly Recurring Charge (USD)
50 Mbps	100
100 Mbps	125
200 Mbps	150
300 Mbps	175
400 Mbps	200
500 Mbps	225
1 Gbps	450

GCP

Virtual Cross Connects	Monthly Recurring Charge (USD)
50 Mbps	100
100 Mbps	125
200 Mbps	150
300 Mbps	175
400 Mbps	200
500 Mbps	225
1 Gbps	450

Azure

Virtual Cross Connects	Monthly Recurring Charge (USD)
50 Mbps	200
100 Mbps	250
200 Mbps	300
300 Mbps	400
400 Mbps	500
500 Mbps	600
1 Gbps	1000

VXC API

Source: https://developers.telnyx.com/docs/network/vxc/api.md

The API resource in question is /v2/virtual_cross_connects. The following group of parameters needs to be provided regardless of the cloud provider.

Parameter	Value
`network_id`	A VXC must be associated with a network. If no network exists on your account, you need to create one first.
`name`	Human readable text; something meaningful to you.

The rest of the parameters are cloud provider specific. Please consult the subsequent sections.

AWS Direct Connect

Source: https://developers.telnyx.com/docs/network/vxc/aws.md

Architecture

We will construct the following architecture:

Prerequisites

VPC

This step is performed on AWS.

⚠️ Note: Ensure the intended region is selected. In this example, we are using eu-central-1 as the region.

Parameter	Value
Resources to create	VPC only
IPv4 CIDR block	IPv4 CIDR manual input
IPv4 CIDR	RFC1918, e.g. 10.10.11.0/24
IPv6 CIDR block	No IPv6 CIDR block
Tenancy	Default

Virtual Private Gateway

This step is performed on AWS. Create and attach a virtual private gateway to the VPC created.

⚠️ Note: Ensure the intended region is selected. In this example, we are using eu-central-1 as the region.

⚠️ Note: Amazon default ASN value is 64512. You will need this value for VXC creation. Next, attach the virtual private gateway to the VPC created in the first step.

The state of the virtual private gateway will go from “Detached” to “Attaching” and finally “Attached”.

VPC Route Table

This step is performed on AWS.

Internet Gateway

This step is performed on AWS. This is optional. Create and attach an internet gateway to the VPC created.

Subnet

This step is performed on AWS. Assuming you don’t have a subnet setup — Choose the VPC created. Subnet CIDR block should be chosen from within the VPC block.

EC2

This step is performed on AWS. Assuming you don’t have an EC2 instance — spin one up in the same region. Assign the VPC and Subnet created previously. Enable public IP on the instance so you can ssh into it.

Account ID

This step is performed on AWS. ⚠️ You would need this number when you create the Telnyx VXC later.

Telnyx Network

This step is performed on Telnyx. If you don’t have a network created already, you may follow this guide to create one.

Procedure

Create a VXC resource

This step is performed on Telnyx.

request

POST /v2/virtual_cross_connects HTTP/1.1
Host: api.telnyx.com
Content-Type: application/json
Authorization: Bearer XXX
Content-Length: 286

{
    "network_id": "314ae4ed-04f0-4111-be40-240beb7fdcf0",
    "name": "xd-frankfurt-vxc-aws",
    "cloud_provider": "aws",
    "cloud_provider_region": "eu-central-1",
    "primary_cloud_account_id": "YYY",
    "bgp_asn": 64512,
    "bandwidth_mbps": 50
}

Parameter	Value
`cloud_provider`	`aws`
`cloud_provider_region`	Match what you selected on the AWS
`primary_cloud_account_id`	AWS account ID from the last step
`bgp_asn`	AWS’s bgp asn which is 64512
`bandwidth_mbps`	Chosen from available bandwidth of the VXC coverage API

Take note of the VXC id returned in the response.

Direct Connect

This step is performed on AWS. If you haven’t accepted the connection from your AWS account within 1 hour of the VXC creation, the VXC would be deleted and you will have to start over.

Enable Primary Connection

This step is performed on Telnyx. The connection must be enabled to be used.

request

PATCH /v2/virtual_cross_connects/:vxc_uuid HTTP/1.1
Host: api.telnyx.com
Content-Type: application/json
Authorization: Bearer XXX
Content-Length: 31

{
    "primary_enabled": true
}

At this point, the connection on AWS will show as “available”.

Virtual Interface

This step is performed on AWS. The connection created above needs to have an interface to which to connect.

Interface Parameters

Parameter	Value
Type	Private
Connection	Choose the Direct Connection you accepted previously.
Virtual interface owner	My AWS account
Gateway Type	Virtual Private Gateway and select the one you created in Prerequisite – AWS → Virtual Private Gateway
BGP ASN	63440 - Telnyx ASN
Your router peer IP - optional	`primary_telnyx_ip`
Amazon router peer IP - optional	`primary_cloud_ip`
BGP authentication key - optional	`primary_bgp_key`

Lastly you should see the following – the interface is “available”.

Validate Connection

This step is performed on AWS. ssh into your EC2 instance and either ping or traceroute to one of the IP in the route table of the VPC. You can see the route went over the VXC instead of the public internet.

Google Cloud Interconnect

Source: https://developers.telnyx.com/docs/network/vxc/gcp.md

Architecture

We will construct the following architecture on Google Cloud.

Prerequisites

VLAN Attachment

This step is performed on Google

Parameters:

“Partner Interconnect Connection”
“Set up unencrypted Interconnect”

“Network”: Choose the one you are connecting from
“Region”: Choose the one that there is a Telnyx PoP in proximity
“MTU”: 8896

Create a router or choose an existing one.

Telnyx Network

This step is performed on Telnyx. If you don’t have a network created already, you may follow this guide to create one.

Procedure

Create a VXC resource

This step is performed on Telnyx.

POST /v2/virtual_cross_connects HTTP/1.1
Host: api.telnyx.com
Content-Type: application/json
Authorization: Bearer XXX
Content-Length: 286

{
    "network_id": "a843547c-3f08-4a7e-8a4b-270c3ffb13f2",
    "name": "xd-frankfurt-vxc-gcp",
    "cloud_provider": "gce",
    "cloud_provider_region": "europe-west3",
    "primary_cloud_account_id": "xxxx/europe-west3/2",
    "bgp_asn": 16550,
    "bandwidth_mbps": 50
}

Activate Connection

This step is performed on Google.

“Peer ASN”: 63440 (Telnyx) “MD5 Authentication”: primary_bgp_key

Update BGP Peering

This step is performed on Telnyx. At this point, the connection is “Down”. We need to take the Google assigned GBP IPs and set them on the VXC.

Use the PATCH method.

primary_cloud_ip — “Cloud Router BGP IP” or “Remote IP” in the “Troubleshooting” page
primary_telnyx_ip — “BGP peer IP” or “Local IP”in the “Troubleshooting” page

PATCH /v2/virtual_cross_connects/:vxc_uuid HTTP/1.1
Host: api.telnyx.com
Content-Type: application/json
Authorization: Bearer XXX
Content-Length: 31

{
    "primary_enabled": true,
    "primary_cloud_ip": "169.254.131.250/29",
    "primary_telnyx_ip": "169.254.131.249/29"
}

At this point, on Google, it will show the “Status” as “Up”

Validate Connection

This step is performed on Google.

Under VPC networks, you should see the routes advertised over the cloud router created.
You can also ssh in one of your instances in the same network and perform a traceroute.

xxx@instance-20240503-154050:~$ traceroute sip.telnyx.com
traceroute to sip.telnyx.com (192.76.120.10), 30 hops max, 60 byte packets
* * *
100.65.72.1 (100.65.72.1)  4.393 ms  4.367 ms  4.349 ms
64.16.254.51 (64.16.254.51)  114.732 ms  114.715 ms  114.698 ms
64.16.247.105 (64.16.247.105)  114.903 ms  114.877 ms  114.860 ms
192.76.120.160 (192.76.120.160)  114.843 ms  114.825 ms  114.807 ms
sip.telnyx.com (192.76.120.10)  114.857 ms  114.064 ms  114.038 ms

Azure ExpressRoute

Source: https://developers.telnyx.com/docs/network/vxc/azure.md

Architecture

We will construct the following architecture.

Prerequisites

Create ExpressRoute Circuit

This step is performed on Azure.

Parameter	Value
Region	Choose the matching available region from the VXC coverage API
Port Type	Provider
Provider	Equinix
Peering location	matching available region from the VXC coverage API
Bandwidth	Choose the available bandwidth from the VXC coverage API
SKU	Standard

Choose the rest of the parameters at your own discretion.

At the end of this step, the “Provider status” should say “Not provisioned”.

Telnyx Network

This step is performed on Telnyx. If you don’t have a network created already, you may follow this guide to create one.

Procedure

Create a VXC resource

This step is performed on Telnyx.

request

POST /v2/virtual_cross_connects HTTP/1.1
Host: api.telnyx.com
Content-Type: application/json
Authorization: Bearer XXX
Content-Length: 286

{
    "network_id": "{{you network UUID}}",
    "name": "my-first-azure-vxc",
    "cloud_provider": "azure",
    "cloud_provider_region": "Frankfurt",
    "primary_cloud_account_id": "xxxxxx",
    "bgp_asn": 12076
}

Parameter	Value
`cloud_provider`	`azure`
`cloud_provider_region`	Choose the matching region from the ExpressRoute circuit
`primary_cloud_account_id`	”Service key” on the ExpressRoute created previously
`bgp_asn`	Azure’s bgp asn which is 12076

Take note of the following info in the response; you will need it later.

id
primary_cloud_ip
primary_bgp_key

Enable Primary Connection

This step is performed on Telnyx.

request

PATCH /v2/virtual_cross_connects/:vxc_uuid HTTP/1.1
Host: api.telnyx.com
Content-Type: application/json
Authorization: Bearer XXX
Content-Length: 31

{
    "primary_enabled": true
}

You must make sure the VXC status is provisioned before proceeding to the next step. You can poll the status using GET request on the specific VXC.

Azure Private Peering

This step is performed on Azure. “Provider status” must show “Provisioned” before performing this step.

Parameter	Value
Peer ASN	Telnyx’s BGP ASN which is 63440
Subnets	IPv4
IPv4 Primary subnet	Choose the /30 block that includes `primary_cloud_ip`
IPv4 Secondary subnet	Choose the next /30 block
VLAN ID	Choose any number from a valid VLAN range
Shared key	primary bgp key
Public IP address	Create new
Public IP address SKU	Standard

After saving, you may need to wait for some time before performing the next step.

At this point, you should see Telnyx IPs advertised in the result after you click into “View route table.”

At this point, you are all set. Perform the following steps only if you are trying to test things out before putting it into your own production environment.

Virtual Network

Parameters	Value
Region	Match that of the virtual network created from the previous step

Next, add a Gateway subnet. Keep all parameters as default.

Virtual Network Gateways

Parameters	Value
Name	Something meaningful to you
Region	Match that of the virtual network created from the previous step
Gateway type	Express Route
SKU	Standard
Virtual network	Choose the one created from the previous step
Public IP address	Create new
Public IP address SKU	Standard

The gateway creation will take a while; upward of 20 minutes. In the meantime, you can proceed to the following step.

Virtual Machines

Parameters	Value
Region	Match that of the virtual network created from the previous step

Parameters	Value
Virtual network	Choose the one created from the previous step

You can keep the rest default or choose at your discretion.

Add Gateway Connection

This step is performed on Azure. The Virtual Gateway you created must be successfully deployed before this step is performed.

Parameters	Value
Connection type	Express Route

Parameters	Value
Virtual network gateway	Choose the one created from the previous step
ExpressRoute circuit	Choose the one created from the previous step
Routing weight	0

Validate Connection

This step is performed on Azure. Ensure all of the following are successfully deployed:

ExpressRoute
Virtual network
Virtual network gateway & connection
Virtual machine

SSH into the VM and perform a traceroute to sip.telnyx.com and sip.telnyx.eu. You can see the next hop is the next hop indicated on the Azure Private Peering under the express route.

API Reference (Network)

Regions

List all Regions: List all regions and the interfaces that region supports

Networks

List all Networks: List all Networks.
Create a Network: Create a new Network.
Delete a Network: Delete a Network.
Retrieve a Network: Retrieve a Network.
Update a Network: Update a Network.
Delete Default Gateway.: Delete Default Gateway.
Get Default Gateway status.: Get Default Gateway status.
Create Default Gateway.: Create Default Gateway.
List all Interfaces for a Network.: List all Interfaces for a Network.

WireGuard Interfaces

List all WireGuard Interfaces: List all WireGuard Interfaces.
Create a WireGuard Interface: Create a new WireGuard Interface. Current limitation of 10 interfaces per user can be created.
Delete a WireGuard Interface: Delete a WireGuard Interface.
Retrieve a WireGuard Interfaces: Retrieve a WireGuard Interfaces.
List all WireGuard Peers: List all WireGuard peers.
Create a WireGuard Peer: Create a new WireGuard Peer. Current limitation of 5 peers per interface can be created.
Delete the WireGuard Peer: Delete the WireGuard peer.
Retrieve the WireGuard Peer: Retrieve the WireGuard peer.
Update the WireGuard Peer: Update the WireGuard peer.
Retrieve Wireguard config template for Peer: Retrieve Wireguard config template for Peer

Public Internet Gateways

List all Public Internet Gateways: List all Public Internet Gateways.
Create a Public Internet Gateway: Create a new Public Internet Gateway.
Delete a Public Internet Gateway: Delete a Public Internet Gateway.
Retrieve a Public Internet Gateway: Retrieve a Public Internet Gateway.

Virtual Cross Connects

List all Virtual Cross Connects: List all Virtual Cross Connects.
Create a Virtual Cross Connect: Create a new Virtual Cross Connect. For AWS and GCE, you have the option of creating the primary connection first and the secondary connection later…
Delete a Virtual Cross Connect: Delete a Virtual Cross Connect.
Retrieve a Virtual Cross Connect: Retrieve a Virtual Cross Connect.
Update the Virtual Cross Connect: Update the Virtual Cross Connect. Cloud IPs can only be patched during the created state, as GCE will only inform you of your generated IP once th…
List Virtual Cross Connect Cloud Coverage: List Virtual Cross Connects Cloud Coverage. This endpoint shows which cloud regions are available for the location_code your Virtual Cross Connect…

Global IPs

List all Global IPs: List all Global IPs.
Create a Global IP: Create a Global IP.
Delete a Global IP: Delete a Global IP.
Retrieve a Global IP: Retrieve a Global IP.
List all Global IP Allowed Ports: List all Global IP Allowed Ports
Global IP Assignment Health Check Metrics: Retrieve health check metrics for your Global IP assignments.
List all Global IP assignments: List all Global IP assignments.
Create a Global IP assignment: Create a Global IP assignment.
Delete a Global IP assignment: Delete a Global IP assignment.
Retrieve a Global IP assignment: Retrieve a Global IP assignment.
Update a Global IP assignment: Update a Global IP assignment.
List all Global IP Health check types: List all Global IP Health check types.
List all Global IP health checks: List all Global IP health checks.
Create a Global IP health check: Create a Global IP health check.
Delete a Global IP health check: Delete a Global IP health check.
Retrieve a Global IP health check: Retrieve a Global IP health check.
Global IP Latency Metrics: Retrieve latency metrics measured for your Global IPs.
List all Global IP Protocols: List all Global IP Protocols
Global IP Usage Metrics: Retrieve usage metrics for your Global IPs.
Global IP Assignment Usage Metrics: Retrieve usage metrics for your Global IP assignments.

Private Wireless Gateways

Get all Private Wireless Gateways: Get all Private Wireless Gateways belonging to the user.
Create a Private Wireless Gateway: Asynchronously create a Private Wireless Gateway for SIM cards for a previously created network. This operation may take several minutes so you can check the P…
Delete a Private Wireless Gateway: Deletes the Private Wireless Gateway.
Get a Private Wireless Gateway: Retrieve information about a Private Wireless Gateway.

⌘I

​Telnyx Compute: Network — Full Documentation

​Private Networks

​Network Overview

​Introduction

​API Concepts

​Coverage

​Networks

​Gateways

​WireGuard Gateways

​Internet Gateways

​Private Wireless Gateways

​Virtual Cross Connects

​Coverage

​Generic Coverage

​Querying by the desired product

​Querying by the desired product with a location constraint

​Querying by the desired location

​Virtual Cross Connects (VXC) Coverage

​Networks Configuration

​Request sample

​WireGuard Gateway Setup

​Introduction

​Creating a WGW

​Step 1: Create a Network

​Step 2: Check for Coverage

​Step 3: Create a WGW

​Step 4: Wait for Status Transition

​Creating Peers

​Configuring Peers

​Use Cases

​Use Case 1: Multi-Cloud Network

​Peer in Cloud A

​Peer in Cloud B

​Cross Cloud Boundary

​Use Case 2: Private Access to Other Telnyx Services

​Use Case 3: Cross-Region Network

​Other use cases

​Costs

​API References

​Linux Configuration

​Prerequisite

​Step 1: Install WireGuard

​Step 2: Bring up the Interface

​Step 3: Validating and Testing

​Next Steps

​macOS Configuration

​Prerequisite

​Step 1: Install WireGuard Client

​Step 2: Create a Tunnel

​Step 3: Validating and Testing

​Next Steps

​Windows Configuration

​Prerequisite

​Step 1: Install WireGuard Client

​Step 2: Create a Tunnel

​Step 3: Validating and Testing

​Next Steps

​Internet Gateway (IGW)

​Introduction

​Creating an IGW

​Step 1: Create a Network

​Step 2: Check for Coverage

​Step 3: Create an IGW

​Step 4: Wait for Status Transition

​Use Cases

​Use Case 1: Pure play VPN

​Use Case 2: IGW + Private Wireless Gateway (PWG)

​Costs

​API References

​Private Wireless Gateway (PGW)

​Introduction

​Creating a PGW

​Step 1: Create a Network

​Step 2: Check for Coverage

​Step 3: Create a PGW

​Step 4: Wait for Status Transition

​Step 5: Attach a SIM Group

​Use Cases

​Use Case 1: PWG + WGW

​Use Case 2: PWG + WGW + IGW

Telnyx Compute: Network — Full Documentation

Private Networks

Network Overview

Introduction

API Concepts

Coverage

Networks

Gateways

WireGuard Gateways

Internet Gateways

Private Wireless Gateways

Virtual Cross Connects

Coverage

Generic Coverage

Querying by the desired product

Querying by the desired product with a location constraint

Querying by the desired location

Virtual Cross Connects (VXC) Coverage

Networks Configuration

Request sample

WireGuard Gateway Setup

Introduction

Creating a WGW

Step 1: Create a Network

Step 2: Check for Coverage

Step 3: Create a WGW

Step 4: Wait for Status Transition

Creating Peers

Configuring Peers

Use Cases

Use Case 1: Multi-Cloud Network

Peer in Cloud A

Peer in Cloud B

Cross Cloud Boundary

Use Case 2: Private Access to Other Telnyx Services

Use Case 3: Cross-Region Network

Other use cases

Costs

API References

Linux Configuration

Prerequisite

Step 1: Install WireGuard

Step 2: Bring up the Interface

Step 3: Validating and Testing

Next Steps

macOS Configuration

Prerequisite

Step 1: Install WireGuard Client

Step 2: Create a Tunnel

Step 3: Validating and Testing

Next Steps

Windows Configuration

Prerequisite

Step 1: Install WireGuard Client

Step 2: Create a Tunnel

Step 3: Validating and Testing

Next Steps

Internet Gateway (IGW)

Introduction

Creating an IGW

Step 1: Create a Network

Step 2: Check for Coverage

Step 3: Create an IGW

Step 4: Wait for Status Transition

Use Cases

Use Case 1: Pure play VPN

Use Case 2: IGW + Private Wireless Gateway (PWG)

Costs

API References

Private Wireless Gateway (PGW)

Introduction

Creating a PGW

Step 1: Create a Network

Step 2: Check for Coverage

Step 3: Create a PGW

Step 4: Wait for Status Transition

Step 5: Attach a SIM Group

Use Cases

Use Case 1: PWG + WGW

Use Case 2: PWG + WGW + IGW