Skip to content

Instantly share code, notes, and snippets.

@hivelogic2018

hivelogic2018/SSH TCP Ports.md

Last active September 5, 2025 11:24
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save hivelogic2018/e0105fd27454719aee305a4d1d1ba733 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save hivelogic2018/e0105fd27454719aee305a4d1d1ba733 to your computer and use it in GitHub Desktop.
Download ZIP
Wireguard (WG-Easy)
Raw
SSH TCP Ports.md

I thought the port 3024 is simply enough

sudo ufw allow 3024/tcp # the ssh tunnel for Forgejo users' code commits

sudo ufw allow 2222/tcp # for Forgejo:Git SSH access via port 2222

The reason you need to open both port 3024 and 2222 is that they serve two distinct purposes in your Teleport and Forgejo setup.

Port 3024: The Reverse Tunnel 🚇

  • Purpose: This port is used by other nodes or agents to establish a reverse tunnel back to the Teleport cluster. This is how a service like your Forgejo instance can securely connect to Teleport and become available to the cluster, even if it's behind a firewall or in a different private network.
  • [cite_start]Source of Information: Your traefik.yaml file defines an entry point for Teleport on address :3024, which is specifically for this reverse tunnel connection[cite: 5]. This allows external services to find and connect to your Teleport instance.
  • Analogy: Think of this as the "home base" or "control center" for your Teleport cluster. All the other services (the "agents") check in and register with it on this port.

Port 2222: The Git/SSH Proxy 💻

  • [cite_start]Purpose: This is the port your client-side git command is trying to connect to[cite: 6]. This port is a direct SSH proxy provided by Teleport. When you run git push --mirror, your SSH client tries to connect to git.infra.zingastay.com on port 2222, and Teleport intercepts that connection to handle authentication and routing to the correct service (Forgejo).
  • [cite_start]Source of Information: Your tmpl.teleport.yaml file explicitly shows the listen_addr for the proxy service is configured for 0.0.0.0:2222[cite: 1]. [cite_start]The git push error messages also confirm that the client is specifically trying to connect to git:2222[cite: 6].
  • Analogy: This is the "front door" for users and their Git clients. It is separate from the internal control channel used for agents and nodes to talk to the cluster.

You are correct that Traefik is not involved in this flow. [cite_start]The git command is an SSH connection, and Traefik is configured to handle HTTP/S traffic, not raw SSH[cite: 3, 4, 5]. Therefore, the SSH traffic on port 2222 must be allowed directly through your host's firewall to reach the teleport-server container, bypassing Traefik entirely.

Raw
update-response.md

Entire thread here: https://g.co/gemini/share/09a7d5751d12

You need the tokens section to automatically join new nodes to the Teleport cluster. The AUTH_INITIAL_TOKEN is the shared secret that validates a new node's connection.

What is AUTH_INITIAL_TOKEN?

The AUTH_INITIAL_TOKEN is a static join token. It's a secret key that a new Teleport node presents to the Teleport auth_service to prove it has permission to join the cluster. Without a valid token, the auth_service will reject the connection, preventing unauthorized nodes from joining.

Is It Necessary?

It is not strictly necessary to have a tokens block if you plan to add nodes to your cluster manually via tctl auth token add. However, for a fully automated, scalable infrastructure, it's considered essential or good-to-have.

Real Benefits

  1. Automation and Scalability: When you're provisioning new nodes with a script or a tool like Docker Compose, you don't want to manually issue a new token for each one. By including the static token in your teleport.yaml, new nodes can automatically join the cluster as soon as they start.
  2. Security: Static tokens help secure the initial join process. By using a secure token, you ensure that only your authorized nodes can connect to your cluster.
  3. Simplified Management: The token simplifies the management of a dynamic infrastructure. When a new node comes online, it joins the cluster without manual intervention, reducing the risk of human error and saving time.

Your teleport.yaml snippet is correct in its format, and you should uncomment and configure the tokens section to enable this behavior. Make sure to generate a long, random, and unguessable token for AUTH_INITIAL_TOKEN and keep it secure.

