TCP Pass Through

Hello, I have a golang project that will terminate TLS and has support for h2c enabled.

This project is listening on :8080.

My fly.toml is:

[[services]]
  internal_port = 8080
  protocol = "tcp"

  [services.concurrency]
    hard_limit = 25
    soft_limit = 20

  [[services.ports]]
    port = "80"

  [[services.ports]]
    port = "443"

  [[services.tcp_checks]]
    interval = 10000
    timeout = 2000

Note that handlers = [“http”] and handlers = [“tls”, “http”] respectively are missing in this configuration. This is because in the fly documentation it is said that taking away the handlers implicitly passes through h2c traffic into your software. (https://fly.io/docs/reference/services/#tcp-pass-through)

Issue: Even though deploys go through successfully, my service never receives any traffic at all once deployed. I get: ERR_SSL_PROTOCOL_ERROR when making requests to my fly.dev URL which presumably is happening before any TCP traffic gets routed to my service.

Does anyone have advice for this scenario?

1 Like

Just to clarify, when you remove the tls handler we don’t do any SSL for you. So your application is receiving the raw, encrypted TCP stream. If you have a server with SSL setup this is probably what you want! If you do not, you will need to add the handlers = ["tls"] line in the port 443 service.

Hi kurt, thank you for the reply. This is not what I want. I would like my application to terminate TLS and be sent the raw TCP stream in order to do so. Does fly.io have this capability?

Ok cool! That’ll work just fine, but most apps like this have two internal ports (one for plaintext http and one for tls). What port is your app expecting TLS on?

(By the way, I’m super happy every time someone does this because it’s my favorite feature).

1 Like

Currently I have it only listening to 8080 for TLS. another random port is exposed for HTTP but i’m not using it. If it’s easier I can configure this piece as well

Give me a few to check on your app specifically.

1 Like

My most recent deployed version has explicit ports defined for TLS (8080) and http (9090) still getting the same ERR_SSL_PROTOCOL_ERROR without any activity in the logs of my service.

@kurt actually I may have spoken too soon, it looks like there is some activity in the logs on this deploy now… so this may have been the root issue! Thanks for your assistance

No worries! For what it’s worth, curl -v https://<app>.fly.dev makes it seem like the server isn’t doing the TLS handshake.

If you haven’t already, you might want to make the process listen on port 443 for SSL instead of 8080.

Interesting, it does look like an issue there. I just swapped it to listen to 443 and its still doing the same. I’ll keep adjusting the configuration on the service side and try to get it to click. Thanks again

@kurt got it to work, it’s a very cool feature!

Oh that’s great. Want to write an application guide for us? :smiling_imp:

I might be able to find some time for that! Would have been handy to have before I went down this rabbit hole, that’s for sure haha