# Telnyx Edge: Network — Full Documentation > Complete page content for Network (Edge section) of the Telnyx developer docs (https://developers.telnyx.com). > Root index: https://developers.telnyx.com/llms.txt · Lightweight index for this subsection: https://telnyx-openapi-ng.s3.us-east-1.amazonaws.com/llms/edge/network.txt ## Edge Network ### Network > Source: https://developers.telnyx.com/docs/edge-compute/network.md # Network Private WireGuard-based mesh networking connecting your edge compute workloads, on-premise infrastructure, and cloud resources. Documentation coming soon. --- ## 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 1. There is a PoP in the vicinity from where you want to connect, and 2. 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](https://developers.telnyx.com/docs/network/coverage) 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](https://developers.telnyx.com/docs/network/networks) 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](https://developers.telnyx.com/docs/network/gateways/wireguard-gateway) 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](https://developers.telnyx.com/docs/network/gateways/internet-gateway) #### 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](https://developers.telnyx.com/docs/iot-sim/private-wireless-gateways) for more detail. ### Virtual Cross Connects It is a virtual direct connection between a supported cloud provider and Telnyx. Refer to [VXC guide](https://developers.telnyx.com/docs/network/vxc/intro) 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.* ```json 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: ```json { "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](/api-reference/networks/create-a-network). --- ### Wireguard Gateway Setup > Source: https://developers.telnyx.com/docs/network/gateways/wireguard-gateway.md On naming convention: in the [API Reference](/api-reference/wireguard-interfaces/list-all-wireguard-interfaces), 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](https://www.wireguard.com/) implementation. ## Creating a WGW ### Step 1: Create a Network Follow [this guide](https://developers.telnyx.com/docs/network/networks). ### Step 2: Check for Coverage Follow [this guide](https://developers.telnyx.com/docs/network/coverage). 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. ```bash # 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](https://github.com/pirate/wireguard-docs?tab=readme-ov-file#allowedips). * `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: * [Linux-like environment](https://developers.telnyx.com/docs/network/wireguard-peer-config/linux) * [macOS](https://developers.telnyx.com/docs/network/wireguard-peer-config/macos) ## 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. ![Multi Cloud Peers](/img/multi-cloud-peers.png) * 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. ![EC2 Peer](/img/ec2.png) As a result, it's unreachable from the public internet. ```bash 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. ```bash 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. ![Droplet Peer](/img/droplet.png) As a result, it's unreachable from the public internet. ```bash 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. ```bash 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 ```bash ubuntu@ip-10-10-11-10:~$ curl 172.27.0.3 I am the Droplet Peer in DigitalOcean ``` From Peer 2 ```bash root@ubuntu-s-1vcpu-512mb-10gb-nyc1-01:~# curl 172.27.0.2 I am the EC2 Peer in AWS ``` 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. ![Private Access](/img/private-access.png) 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. ![Cross Regional Network](/img/multi-site-network.png) 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](https://developers.telnyx.com/docs/network/gateways/internet-gateway) * 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](/api-reference/wireguard-interfaces/create-a-wireguard-interface) * Peers --- ### Linux Configuration > Source: https://developers.telnyx.com/docs/network/wireguard-peer-config/linux.md ## Prerequisite You come from [here](https://developers.telnyx.com/docs/network/gateways/wireguard-gateway) 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](https://developers.telnyx.com/docs/network/gateways/wireguard-gateway) 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](https://developers.telnyx.com/docs/network/gateways/wireguard-gateway) and have a `.conf` file ready. ## Step 1: Install Wireguard Client From [here](https://www.wireguard.com/install/), choose and install the macOS client. ## Step 2: Create a Tunnel "Import Tunnel(s) from File..." ![Import Tunnel(s) from File...](/img/create-tunnel.png) "Activate" !["Activate"](/img/activate.png) At this point, it should show "Status: Active" !["Active"](/img/activate-success.png) ## 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](https://developers.telnyx.com/docs/network/gateways/wireguard-gateway) 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](https://developers.telnyx.com/docs/network/gateways/wireguard-gateway) and have a `.conf` file ready. ## Step 1: Install Wireguard Client From [here](https://www.wireguard.com/install/), choose and install the Windows Installer. ## Step 2: Create a Tunnel "Import Tunnel(s) from File..." ![Import Tunnel(s)](/img/windows-import-tunnel.png) "Activate" ![Activate Tunnel](/img/windows-activate-tunnel.png) 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](https://developers.telnyx.com/docs/network/gateways/wireguard-gateway) 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](https://developers.telnyx.com/docs/network/networks). ### Step 2: Check for Coverage Follow [this guide](https://developers.telnyx.com/docs/network/coverage). 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. 1. Set up an IGW 2. Set up a WGW and a peer. 3. 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 * [IGW](/api-reference/public-internet-gateways/create-a-public-internet-gateway) --- ### 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](https://developers.telnyx.com/docs/iot-sim/private-wireless-gateways) for more information on PGW. ## Creating a PGW ### Step 1: Create a Network Follow [this guide](https://developers.telnyx.com/docs/network/networks). ### Step 2: Check for Coverage Follow [this guide](https://developers.telnyx.com/docs/network/coverage). 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 1. Traffic to and from SIMs needs to be segmented and private, and 2. They do not need high bandwidth connection back to your internal service. ![PWG + WGW Architecture](/img/pgw-wgw.png) 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](https://developers.telnyx.com/docs/network/gateways/wireguard-gateway). 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 1 172.27.0.1 21.591ms 21.000ms 20.677ms 2 * * * 3 * * * 4 * * * 5 100.64.199.1 885.269ms 179.245ms 171.923ms ``` From the iPhone, it has access to the internal service peer. ![Connection to Apache](/img/ping-apache-1.png) ### 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. ![PWG + WGW + IGW Architecture](/img/pgw-wgw-igw.png) Follow the procedure outlined in [this guide](https://developers.telnyx.com/docs/network/gateways/internet-gateway) 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. ![Deice Network Stats](/img/device-network-stats.png) ![Deice Internet Reachability](/img/internet-reachability.png) 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](https://developers.telnyx.com/docs/network/vxc/intro) ![PWG + WGW + IGW + VXC Architecture](/img/pgw-wgw-igw-vxc.png) In AWS's VPC, we can see the routes from Telnyx's public APIs AND the SIMs' private IP ranges are advertised and propagated. ![Route Table](/img/route-table.png) 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 1 169.254.237.21 0.916ms 1.091ms 1.079ms 2 169.254.69.2 0.911ms 0.827ms 0.816ms 3 169.254.69.1 1.398ms 1.347ms 1.338ms 4 100.100.100.1 1.833ms 1.782ms 1.769ms 5 100.65.72.1 120.938ms 120.001ms 119.756ms 6 64.16.254.219 119.999ms 119.879ms 119.924ms 7 64.16.254.71 119.758ms 119.691ms 120.006ms 8 * * * 9 169.254.208.167 119.488ms 119.552ms 119.599ms 10 172.22.25.82 120.438ms 120.072ms 119.640ms 11 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. ![EC2 Inbound Rule](/img/inbound-rule.png) From the iPhone, the server is clearly accessible via private IP. ![iPhone to Apache](/img/iphone-apache-fr.jpg) ## 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](https://developers.telnyx.com/docs/iot-sim/iot-pricing) for more detail. ## API References * [PGW](/api-reference/private-wireless-gateways/create-a-private-wireless-gateway) --- ### 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](/docs/network/coverage) 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](https://developers.telnyx.com/docs/network/networks) 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: ![AWS Architecture](/img/vxc-aws-architecture.png "AWS Architecture") ## Prerequisites ### VPC This step is performed on AWS. ![AWS VPC](/img/vxc-aws-vpc.png "AWS VPC") ⚠️ Note: Ensure the intended region is selected. In this example, we are using eu-central-1 as the region. ![AWS Create VPC](/img/vxc-aws-create-vpc.png "AWS Create VPC") | 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. ![AWS Virtual Private Gateway](/img/vxc-aws-virtual-private-gateway.png "AWS Virtual Private Gateway") ⚠️ Note: Ensure the intended region is selected. In this example, we are using eu-central-1 as the region. ![AWS Create Virtual Private Gateway](/img/vxc-aws-create-virtual-private-gateway.png "AWS Create Virtual Private Gateway") ⚠️ 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. ![AWS Attach Virtual Private Gateway](/img/vxc-aws-attach-virtual-private-gateway.png "AWS Attach Virtual Private Gateway") ![AWS Attach Virtual Private Gateway 2](/img/vxc-aws-attach-virtual-private-gateway-2.png "AWS Attach Virtual Private Gateway 2") 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. ![AWS VPC Route Table 1](/img/vxc-aws-vpc-route-table-1.png "AWS VPC Route Table 1") ![AWS VPC Route Table 2](/img/vxc-aws-vpc-route-table-2.png "AWS VPC Route Table 2") ![AWS VPC Route Table 3](/img/vxc-aws-vpc-route-table-3.png "AWS VPC Route Table 3") ### Internet Gateway This step is performed on AWS. This is optional. Create and attach an internet gateway to the VPC created. ![AWS Internet Gateway 1](/img/vxc-aws-internet-gateway-1.png "AWS Internet Gateway 1") ![AWS Internet Gateway 2](/img/vxc-aws-internet-gateway-2.png "AWS Internet Gateway 2") ![AWS Internet Gateway 3](/img/vxc-aws-internet-gateway-3.png "AWS Internet Gateway 3") ![AWS Internet Gateway 4](/img/vxc-aws-internet-gateway-4.png "AWS Internet Gateway 4") ![AWS Internet Gateway 5](/img/vxc-aws-internet-gateway-5.png "AWS Internet Gateway 5") ![AWS Internet Gateway 6](/img/vxc-aws-internet-gateway-6.png "AWS Internet Gateway 6") ### 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. ![AWS Subnet](/img/vxc-aws-subnet.png "AWS Subnet") ### 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. ![AWS EC2](/img/vxc-aws-ec2.png "AWS EC2") ### Account ID This step is performed on AWS. ⚠️ You would need this number when you create the Telnyx VXC later. ![AWS Account ID](/img/vxc-aws-account-id.png "AWS Account ID") ### Telnyx Network This step is performed on Telnyx. If you don't have a network created already, you may follow [this guide](https://developers.telnyx.com/docs/network/networks) to create one. ## Procedure ### Create a VXC resource This step is performed on Telnyx. ```http 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. ![AWS Direct Connect](/img/vxc-aws-direct-connect.png "AWS Direct Connect") ![AWS Direct Connect 2](/img/vxc-aws-direct-connect-2.png "AWS Direct Connect 2") ### Enable Primary Connection This step is performed on Telnyx. The connection must be enabled to be used. ```http 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”. ![AWS Enable Primary Connection](/img/vxc-aws-enable-primary-connection.png "AWS Enable Primary Connection") ### Virtual Interface This step is performed on AWS. The connection created above needs to have an interface to which to connect. ![AWS Virtual Interface 1](/img/vxc-aws-virtual-interface-1.png "AWS Virtual Interface 1") ![AWS Virtual Interface 2](/img/vxc-aws-virtual-interface-2.png "AWS Virtual Interface 2") 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”. ![AWS Interface Parameters](/img/vxc-aws-interface-parameters.png "AWS Interface Parameters") ### 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. ![AWS Validate Connection](/img/vxc-aws-validate-connection.png "AWS Validate Connection") --- ### Google Cloud Interconnect > Source: https://developers.telnyx.com/docs/network/vxc/gcp.md ## Architecture We will construct the following architecture on Google Cloud. ![GCP Architecture](/img/vxc-gcp-architecture.png "GCP Architecture") ## Prerequisites ### VLAN Attachment This step is performed on Google ![GCP VLAN Attachment](/img/vxc-gcp-vlan-attachment.png "GCP VLAN Attachment") Parameters: - "Partner Interconnect Connection" - "Set up unencrypted Interconnect" ![GCP VLAN Attachment Parameters](/img/vxc-gcp-attach-parameters-1.png "GCP VLAN Attachment Parameters") ![GCP VLAN Attachment Parameters 2](/img/vxc-gcp-attach-parameters-2.png "GCP VLAN Attachment Parameters 2") - "Network": Choose the one you are connecting from - "Region": Choose the one that there is a Telnyx PoP in proximity - "MTU": 8896 ![GCP VLAN Attachment Parameters 3](/img/vxc-gcp-attach-parameters-3.png "GCP VLAN Attachment Parameters 3") - Create a router or choose an existing one. ![GCP VLAN Attachment Parameters 4](/img/vxc-gcp-attach-parameters-4.png "GCP VLAN Attachment Parameters 4") ![GCP VLAN Attachment Parameters 5](/img/vxc-gcp-attach-parameters-5.png "GCP VLAN Attachment Parameters 5") ![GCP VLAN Attachment Parameters 6](/img/vxc-gcp-attach-parameters-6.png "GCP VLAN Attachment Parameters 6") ### Telnyx Network This step is performed on Telnyx. If you don't have a network created already, you may follow [this guide](https://developers.telnyx.com/docs/network/networks) 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. ![GCP Activate Connection](/img/vxc-gcp-procedure-1.png "GCP Activate Connection") ![GCP Activate Connection 2](/img/vxc-gcp-procedure-2.png "GCP Activate Connection 2") ![GCP Activate Connection 3](/img/vxc-gcp-procedure-3.png "GCP Activate Connection 3") “Peer ASN”: 63440 (Telnyx) “MD5 Authentication”: `primary_bgp_key` ![GCP Activate Connection 4](/img/vxc-gcp-procedure-4.png "GCP Activate Connection 4") ### 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. ![GCP Update BGP Peering 1](/img/vxc-gcp-update-bgp-peering-1.png "GCP Update BGP Peering 1") ![GCP Update BGP Peering 2](/img/vxc-gcp-update-bgp-peering-2.png "GCP Update BGP Peering 2") 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” ![GCP Update BGP Peering 3](/img/vxc-gcp-update-bgp-peering-3.png "GCP Update BGP Peering 3") ### 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. ![GCP Verify Connection](/img/vxc-gcp-verify-connection.png "GCP Verify Connection") ```bash xxx@instance-20240503-154050:~$ traceroute sip.telnyx.com traceroute to sip.telnyx.com (192.76.120.10), 30 hops max, 60 byte packets 1 * * * 2 100.65.72.1 (100.65.72.1) 4.393 ms 4.367 ms 4.349 ms 3 64.16.254.51 (64.16.254.51) 114.732 ms 114.715 ms 114.698 ms 4 64.16.247.105 (64.16.247.105) 114.903 ms 114.877 ms 114.860 ms 5 192.76.120.160 (192.76.120.160) 114.843 ms 114.825 ms 114.807 ms 6 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. ![Azure Architecture](/img/vxc-azure-architecture.png "Azure Architecture") ## Prerequisites ### Create ExpressRoute Circuit This step is performed on Azure. ![Azure Prerequisite 1](/img/vxc-azure-prerequisite-1.png "Azure Prerequisite 1") ![Azure Prerequisite 2](/img/vxc-azure-prerequisite-2.png "Azure Prerequisite 2") | 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. ![Azure Pre-requisite 3](/img/vxc-azure-prerequisite-3.png "Azure Pre-requisite 3") 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](https://developers.telnyx.com/docs/network/networks) to create one. ## Procedure ### Create a VXC resource This step is performed on Telnyx. ```http 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. ```http 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. ![Azure Private Peering 1](/img/vxc-azure-private-peering-1.png "Azure Pre-requisite 1") ![Azure Private Peering 2](/img/vxc-azure-private-peering-2.png "Azure Pre-requisite 2") ![Azure Private Peering 3](/img/vxc-azure-private-peering-3.png "Azure Pre-requisite 3") | 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. ![Azure Private Peering 4](/img/vxc-azure-private-peering-4.png "Azure Pre-requisite 4") At this point, you should see Telnyx IPs advertised in the result after you click into “View route table.” ![Azure Private Peering 5](/img/vxc-azure-private-peering-5.png "Azure Pre-requisite 5") 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 ![Azure Virtual Network 1](/img/vxc-azure-virtual-network-1.png "Azure Virtual Network 1") | Parameters | Value | |------------|------------------------------------------------------------------| | Region | Match that of the virtual network created from the previous step | Next, add a Gateway subnet. Keep all parameters as default. ![Azure Virtual Network 2](/img/vxc-azure-virtual-network-2.png "Azure Virtual Network 2") ### Virtual Network Gateways ![Azure Virtual Network Gateways 1](/img/vxc-azure-virtual-network-gateways-1.png "Azure Virtual Network Gateways 1") | 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 ![Azure Virtual Machines 1](/img/vxc-azure-virtual-machines-1.png "Azure Virtual Machines 1") | Parameters | Value | |------------|------------------------------------------------------------------| | Region | Match that of the virtual network created from the previous step | ![Azure Virtual Machines 2](/img/vxc-azure-virtual-machines-2.png "Azure Virtual Machines 2") | 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. ![Azure Add Gateway Connection 1](/img/vxc-azure-add-gateway-connection-1.png "Azure Add Gateway Connection 1") ![Azure Add Gateway Connection 2](/img/vxc-azure-add-gateway-connection-2.png "Azure Add Gateway Connection 2") | Parameters | Value | |-----------------|---------------| | Connection type | Express Route | ![Azure Add Gateway Connection 3](/img/vxc-azure-add-gateway-connection-3.png "Azure Add Gateway Connection 3") | 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. ![Azure Validate Connection](/img/vxc-azure-verify-connection.png "Azure Validate Connection") --- ## API Reference (Network) ### Regions - [List all Regions](https://developers.telnyx.com/api-reference/regions/list-all-regions.md): List all regions and the interfaces that region supports ### Networks - [List all Networks](https://developers.telnyx.com/api-reference/networks/list-all-networks.md): List all Networks. - [Create a Network](https://developers.telnyx.com/api-reference/networks/create-a-network.md): Create a new Network. - [Retrieve a Network](https://developers.telnyx.com/api-reference/networks/retrieve-a-network.md): Retrieve a Network. - [Update a Network](https://developers.telnyx.com/api-reference/networks/update-a-network.md): Update a Network. - [Delete a Network](https://developers.telnyx.com/api-reference/networks/delete-a-network.md): Delete a Network. - [Get Default Gateway status.](https://developers.telnyx.com/api-reference/networks/get-default-gateway-status.md): Get Default Gateway status. - [Create Default Gateway.](https://developers.telnyx.com/api-reference/networks/create-default-gateway.md): Create Default Gateway. - [Delete Default Gateway.](https://developers.telnyx.com/api-reference/networks/delete-default-gateway.md): Delete Default Gateway. - [List all Interfaces for a Network.](https://developers.telnyx.com/api-reference/networks/list-all-interfaces-for-a-network.md): List all Interfaces for a Network. ### WireGuard Interfaces - [List all WireGuard Interfaces](https://developers.telnyx.com/api-reference/wireguard-interfaces/list-all-wireguard-interfaces.md): List all WireGuard Interfaces. - [Create a WireGuard Interface](https://developers.telnyx.com/api-reference/wireguard-interfaces/create-a-wireguard-interface.md): Create a new WireGuard Interface. Current limitation of 10 interfaces per user can be created. - [Retrieve a WireGuard Interfaces](https://developers.telnyx.com/api-reference/wireguard-interfaces/retrieve-a-wireguard-interfaces.md): Retrieve a WireGuard Interfaces. - [Delete a WireGuard Interface](https://developers.telnyx.com/api-reference/wireguard-interfaces/delete-a-wireguard-interface.md): Delete a WireGuard Interface. - [List all WireGuard Peers](https://developers.telnyx.com/api-reference/wireguard-interfaces/list-all-wireguard-peers.md): List all WireGuard peers. - [Create a WireGuard Peer](https://developers.telnyx.com/api-reference/wireguard-interfaces/create-a-wireguard-peer.md): Create a new WireGuard Peer. Current limitation of 5 peers per interface can be created. - [Retrieve the WireGuard Peer](https://developers.telnyx.com/api-reference/wireguard-interfaces/retrieve-the-wireguard-peer.md): Retrieve the WireGuard peer. - [Update the WireGuard Peer](https://developers.telnyx.com/api-reference/wireguard-interfaces/update-the-wireguard-peer.md): Update the WireGuard peer. - [Delete the WireGuard Peer](https://developers.telnyx.com/api-reference/wireguard-interfaces/delete-the-wireguard-peer.md): Delete the WireGuard peer. - [Retrieve Wireguard config template for Peer](https://developers.telnyx.com/api-reference/wireguard-interfaces/retrieve-wireguard-config-template-for-peer.md): Retrieve Wireguard config template for Peer ### Private Wireless Gateways - [Get all Private Wireless Gateways](https://developers.telnyx.com/api-reference/private-wireless-gateways/get-all-private-wireless-gateways.md): Get all Private Wireless Gateways belonging to the user. - [Create a Private Wireless Gateway](https://developers.telnyx.com/api-reference/private-wireless-gateways/create-a-private-wireless-gateway.md): 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… - [Get a Private Wireless Gateway](https://developers.telnyx.com/api-reference/private-wireless-gateways/get-a-private-wireless-gateway.md): Retrieve information about a Private Wireless Gateway. - [Delete a Private Wireless Gateway](https://developers.telnyx.com/api-reference/private-wireless-gateways/delete-a-private-wireless-gateway.md): Deletes the Private Wireless Gateway. ### Public Internet Gateways - [List all Public Internet Gateways](https://developers.telnyx.com/api-reference/public-internet-gateways/list-all-public-internet-gateways.md): List all Public Internet Gateways. - [Create a Public Internet Gateway](https://developers.telnyx.com/api-reference/public-internet-gateways/create-a-public-internet-gateway.md): Create a new Public Internet Gateway. - [Retrieve a Public Internet Gateway](https://developers.telnyx.com/api-reference/public-internet-gateways/retrieve-a-public-internet-gateway.md): Retrieve a Public Internet Gateway. - [Delete a Public Internet Gateway](https://developers.telnyx.com/api-reference/public-internet-gateways/delete-a-public-internet-gateway.md): Delete a Public Internet Gateway. ### Virtual Cross Connects - [List all Virtual Cross Connects](https://developers.telnyx.com/api-reference/virtual-cross-connects/list-all-virtual-cross-connects.md): List all Virtual Cross Connects. - [Create a Virtual Cross Connect](https://developers.telnyx.com/api-reference/virtual-cross-connects/create-a-virtual-cross-connect.md): 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… - [Retrieve a Virtual Cross Connect](https://developers.telnyx.com/api-reference/virtual-cross-connects/retrieve-a-virtual-cross-connect.md): Retrieve a Virtual Cross Connect. - [Update the Virtual Cross Connect](https://developers.telnyx.com/api-reference/virtual-cross-connects/update-the-virtual-cross-connect.md): 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… - [Delete a Virtual Cross Connect](https://developers.telnyx.com/api-reference/virtual-cross-connects/delete-a-virtual-cross-connect.md): Delete a Virtual Cross Connect. - [List Virtual Cross Connect Cloud Coverage](https://developers.telnyx.com/api-reference/virtual-cross-connects/list-virtual-cross-connect-cloud-coverage.md): 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](https://developers.telnyx.com/api-reference/global-ips/list-all-global-ips.md): List all Global IPs. - [Create a Global IP](https://developers.telnyx.com/api-reference/global-ips/create-a-global-ip.md): Create a Global IP. - [Retrieve a Global IP](https://developers.telnyx.com/api-reference/global-ips/retrieve-a-global-ip.md): Retrieve a Global IP. - [Delete a Global IP](https://developers.telnyx.com/api-reference/global-ips/delete-a-global-ip.md): Delete a Global IP. - [List all Global IP Allowed Ports](https://developers.telnyx.com/api-reference/global-ips/list-all-global-ip-allowed-ports.md): List all Global IP Allowed Ports - [Global IP Assignment Health Check Metrics](https://developers.telnyx.com/api-reference/global-ips/global-ip-assignment-health-check-metrics.md) - [List all Global IP assignments](https://developers.telnyx.com/api-reference/global-ips/list-all-global-ip-assignments.md): List all Global IP assignments. - [Create a Global IP assignment](https://developers.telnyx.com/api-reference/global-ips/create-a-global-ip-assignment.md): Create a Global IP assignment. - [Update a Global IP assignment](https://developers.telnyx.com/api-reference/global-ips/update-a-global-ip-assignment.md): Update a Global IP assignment. - [Delete a Global IP assignment](https://developers.telnyx.com/api-reference/global-ips/delete-a-global-ip-assignment.md): Delete a Global IP assignment. - [Global IP Assignment Usage Metrics](https://developers.telnyx.com/api-reference/global-ips/global-ip-assignment-usage-metrics.md) - [List all Global IP Health check types](https://developers.telnyx.com/api-reference/global-ips/list-all-global-ip-health-check-types.md): List all Global IP Health check types. - [List all Global IP health checks](https://developers.telnyx.com/api-reference/global-ips/list-all-global-ip-health-checks.md): List all Global IP health checks. - [Create a Global IP health check](https://developers.telnyx.com/api-reference/global-ips/create-a-global-ip-health-check.md): Create a Global IP health check. - [Retrieve a Global IP health check](https://developers.telnyx.com/api-reference/global-ips/retrieve-a-global-ip-health-check.md): Retrieve a Global IP health check. - [Delete a Global IP health check](https://developers.telnyx.com/api-reference/global-ips/delete-a-global-ip-health-check.md): Delete a Global IP health check. - [Global IP Latency Metrics](https://developers.telnyx.com/api-reference/global-ips/global-ip-latency-metrics.md) - [List all Global IP Protocols](https://developers.telnyx.com/api-reference/global-ips/list-all-global-ip-protocols.md): List all Global IP Protocols - [Global IP Usage Metrics](https://developers.telnyx.com/api-reference/global-ips/global-ip-usage-metrics.md)