The --ttl flag with AUTH_INITIAL_TOKEN is a security measure. The token is designed for a one-time, automated join operation, not for continuous use. By giving it a short time-to-live (e.g., 24 hours), you limit the window of opportunity for an attacker to compromise it and use it to add a malicious node to your cluster. After a node successfully joins, it gets its own certificate and does not need the token again.

Accessing Tier 2 Resources with Teleport

You can still commit code to your Forgejo Git projects, a Tier 2 resource, using both the command-line interface (CLI) and VS Code's Git plugin. The key is to use Teleport's tsh CLI tool and your VPN to authenticate and establish a secure connection.

Here's how it works with the auth,node,proxy,app token flags:

  • --type=auth: For the Teleport Auth service.
  • --type=node: For the Teleport Node service (which handles SSH connections to servers). This is what you will use to connect to the server running Forgejo.
  • --type=proxy: For the Teleport Proxy service.
  • --type=app: For the Teleport Application service (which handles access to web apps like Forgejo). This is how you will access the Forgejo web UI.

Committing via CLI and VS Code

  1. Authenticate with Teleport: Before you can connect, you must log in to your Teleport cluster from your local machine using the tsh command.

    tsh login --proxy=teleport.infra.zingastay.com

  2. Access the Forgejo Git Repo: When you clone or push to the repository, you'll use the Teleport SSH proxy and your VPN.

    Using the CLI: Your local SSH configuration needs to be set up to use tsh as a proxy command. Once configured, you can use standard Git commands.

    # Clone the repository
git clone ssh://teleport-proxy:[email protected]:22/your-repo.git

# Push changes
git push

  3. VS Code Integration: The VS Code Git plugin uses the underlying Git and SSH configurations. Once your ~/.ssh/config is properly set up to use tsh for the git.infra.zingastay.com host, the VS Code plugin will automatically proxy its Git operations through Teleport. The user experience remains seamless—you simply push and pull as you normally would, but the connection is now secured and managed by Teleport.

The VPN is a necessary layer that ensures you're on a trusted network before the Teleport connection even begins, adding an extra layer of defense against unauthorized access to your sensitive resources.

https://g.co/gemini/share/5c923196e99a

Yes, I am with you on the updated diagram and your understanding of the architecture. The "before" in my previous response refers to the logical flow of security, not the strict chronological order of operations. The VPN establishes a secure, trusted network perimeter first, and then the Teleport connection authenticates your user and grants access to specific services within that trusted network.

1. Order of Operations: VPN and Teleport

The order is crucial: you must activate the WG-Easy VPN first, before attempting to log in to Teleport or access any Tier 2 resources.

Think of it like this: the VPN is the key to get you into the building (your private network). Teleport is the specific ID card that lets you into a particular room (your Forgejo server). You can't use your ID card to get into a room if you aren't already inside the building.

The correct order is:

  1. Activate your VPN connection. This places your machine on the trusted network where your services reside.
  2. Log in to Teleport with tsh login. This authenticates you and obtains your short-lived Teleport SSH certificate.
  3. Perform your Git commands. Now, your SSH client and VS Code can use the Teleport-issued certificate to access the Forgejo server securely.

2. How to Configure SSH for tsh

To make standard Git and SSH commands work with Teleport, you need to tell your SSH client to use tsh as a proxy. You do this by modifying your SSH configuration file, which is located at ~/.ssh/config.

  1. Open or create the ~/.ssh/config file in your home directory with a text editor.

  2. Add the following block to the file, replacing the hostnames with your own if they are different:

    Host git.infra.zingastay.com
    ProxyCommand C:/path/to/tsh.exe proxy --ssh -s %r@%h:%p
    IdentityFile none
    StrictHostKeyChecking no
    • Host: This defines a custom hostname that you will use in your Git commands. You can name this whatever you like (e.g., forgejo-git-teleport).
    • ProxyCommand: This is the most important part. It tells your SSH client to run the tsh proxy command to establish the connection instead of trying to connect directly. The path to tsh.exe may vary depending on your operating system.
    • IdentityFile none: This tells SSH not to use your standard private key. Teleport handles authentication with its own certificates.
    • StrictHostKeyChecking no: This is a convenience for now, but in a production environment, it is better to set this to yes to ensure you are connecting to the correct host.

