v2.5.0-rc2 HTTP3 "QUIC is not supported"

[chesskuo]

Welcome!

• Yes, I've searched similar issues on GitHub and didn't find any.
• Yes, I've searched similar issues on the Traefik community forum and didn't find any.

What did you do?

enable the experimental http3 on entryPoint 443 and use it on http router

What did you see instead?

I'm using https://http3check.net/ to check my website, but it show me

QUIC is not supported

HTTP/3 Check failed to establish a QUIC connection for all attempts made with the given endpoint. See the connection errors below for more information.

Attempted 4 connection(s).
Received packets for 4 connection(s).
Successful handshake for 2 connection(s).

I already check the response header, it had Alt-Svc: h3-29=":443"; ma=2592000,h3-34=":443"; ma=2592000,h3-32=":443"; ma=2592000.

Besides enable the experimental http3 in traefik.yml, what should I do anything else?

What version of Traefik are you using?

v2.5.0-rc2

What is your environment & configuration?

traefik.yml

experimental:
  http3: true

entryPoints:
  http:
    address: ":80"
  https:
    address: ":443"
    enableHTTP3: true

api:
  dashboard: true

accessLog:
  fields:
    names:
      StartUTC: drop

providers:
  file:
    directory: /etc/traefik/dynamic_conf
    watch: true

dynamic_conf/main.yml

http:
  routers:
    www-http:
      entryPoints:
        - http
      rule: "Host(`ctf.example.com`)"
      middlewares:
        - redirect-to-https
      service: ctfd

    www-https:
      entryPoints:
        - https
      rule: "Host(`ctf.example.com`)"
      service: ctfd
      tls: {}

  services:
    ctfd:
      loadBalancer:
        servers:
          - url: "http://ctfd:8000/"

  middlewares:
    redirect-to-https:
      redirectScheme:
        scheme: https
        permanent: true

tls:
  certificates:
    - certFile: /ca/fullchain.pem
      keyFile: /ca/privkey.pem

If applicable, please paste the log output in DEBUG level

No response

[jbdoumenjou]

Hi @chesskuo,

We tested your website to check http3 with Traefik and the result is that we support http3 but not QUIC.
If you don't have the sentence that says HTTP3 is supported, you probably need to open port 443 with UDP.

As the tool you mentioned is not very explicit, we can't know exactly what part is needed to be "QUIC compliant".
We may suppose it checks the Google QUIC compatibility without being sure.

Could you give more information?

[chesskuo]

@jbdoumenjou
Sir, thx for your reply.

In my docker-compose.yml, I already open TCP and UDP for 443 port at the same time, so the connection can upgrade to HTTP/3 correctly. If I just open TCP, the connection will not upgrade to HTTP/3, it just has alt-srv header.

