Reverse-proxying to non-local target

I'm trying to move from an Apache2-based reverse-proxy setup to Traefik, and I've managed to move all but one of my services. The last remnant is an Okta.com domain configuration, which is by design external, and unfortunately I've yet to find the section in the documentation that would tell me how to reverse-proxy to an external target properly. Any help would be appreciated.

The idea here is not a Redirect, it is a full reverse proxy setup via services - not using Okta as an auth provider via traefik itself [though this could become a thing], no 3xx, no additional docker services (nginx, apache) handing more creative solutions.

I have not use this against something like okta, just legacy severs. Define the service using a dynamic file provider.

http:
  services:
    oldnbusted:
      loadBalancer:
        servers: 
        - url: http://legacy-server:8080
# your example might look like:
# a router defined in the dynamic file provide can use the service name okta, a docker router would use okta@file
    okta:
      loadBalancer:
        servers:
        - url: https://myorg.okta.com/auth/xyz

Unfortunately that's exactly what I did already, which is why I'm asking here.

This is an obviously edited version of what I have right now. Why it's not working is beyond me.

http:
  routers:
    auth:
      entryPoints:
        - websecure
      rule: "Host(`auth.x.y`)"
      service: newhotness
      tls:
        certResolver: "xy"
        domains:
          - main: "auth.x.y"

  services:
    newhotness:
      loadBalancer:
        servers:
          - url: https://newhotness.customdomains.okta.com/

Damn.

Looks okay in trafik logs and dashboard otherwise?

Do you get a response ?

Traefik itself doesn't look like it's throwing any error making the thing. It just (comparatively) doesn't work.

Admittedly the real way to set this up would be to point the DNS entry to okta services, but if I did that, I wouldn't be able to easily get the LetsEncrypt certs through port:80 and update them in the Okta dev console manually, which is why I've been using a Reverse Proxy setup instead.

As far as the Apache config is concerned, it's not even customised:

        ProxyRequests Off
        ProxyPreserveHost Off
        SSLProxyEngine on
        AllowEncodedSlashes NoDecode
        <Location />
                ProxyPass https://newhotness.customdomains.okta.com/
                ProxyPassReverse https://newhotness.customdomains.okta.com/
                ProxyPreserveHost On
                RequestHeader set X-Forwarded-Proto "https"
                RequestHeader set X-Forwarded-Port "443"
        </Location>

Mind you, it's also possible Okta is choking up because the SSL cert used by traefic for rproxying is different from the one they've been made aware of.

Traefik does not do this, which is probably the problem.

Managed to extract the certs into flat files, and the cert mismatch wasn't it. You're probably right, in which case, darn it.

Actually!

x509: certificate is valid for *.okta.com, okta.com, not hotness.customdomains.okta.com

I should have looked at the logs before, but this is an intriguing error, especially since the wildcard should be matching the customdomains.okta.com.

...did I find a bug here?

No a wildcard certificate is not recursive.

You'd need a wildcard cert matching *.customdomains.okta.com

Just curious what the final verdict was here. Is this simply not possible because of the issue that @cakiwi mentioned? Or might it be possible with an nginx setup?

I am looking to do something similar - i.e. reverse proxy to a remote server.

@shot

If you can proxy without doing a response rewrite then traefik will do it fine. Now that plugins have been released there may be one that can do this too. I haven't bothered to look, as all the software I use can be configured to work behind a reverse proxy properly.

1 Like