3. How This Applies to VS Code

VS Code's Git plugin does not have its own, separate SSH configuration; it relies on your system's SSH settings. Once you have correctly configured your ~/.ssh/config file as described above, the VS Code Git plugin will automatically use it.

This means you can continue to use the integrated Git commands in VS Code's sidebar—the push, pull, and sync buttons will all work seamlessly and securely via Teleport.

No, the order of operations does not contradict. The key is to distinguish between accessing the WG-Easy web UI for configuration and using the WireGuard VPN itself to establish a network connection. Your updated access flow correctly outlines the former, while my previous response described the latter.

Here's a breakdown of the two distinct processes:

Process 1: Initial VPN Client Setup (via Teleport)

This is the process you described. It's a one-time setup to get a new VPN client.

  1. A user on a public internet connection goes to teleport.zingastay.com.
  2. They authenticate via Teleport.
  3. They access the WG-Easy web UI through the secure Teleport tunnel.
  4. They download their VPN configuration (.conf file or QR code).
  5. They close their browser. At this point, they are still on the public internet.

Process 2: Using the VPN to Access Tier 2 Resources

This is what happens after the client has been configured. This is the day-to-day workflow for accessing your sensitive services.

  1. The user activates the VPN client on their local machine. This establishes a direct, encrypted tunnel from their computer to your VPS, placing them on the private network.
  2. Now that they are on the trusted network, they can use tsh to log in to Teleport and get their SSH certificate.
  3. They use standard tools like Git or an SSH client to connect to the internal IP of your Forgejo server.
  4. The request passes through the VPN tunnel, is authenticated by Teleport, and then the connection is established.

So, while you initially configure the VPN through Teleport, you use the VPN itself to access all other services in front of Teleport. This creates a powerful layered security model. The VPN acts as the first line of defense and network gate, and Teleport acts as the second, identity-based layer of authentication and access control for the services themselves.

The process for accessing a UI-based Tier 2 resource like DbGate is conceptually the same as for Git/SSH, but you perform the steps within the application itself rather than in a terminal. The core principle remains: the VPN puts you on the private network, and then your local application can connect directly to the internal service.

Step-by-Step UI-Based Access

The flow for a client tool like DbGate is very straightforward once your VPN is active.

  1. Activate Your VPN: First, you must activate the VPN client (e.g., WireGuard) on your local machine. This establishes a secure tunnel, making your computer a virtual part of your private network. Your local machine can now "see" the private IP addresses of all your services.
  2. Open the Client Application: Open DbGate or any other database client on your local machine.
  3. Create a New Connection: In DbGate, create a new connection to your database.
  4. Enter Internal Credentials:
    • For the host, enter the internal IP address of your database container or service (e.g., 172.17.0.5).
    • For the port, enter the database's internal port number (e.g., 5432 for PostgreSQL).
    • Enter your database username and password.

Because your VPN is active, DbGate will successfully connect to the database via its internal IP, bypassing the public internet entirely.

The Role of Teleport vs. VPN

This setup highlights the distinct roles of Teleport and the VPN in your security model:

  • VPN: Provides network-level access. It acts as the gatekeeper, ensuring only trusted machines can connect to your private network. It’s a prerequisite for any connection to an internal resource.
  • Teleport: Provides identity-based access and authentication. You use Teleport's tsh command for SSH and application access to services configured to use it. For a database, the authentication is handled by the database's own user/password system.

In this model, the VPN is the first layer of defense, and the database's native authentication is the second. Your setup correctly keeps the database completely private and unreachable from the public internet.

That's an excellent and very important question. The security model for the UI-based access is different from the CLI-based one, but it is still secure because it relies on a layered approach. You are correct that the tsh authentication step is not part of the DbGate workflow.

The core difference is this: Teleport handles authentication for services that it is integrated with, such as SSH, Kubernetes, and web applications. A database, however, uses its own built-in authentication system.

Here's how the security works:

1. Network-Level Security (VPN)