According the tool checking my website (https://http3check.net/?host=ctf.nisra.net), it returned my website already had HTTP/3, but didn't support QUIC and showed some error msg about connection failed (QLog is at bottom).

And then I use this tool to check google.com, it doesn't show any error, so I think traefik maybe has some bug when creating QUIC connection. But actually, HTTP/3 is working perfectly on my site, so I really have no idea about it... HTTP/3 is based on QUIC, so I feel this situation is so weird.

[thematchless]

Hi everybody 🖖🏼

I tested the v2.5.0-rc2 as well and can confirm that the HTTP3Check will report that HTTP/3 is supported but shows no compatibility for QUIC.

@chesskuo how did you manage your TCP und UPD Port in your docker-compose.yml? I came across the following in the traefik documentation:

[chesskuo]

hey @thematchless

this is my docker-compose.yml:

version: '3.8'

services:
  traefik:
    image: traefik:v2.5.0-rc2
    container_name: traefik
    restart: always
    environment:
      - TZ=Asia/Taipei
    ports:
      - "80:80"
      - "443:443/tcp"
      - "443:443/udp"
    volumes:
      - ./conf:/etc/traefik
      - ./log:/var/log/traefik
      - ./ca:/ca
    networks:
      traefik:
        ipv4_address: 172.100.0.1

networks:
  traefik:
    name: traefik
    attachable: true
    ipam:
      config:
        - subnet: 172.100.0.0/24
          gateway: 172.100.0.254

It is not especially at all.
I am just forwarding TCP and UDP 443 to let http3 works.
According the docs you mentioned, I think it just talk about how is http3 working on traefik.
Setting enableHTTP3 in a TCP entrypoint, and then this TCP entrypoint will open a UDP at the same time.
So you cannot set this port for UDP, it will show you the port is been used.

[thematchless]

Thanks for the reply @chesskuo 🙇🏼‍♂️

That's exactly how I configured my system. But to be clear, that's just the Docker port mapping.
I was just wondering if you have made some more adjustments to traefik itself.

My understanding was that i have to configure multiple entrypoints:

• my old one for TCP Connections (like 443)
• one new explicit TCP Connection for UDP
• map both entrypoints two your router

Now with your docker-compose file i understand that the explicit enableHTTP3 flag is enabling 443/udp for traefik. I tried multiple configurations even with a different UDP Port than 443, but it traefik seems to use only 443 for HTTP/3 as you can see in the HTTP headers.

Would be nice to have the possibility to configure the HTTP/3 Port as mentioned in #8130

[chesskuo]

@thematchless

But on my setting, http3 could work besides the port 443.

This is a example for my site.
I opened port 8443 to enable http3 and worked perfectly.
You can also check it by yourself, my site is still online now.

I provide some my configs, maybe it can help you.

• docker-compose.yml

  ports:
    - "80:80"
    - "443:443/tcp"
    - "443:443/udp"
    - "8443:8443/tcp"
    - "8443:8443/udp"

• traefik.yml

  entryPoints:
    http:
      address: ":80"
    https:
      address: ":443"
      enableHTTP3: true
    https2:
      address: ":8443"
      enableHTTP3: true

• dynamic.yml

  http:
    www-https:
      entryPoints:
        - https
        - https2
      rule: "Host(`ctf.nisra.net`)"
      service: ctfd
      tls: {}

[fserve]

I can confirm this.

tested with curl -v https://http3check.net

header for https://http3check.net has:

alt-svc: quic=":443"; ma=2592000; v="43,46", h3-Q043=":443"; ma=2592000, h3-Q046=":443"; ma=2592000, h3-Q050=":443"; ma=2592000, h3-25=":443"; ma=2592000, h3-27=":443"; ma=2592000

header for my site with traefik 2.5.1 has:
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

[m00nwtchr]

I have this issue as well, for me browsers attempt to use HTTP/3 but fail with a HTTP 421 "Misdirected Request" error, and fall back to using HTTP/2.
HTTP3Check:

HTTP/3 Check failed to establish a QUIC connection for all attempts made with the given endpoint. See the  connection errors below for more information.

Attempted 4 connection(s).

Received packets for 4 connection(s).
Successful handshake for 2 connection(s).

[mradalbert]

Traefik 2.8.3 running from docker container.
Same issue here. Firefox seems to load traefik dashboard by HTTP3 just fine:

yet http3check.net reports missing QUIC:

It's interesting that handshake isn't done in the first RTT. But maybe it's my misunderstanding.

[m00nwtchr]

@mradalbert what's the response code on those requests? for me it shows http/3 even when it returns a 421 response, but the page is actually loaded over http/2 / tcp (as far as I can tell)

[mradalbert]

200 OK over HTTP3 on all requests

[mpl]

I'm seeing some dodgy stuff on https://http3check.net/ atm (it seems to ignore the port I give it on the advanced tab), so I don't fully trust it.
@chesskuo out of curiosity, what do you see when you test with https://geekflare.com/tools/http3-test ?

[mradalbert]

Same result, H3-29

[mradalbert]

This is my config

version: "3"
services:
  traefik:
    image: traefik:latest
    container_name: traefik
    restart: unless-stopped
    command:
      # Tell Traefik to discover containers using the Docker API
      - --providers.docker=true
      # Enable the Trafik dashboard
      - --api.dashboard=true
      # Set up LetsEncrypt
      - --certificatesresolvers.letsencrypt.acme.httpchallenge=true
      - --certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web
      - --certificatesresolvers.letsencrypt.acme.email=################
      - --certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json
      # Set up an insecure listener that redirects all traffic to TLS
      - --entrypoints.web.address=:80
      - --entrypoints.web.http.redirections.entrypoint.to=websecure
      - --entrypoints.web.http.redirections.entrypoint.scheme=https
      - --entrypoints.websecure.address=:443
      - --entrypoints.websecure.http3
      - --entrypoints.websecure.http3.advertisedPort=443
      - --experimental.http3=true
      # Set up the TLS configuration for our websecure listener
      - --entrypoints.websecure.http.tls=true
      - --entrypoints.websecure.http.tls.certResolver=letsencrypt
      - --entrypoints.websecure.http.tls.domains[0].main=########
      - --entrypoints.websecure.http.tls.domains[0].sans=*.########
    networks:
      - traefik-public
    ports:
      - 80:80
      - 443:443/tcp
      - 443:443/udp
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - certs:/letsencrypt
    labels:
      - "traefik.enable=true"
      - 'traefik.http.routers.traefik.rule=Host(`#########`)'
      - "traefik.http.routers.traefik.entrypoints=websecure"
      - "traefik.http.routers.traefik.tls.certresolver=letsencrypt"
      - "traefik.http.routers.traefik.service=api@internal"
      - 'traefik.http.routers.traefik.middlewares=strip'
      - 'traefik.http.middlewares.strip.stripprefix.prefixes=/traefik'

volumes:
  certs:
networks:
  traefik-public:
    external: true

[chesskuo]

Hello @mpl ,

When I used https://geekflare.com/tools/http3-test, I got the result same as @mradalbert.

[mpl]

Same result, H3-29

@mradalbert I don't get it. You're saying same result, but https://geekflare.com/tools/http3-test does not report any problem, it does not say that "QUIC is not supported", right? So to me it's not exactly the same result, wrt to what an innocent user might conclude when comparing the results from both these websites.

I am starting to suspect that the only reason that https://http3check.net/ is showing this (badly explained on their part) warning, is because they expect the server to implement higher (than 29) drafts of HTTP/3 (I think the latest is 34 as of now).
And seeing as traefik relies on https://github.com/lucas-clemente/quic-go (which indeed is at h3-29 atm) , I think it might just be a matter of waiting for quic-go to implement more recent versions of the drafts for the "warning" to go away from https://http3check.net/

But there's a couple more things I'm going to test before moving on.

[m00nwtchr]

Geekflare only tests for the presence of the alt-svc header, not whether a QUIC connection can actually be made. Tested this by disabling the udp port mapping in my docker compose, it still showed a successful test result.

[mpl]

Geekflare only tests for the presence of the alt-svc header, not whether a QUIC connection can actually be made. Tested this by disabling the udp port mapping in my docker compose, it still showed a successful test result.

That does not invalidate my suspicion, but good to know, thanks.

[mradalbert]

Caddy web server uses quic-go as well. Testing it against http3check.net would be valuable in narrowing down the issue.

[mpl]

@mradalbert or even simpler :-) :
I've just tested against a trivial Go server using quic-go , and I get results similar to what you all are observing.

package main

import (
	"net/http"

	"github.com/lucas-clemente/quic-go/http3"
)

type myhandler struct{}

func (mh myhandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
	w.Write([]byte("HELLO"))
}

func main() {
	http.Handle("/", myhandler{})
	http3.ListenAndServe(":443", "./cert.pem", "./key.pem", nil)
}

[mpl]

FYI to all, to sum up:

1. I'm not really worried about this being a traefik issue per-se, since we completely rely on quic-go
2. quic-go thinks it's just http3check.net being weird. And given that http3check is neither clear about what the problem is/are, nor do they have a public repo/bug tracker where we can give feedback, I'm inclined to rather give quic-go the benefit of the doubt for now.