Teleport Agents on Dmz/Different subnets

[buzzzo]

HI

From what i've understand tls routing mode let teleport agent installed on lets say ServerA or ServerB and located in various subnet to initiated the connection to the port 443 of teleport server (proxy).
This let me think about some concerns regarding security when network segmentation is required and enforced.

For example, suppose we have serverA located on 192.168.0.0/24 and serverB located on 192.168.1.0/24.
subnet 192.168.0.0/24 and subnet 192.168.1.0/24 are both firewalled and can't talk each other ( so server A can't ssh to server B and viceversa)

By installing teleport agent on both server A and server B and let they reach the teleport proxy i would create a "virtual" hole in the network security because i could ssh via tsh from server a versus server b by using teleport server as proxy.
I know there is mfa/login etc etc (and even rbac) BUT this defeat the first goal of network segmentation: separate exposed public facing network (dmz) from internal network.

So Is there a way to:

1. let teleport proxy connect to the server a and server b (so the tunnel is initiated by teleport server and not by teleport agent). in this way i can't tsh ssh login to the teleport proxy and so each client (server a and server b) can't initiate ssh connection to each other.

EDIT:

After some research i've notice that the issue is mainly related to proxy mode, in which the teleport agent on serverA or serverB is started with:

proxy_server: xxx.yyy.zzz.www:443

So at least for ssh the issue could be mitigated by configuring teleport ssh agents on the dmz subnet with:
auth_server: xxx.yyy.zzz.www:3025

In this way by firewalling port 443 and open only 3025 the teleport tsh clients residing on the teleport agents (lets say server A and server B) can't be able to reach teleport proxy on 443 port.

So when started tsh ssh root@serverA from a clientB node the connnection flow is from clientB to serverA:3022.

I think this is by design but i've notice a caveat: if we would like to use on serverA for example a TCP App this would not possible without setting proxy_server on the teleport config on the serverA agent.

So if the issue could be mitigated for ssh this is not true for other general services, not mentioning the fact that deployment on new server in firewalled subnet will be impossible to be performed via the web ui because the 443 port is firewalled and then the installation script could not be executed on the endpoint where the teleport agent want to be installed.

Thx

[zmb3]

After some research i've notice that the issue is mainly related to proxy mode, in which the teleport agent on serverA or serverB is started with:
proxy_server: xxx.yyy.zzz.www:443

Correct, when you use proxy_server the agent dials out to the proxy, when you use auth_server the proxy dials the agent. (The latter is generally considered less secure, as you need to allow inbound traffic on port 3022)

I think this is by design but i've notice a caveat: if we would like to use on serverA for example a TCP App this would not possible without setting proxy_server on the teleport config on the serverA agent.

Also correct - this is by design. App access does not support direct dial and must dial via proxy. If you want to run a TCP app and SSH server on the same host, and you don't want the SSH server to tunnel, then you'd need to run two separate teleport processes on said host.

[buzzzo]

Thx for your answer

Correct, when you use proxy_server the agent dials out to the proxy, when you use auth_server the proxy dials the agent. (The latter is generally considered less secure, as you need to allow inbound traffic on port 3022)

True, but this means that if I let teleport agent reach the proxy i need to open anyway the 443 port of proxy to the server, and so let this server reach potentially every other server connected to teleport.
As I said, it's just a matter of protection given by network segmentation (built by firewall) vs protection built by teleport, but in the spirit of try to follow pure zero trust access and least privilege access philosophy i would like to eliminate any security hole.

Also correct - this is by design. App access does not support direct dial and must dial via proxy. If you want to run a TCP app and SSH server on the same host, and you don't want the SSH server to tunnel, then you'd need to run two separate teleport processes on said host.

One question: Assume hat I let server A dial with auth_server instead of proxy_server to the teleport server and so let ssh connection directly connectable via 3022 port on server a.

If teleport proxy is exposed externally on the internet with port 443 and some external client (web/tsh/connect whatever) try to connect on serverA once logged on the proxy: does this means that server A is not reachable because there isn't a tunnel between teleport proxy and teleport agent ? or anyway the proxy route internally the connection to serverA ?

This point is not clear.

Thx again

[stevenGravy]

Instead of connecting to the proxy web address agents can also connect to the tunnel address. Which you can choose to expose in your proxy service configuration.

Going through 443 you're using the tls routing feature in multiplex mode which reaches the tunnel through a single port. By exposing that tunnel address agents to go through by whatever dns routing (public/internal/peering) you choose. Please see the proxy service reference in the docs for details on tunnel listener and public tunnel address. The public tunnel dns address does not have to be a public Internet address, just reachable by the agent.

[buzzzo]

Thx

In this way from the external connecting to teleport.foobar.com:443 (for example) can i reach via tsh/connect the ssh agent configured in this way ?

[buzzzo]

I've some trouble finding the correct conf.

Is this (on the teleport server side)
tunnel_listen_addr: 0.0.0.0:3024
tunnel_public_addr: teleport.foo.bar:3024

And on the agent side should i point proxy_address to teleport.foo.bar:3024 ?

EDIT:

Need to change the proxy_lister_mode in auth service to "separate" in order to use port 3024 for reverse tunnel of the agent

Thx

[stevenGravy]

Yes right. Here's a issue that lists that and other options. #27885

[buzzzo]

Thx.

From what i've seen in this configuration i need to open to the outside also 3023 port, which is the ssh forwarding port (so I assume tsh ssh requests connect to 3023 and then they will be forwarded to the corresponding agents via reverse tunnels established on 3024.

To sumup:

1. without tls routing we need to open two ports to the outside to teleport proxy in order to let clients connects to resources: 443 and 2023
2. teleport agents need to connect to 3024 to teleport proxy in order to have reverse tunnel established , with no need to connect to 443 anymore

Thx for your invaluable help

[buzzzo]

One more question: is is possible to have 2 proxy: one on dmz (public exposed) and one internal ?

Thx

[stevenGravy]

You could. The agent will just need to be able to reach both on that reverse tunnel port with that internal address.

[buzzzo]

You could. The agent will just need to be able to reach both on that reverse tunnel port with that internal address.

Does it means that agent would discover automatically (with oss edition) the proxies and establish the reverse tunnel automatically on each proxy on port 3024 ?
I've seen there is the tunnel_strategy option that by default is mesh.