The first layer of security is your VPN. The database service is completely hidden from the public internet. The only way to even attempt a connection is to first be on your trusted private network, which is only possible by activating the WireGuard VPN client. Without the VPN, the database's internal IP address is unreachable.

2. Application-Level Security (Native Authentication)

The second layer is the database's own authentication. When you connect with DbGate, you are prompted for a username and password . This authentication is handled entirely by the database server (PostgreSQL, MongoDB, etc.), not by Teleport. If you don't have the correct credentials, the connection will be rejected.

CLI Access vs. UI Access

  • CLI-based access (SSH): When you use tsh to connect to a server, Teleport acts as the identity provider for that server. It validates your identity and provides a temporary SSH certificate, so you don't need a static key pair.
  • UI-based access (DbGate): The DbGate application is not integrated with Teleport. It simply uses the network provided by the VPN to reach the database, and the database itself handles the authentication and authorization.

In both cases, you have a two-factor security model: a network factor (VPN) and an identity factor (either your Teleport identity or your database credentials). The VPN ensures that only trusted machines can connect to your network, and the credentials ensure that only authorized users can access the data.

UI-based access (DbGate): The DbGate application is not integrated with Teleport. It simply uses the network provided by the VPN to reach the database, and the database itself handles the authentication and authorization. << No, indeed I will have The DbGate application integrated with Teleport and served at dbgate.infra.zingastay.com though, feel free to update your guide/flow

You are absolutely right. Thank you for the clarification. My previous guide was based on the common model of using a desktop client. With your setup, where DbGate is integrated with Teleport's Application Access and served at dbgate.infra.zingastay.com, the flow is entirely different and even more secure. The VPN is not needed for this process.

Here is the updated, correct guide for UI-based access to your DbGate application.

Updated UI-Based Access Flow (Teleport Application Access)

This new flow aligns perfectly with your zero-trust principle, where Teleport is the single entry point. The security is handled by Teleport's authentication and proxying capabilities, not by the VPN.

  1. Initial Access and Authentication: A user navigates their browser to dbgate.infra.zingastay.com. This is a publicly exposed URL, but it's protected by your infrastructure.

    • The request goes to Traefik, which routes it to your Teleport container.
    • Teleport intercepts the request and handles the authentication and authorization. The user must log in to Teleport using your configured identity provider.

  2. Secure Tunneling: Once the user is successfully authenticated, Teleport establishes a secure, encrypted tunnel from the user's browser directly to the internal DbGate service.

  3. Application Access: The user is now able to use the DbGate web interface. The user's machine never directly accesses the database's internal IP. The connection is proxied and secured by Teleport.

Security Summary

The flow is secure for the following reasons:

  • No VPN Required: The VPN is for services that are not integrated with Teleport's Application Access (like your Git CLI). For DbGate, Teleport handles everything, eliminating the need for a separate VPN connection.
  • Zero-Trust: The user is authenticated by Teleport before they can even see the DbGate application. This verifies their identity and permissions at the network edge.
  • Single Public Entry Point: Your dbgate.infra.zingastay.com domain is protected by Teleport. All traffic is funneled through the Teleport proxy, which acts as a secure front door for your private applications.

Why not keep dbgate behind another layer of security like WG VPN ?

That's an excellent question that gets to the heart of a zero-trust architecture. You don't need to put the DbGate web UI behind both a VPN and Teleport because Teleport's Application Access effectively replaces the need for a VPN for that specific service.

Adding a VPN layer on top of Teleport for DbGate is redundant and creates a clunky, unnecessary user experience without a significant security benefit. Here's why:

  • Redundant Security: Both a VPN and Teleport provide secure, encrypted tunnels from the public internet to your private network. When you use Teleport's Application Access, it's already creating a secure, authenticated tunnel. Adding a VPN on top is like wearing two sets of body armor—it's overkill and makes movement difficult.
  • Poor User Experience: In your proposed scenario, a user would first have to turn on their VPN, then navigate their browser to dbgate.infra.zingastay.com, where they would be prompted to authenticate with Teleport. The elegance and simplicity of a single-step, identity-based access model are lost.
  • Zero-Trust Philosophy: The goal of a zero-trust model is to shift the security perimeter from the network to the user's identity. Your current setup achieves this perfectly:
    1. The VPN is used for services that require raw network access (like a terminal for the Git CLI).
    2. Teleport is used for services that are identity-aware and can be securely exposed to the public internet via its proxy (like the DbGate web UI).

