Just a follow up on this PR, we have been focusing somewhere else lately but we still want to bring middleware support for UDP, so reviewing and iterating on this PR will be prioritized after we release the next minor in the next two weeks, thanks for the patience.

unfortunately we couldn't get to this PR in time so we're updating its target release to the next major version, which should have a beta until end of Q4

unfortunately we couldn't get to this PR in time so we're updating its target release to the next major version, which should have a beta until end of Q4

Thank you for following up. It's been a while since the last commit, and I'll get around to rechecking this PR before the reviewing.

What is missing to get this into v3? Anything I can do to help?

Hello @ichxxx and @Olen , we're finally getting back to this and while discussing it internally we had a hard time to get a real use case for the included middleware.

I can definitely see benefits on having the middleware mechanism ready for UDP as well, specially if we manage to add plugins support outside HTTP, so anyone could write custom code. But before that happens we need a good justification to add this, in the form of a specific middleware that's required in a real use case.

Can you help us on by providing what was the use case that motivated you? (to contribute and / or require this contribution)
The more specific around the tooling, environment and use case the better.

My use case is using Traefik as a simple "firewall" (I know that is not what it is made for, but it has some advantages), as I am dockerizing basically everything.
So the middlewares that are most important to me are geoblocking and whitelisting so I can allow access to certain udp services from a limited number of sources.
By using traefik in front of the services, I don't need to expose the services directly on the host, and I can keep a simple, common config in docker-compose.yaml no matter what kind of service we are talking about.

I use Traefik to expose some udp services, but I don't want these services to be completely exposed except the ip I trust. In this case, ip allowlist are required. Of course, I could write the ip allowlist logic in each of these udp services, but it is a bit inelegant, and I think it should be done at the gateway layer.

Same as @ichxxx , I expose multiple UDP services via traefik. Including video game servers, vpn servers, and dns servers. Sometimes I need to configure a backend for a particular CIDR range and I agree that should be done at the gateway layer

Examples:
Many multiplayer games use UDP/DTLS for networking,:
https://partner.steamgames.com/doc/features/multiplayer/networking
https://github.com/ValveSoftware/GameNetworkingSockets
https://dev.epicgames.com/docs/game-services/p-2-p

Many vpn servers route traffic via UDP, including wireguard:
https://www.wireguard.com/protocol/#key-exchange-and-data-packets

DNS servers use UDP:
https://www.ietf.org/rfc/rfc1035.txt

@ddtmachado, same use-case like others have mentioned: I'm using docker for various services that use TCP and UDP, having Traefik plugins as a type of firewall would be very helpful and convenient!

Concrete examples would be game servers, or really any UDP-based service. Since these are public-facing, but usually meant to be limited to users from a specific region/country, having a firewall could help mitigate attacks from CH or RU for example. This is an actual threat to any public-facing service, and limiting who can access which services can eliminate a significant portion of recon/hacking attempts. The problem many times is that setting up a firewall that does this, and in such a granular way is not very easy. Having Traefik act as a firewall for all kinds of services, and not just HTTP would help a lot in this regard!

Oh this would be so great! I am trying to write a TCP and UDP middleware right now and just found out UDP routes had no middleware support :)

Just to add a real world example that is relevant only for UDP:

We are providing a RADIUS service (using Dockerized FreeRADIUS). State is only stored in an SQL database (which can be a cloud-based DBaaS or a centralized SQL cluster/Galera) while the actual RADIUS servers should be scaled horizontally as long as a proxy provides an entrypoint for the IP endpoint.

For security reasons, only specific Access Point IP ranges should be able to send RADIUS requests to the RADIUS server which means that a IPWhiteList middleware is needed.

This is a clear cut case for Traefik as the dynamic proxy entrypoint provider with IP white listing firewalling middleware.

Hi! Is there an expected version/date when this will be merged? I'd love to use UDP middlewares, as I'm currenty using this awesome middleware to shut down unused services. However, I'd love to use UPNP without having to first wake up the service using HTTP. Hopefully this adds to potential usecases that you have been looking for.
Cheers!

This would be really great if you are still looking at this! Lots of use cases on our side for our network/dns services.

Can this be priortized? At least for feature parity? Is there a reason this was dropped?

Hello,

Sorry for the delay, but we were focused on releasing Traefik v3.0, and UDP middleware was not part of the roadmap.

We are still interested in this feature, but to be able to review it the conflicts have to be fixed.

@ichxxx could you please fix the conflicts? (rebase it on the master branch)

Hello,

Sorry for the delay, but we were focused on releasing Traefik v3.0, and UDP middleware was not part of the roadmap.

We are still interested in this feature, but to be able to review it the conflicts have to be fixed.

@ichxxx could you please fix the conflicts? (rebase it on the master branch)

Okay, I will fix the conflict when I have time.

Hey @ichxxx,

Okay, I will fix the conflict when I have time.

Are you still interested in moving forward on this PR?

As @kevinpollet said, even if we are still interested in this feature, this PR was opened a long time ago, and because we were focused on other features, we have frozen it and it's now outdated with a lot of changes to bring before being in a reviewable status.

If the work seems too huge for you we propose to close this PR and allow you or another contributor to open a new one to tackle this topic.

We keep it open while waiting for your feedback, and once again please apologize again for the long time with no action on this PR.

Hey @ichxxx,

Okay, I will fix the conflict when I have time.

Are you still interested in moving forward on this PR?

As @kevinpollet said, even if we are still interested in this feature, this PR was opened a long time ago, and because we were focused on other features, we have frozen it and it's now outdated with a lot of changes to bring before being in a reviewable status.

If the work seems too huge for you we propose to close this PR and allow you or another contributor to open a new one to tackle this topic.

We keep it open while waiting for your feedback, and once again please apologize again for the long time with no action on this PR.

Sorry I don't have enough free time to rebase. There have been too many changes since the last commit. I'l close this PR first.

Hello @ichxxx,

Thank you for your feedback.

As I said previously, we are still interested in this feature, if you or another contributor want to move forward on this PR or open a new one on this topic, please let us know, and we will work with you to ensure you have all the information needed.