By keeping DbGate accessible through Teleport's proxy, you maintain a single, strong entry point for all your web applications and only use the VPN for services where it's truly necessary.

You can learn more about how Teleport acts as a secure, zero-trust gateway for databases and other applications in this video about Teleport's database access. http://googleusercontent.com/youtube_content/0

only use the VPN for services where it's truly necessary. Good point. Then, besides Git cli (like Forgejo), what other Tier2 services should I use with VPN? are they only CLI-Based then?

You should use a VPN for any Tier 2 service that cannot be proxied by Teleport's Application Access. These services are typically managed via a CLI or a desktop client application that connects directly to an internal IP and port.

Here's a breakdown of common Tier 2 services that fit this description:

Database Clients (e.g., DbGate, PgAdmin, DBeaver)

  • Why a VPN is necessary: These applications are not web-based and don't typically support being proxied by a tool like Teleport. They are designed to connect directly to a database's private IP address and port (e.g., 10.8.0.x:5432). The VPN is the only way to make your computer a part of that private network, allowing the connection to succeed.

Docker CLI / API

  • Why a VPN is necessary: If you need to manage your Docker containers from your local machine using the docker CLI, you will need to be on the same private network as the Docker daemon. The VPN provides this network-level connectivity, allowing you to run commands like docker ps or docker compose up against a remote server.

Infrastructure Management (e.g., SSH, SCP, Rsync)

  • Why a VPN is necessary: For secure file transfers (scp, rsync) or for direct shell access to a server's private network interface, a VPN is essential. While Teleport can handle SSH proxying, there are scenarios where you might need direct network access for other tools.

Kubernetes Management (e.g., kubectl)

  • Why a VPN is necessary: If you're managing a Kubernetes cluster, the kubectl CLI tool needs to communicate with the cluster's API server. For security, this API server should only be accessible on a private network, and the VPN provides the necessary connectivity for this.

In short, the rule of thumb is: If the service has a public URL that can be routed through Teleport's Application Access, use Teleport. If it's a CLI-based tool or a desktop application that needs to connect directly to a private IP, use the VPN.

ah, I see. so, since dbGate has a public URL for its UI, use Teleport for routing it through Teleport's Application Access.

a desktop application like Duplicati running on a Daemon on my Ubuntu 24 VPS is perfect example to require an active VPN connection via WG.

Dokku shell script execution and Forgejo CLI git commands are another perfect examples. Elaborate about Dokku for deployment automation of Forgejo code projects then?

You've nailed it. A desktop application like Duplicati and CLI tools like the Git CLI and Dokku are perfect examples of services that benefit from a VPN, as they require direct, low-level network access to an internal IP address.

The Role of VPN in Dokku Deployment Automation

Dokku is a great example because its entire deployment model is built around SSH, which is a network-dependent protocol. Dokku simplifies the "git push to deploy" process, but that push is, at its core, an SSH operation.

Here's a breakdown of the Dokku workflow and why the VPN is essential:

  1. VPN Activates Private Network Access: When you turn on your WireGuard VPN, your local machine is assigned an IP address on your VPS's private network (e.g., 10.8.0.x). This is the key step. Your machine can now "see" and communicate with other private IPs on your VPS, including the one hosting Dokku.

  2. SSH for Dokku Commands: When you run a command like dokku apps:list or dokku logs myapp from your local machine, the Dokku CLI uses SSH to connect to the Dokku host. This connection goes from your local machine, through the VPN tunnel, to the Dokku server's private IP. The VPN makes this internal SSH connection possible.

  3. Git Push to Deploy: The git push command for Dokku is an SSH-based operation. When you run git push dokku master, Git attempts to connect via SSH to the dokku host. Your SSH configuration (which you set up for Teleport) can be configured to also work with the Dokku host, directing the connection through the VPN tunnel to the Dokku server's private IP. The Dokku daemon then receives the code and handles the build and deployment process.

In this model, your Forgejo instance hosts the source code repository, which you can push to using your secure Teleport credentials. Your Dokku instance handles the deployment itself. You use the VPN to connect to the Dokku server to initiate the deployment process, and Dokku pulls the code from your Forgejo instance.

This workflow showcases the two-pronged approach: one set of tools (DbGate, Dokku CLI) use the VPN for network access, while other tools (Git with Teleport) use Teleport's proxy for identity-aware access. It's a robust and secure way to manage your infrastructure.

well, I do see that Teleport has ssh-service, why should I use WG VPN then? isn't it a true VPN similar to WG?

ssh_service:

enabled: false

vs.

ssh_service:

enabled: "yes"

labels:

env: production

role: infra-host

?

Teleport's SSH service is not a true VPN. It's a secure access proxy that authenticates and authorizes users for SSH connections, but it does not create a network-level tunnel that places your computer on the remote private network. That's why you still need a VPN like WireGuard.

Teleport's ssh_service (Secure Gatekeeper)

When the ssh_service is enabled, Teleport acts as a secure gatekeeper for SSH access.

  • Authentication: It authenticates the user's identity using a short-lived certificate, eliminating the need for static SSH keys.
  • Authorization: It grants access to specific nodes based on a user's role and permissions.
  • Proxying: It proxies the SSH connection from the user's client to the target server.

The crucial point is that this access is service-specific. You are granted a secure connection to the SSH service on that node, but you are not on the node's private network. You cannot, for example, access a database's private IP address or manage Docker containers.

WireGuard VPN (Private Network Tunnel)

A VPN like WireGuard, on the other hand, creates a network-level tunnel.

  • Encrypted Tunnel: It establishes an encrypted connection between your computer and the remote private network.
  • Private IP Address: Your local machine is assigned a private IP on that network, making it a virtual member of the remote network.
  • Network Access: Once connected, your computer can reach any service on that network using its private IP address, not just SSH.

Why You Need Both

Think of it this way:

  • Teleport's ssh_service is like a VIP-access card for a single room (SSH). It gets you securely into that one room, but you can't go anywhere else in the building with just that card.
  • WireGuard VPN is like a private tunnel that takes you into the entire building's private parking garage. Once inside, you can go to any room you have the right key for (e.g., using a desktop client to access a database).

You need both because they serve different purposes:

  • Use Teleport for all identity-aware services that it can proxy (SSH, web apps).
  • Use a VPN for all services that require direct, low-level network access to an internal IP and port.
Raw
updated-flow.md

That's an excellent approach. This updated model creates a more secure, zero-trust architecture. Here are the updated text-based diagrams and a detailed explanation of the revised access flows.

Updated Flow Diagram

This diagram shows Teleport as the single, authenticated gateway. The WG-Easy UI is now an internal service, not directly accessible from the public internet.

+----------------+
| External Client|
+-------+--------+
        |
        | 1. Public HTTPS Request to Teleport (Port 443)
        v
+------------------------+
|   VPS Firewall         |
|   (Port 443 only)      |
+------------------------+
        |
        | 2. Request is routed to Traefik
        v
+------------------------+
| Traefik Reverse Proxy  |
| (Handles TLS, Routing) |
+-----------+------------+
            |
            | 3. Traefik routes the request to the Teleport container.
            v
+------------------------+
| Teleport Gateway       |
| (Publicly Accessible)  |
+-----------+------------+
            |
            | 4. User Authenticates with OIDC/SSO
            |    (e.g., Google, GitHub)
            v
+------------------------+
| Teleport Dashboard     |
| (Access Granted)       |
+-----------+------------+
            |
            | 5. User requests to connect to an internal host
            |    or service.
            v
+------------------------+
| Teleport Access Proxy  |
| (Secure Tunnel)        |
+-----------+------------+
            |
            | 6. Teleport securely proxies the connection to the internal service.
            |    This traffic is internal and not exposed to the public.
            |
            +------------------> Wireguard Host/Internal Service (e.g., WG-easy)
            |
            +------------------> Dokku/Forgejo Host
            |
            +------------------> Other Internal Hosts

Updated Access Flows

This new model simplifies the entry points and strengthens security by treating almost everything as an internal resource.

1. Initial Access to the Network

The first step is for a user to gain access to the private network. This is now done exclusively through Teleport.

  1. A user navigates their browser to teleport.zingastay.com from a public internet connection.
  2. The VPS firewall, which is now only open on port 443, accepts this request.
  3. Traefik receives the request and routes it to the Teleport container.
  4. Teleport handles the authentication process, using your configured identity provider.
  5. Once authenticated, the user is presented with the Teleport dashboard, where they can see the internal hosts they have permission to access.

2. Accessing and Managing WG-Easy

WG-Easy is now considered an internal service. A user cannot access its web UI directly from the internet. They must first authenticate via Teleport.

  1. From the Teleport dashboard, the authenticated user selects the host running the WG-Easy service (e.g., a host named vpn-server).
  2. Teleport's access proxy creates a secure, encrypted tunnel to that internal host.
  3. The user can then launch a web terminal or use SSH to connect to the internal server through this tunnel.
  4. From within this secure connection, they can use tools like curl to interact with the WG-Easy API or even open a forwarded port to access the WG-Easy web UI on their local machine.
  5. Once they have access to the WG-Easy UI (via the secure Teleport tunnel), they can create and manage Wireguard clients.

3. Accessing Other Internal Services

This same flow applies to all other internal services like Dokku, Forgejo, or Portainer. They are not exposed to the public internet. Access is always granted via the Teleport Access Proxy after successful authentication.

Why This is More Secure

This updated model aligns with the zero-trust security principle: "never trust, always verify."

  • Single Entry Point: Your infrastructure now has only one public-facing entry point—the Teleport gateway. All other services are completely hidden from the public internet.
  • Strong Authentication: Access is contingent on a robust authentication process via your identity provider, not just a shared password.
  • No Direct Exposure: Even if an attacker were to discover the IP address and port of your WG-Easy instance, they couldn't access it because it's not exposed to the public. It can only be reached through the authenticated and authorized Teleport tunnel.

This setup significantly reduces your attack surface and provides a more secure and manageable infrastructure.

Raw
wg-QnA.md

https://g.co/gemini/share/59a6b33b9082

How does one use Wireguard & WG-easy together with Teleport and Traefik on a cloudflare dns-01 challenge? I already have the latter part fully setup for RBAC and want to see the use / use cases of Wireguard and WG-Easy? and determine the necessity and workflow to incorporate them into my VPS infra setup. Give me flow diagram and access perimeters in your answer too.

Flow Diagram: Wireguard, Teleport, and Traefik

+----------------+
| External Client|
+-------+--------+
        |
        | 1. Connects to Wireguard VPN (UDP 51820)
        v
+------------------------+
|   VPS Firewall         |
|   (Ports 80, 443, 51820)|
+------------------------+
        |
        | 2. Traffic is routed to the VPN
        v
+------------------------+
| Wireguard VPN          |
| (Secure, Encrypted)    |
+-----------+------------+
            |
            | 3. Client is now on the private network.
            |    All traffic is internal.
            |
            +------------> Accesses WG-easy UI
            |              (via Traefik)
            |
            +------------> Accesses other internal services
            |              (e.g., App-1, Database)
            |
            | 4. User navigates to a domain (e.g., teleport.yourdomain.com)
            |    The request is directed to Traefik.
            v
+------------------------+
| Traefik Reverse Proxy  |
| (Handles TLS, Routing) |
+-----------+------------+
            |
            | 5. Traefik routes the request to the correct container.
            +---------------> Teleport Container
            |                  (Provides RBAC for SSH/Kubernetes)
            |
            +---------------> WG-easy Container
            |                  (Manages Wireguard Peers)
            |
            +---------------> Other Service Containers
                               (Your Apps)

ref: https://thuanbui.me/wirehole-ui-wireguard-vpn-server-dns-chan-quang-cao/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment