EXACTLY, i will keep poking around and trying different things. If I solve it i will def report back what it was that I did to fix it and what caused it, maybe it will help others.
I’d love to see you expand on this. I found this when trying to do this and got a bit lost. I thought you could do it automatically for all services but after looking more it seems maybe it’s on a per service basis? Is this what you found?
Where did you quote me from above? But yes, you need a separate oauth_proxy for each service, since each service needs a unique callback-url…
I read your other page on oauth_proxy again and you did make it clear it was for each service. That’s such a bummer you can’t do a single oauth_proxy for multiple Traefik frontends, it seems like it should be possible. I might do some more noodling on this, it’ll take way more time to figure out how to do it automagically instead of manually, but where’s the fun in that.
And here is where the quote is from.
Aah, nice, #1 and #2 are actually done now. I’ll update the recipe.
Yeah, no way around the per-service container - I just suck it up and create a oauth config for each service - gives me the opportunity to upload a nice logo for each one too (below)
Because if it is, when I access containers over http it only says the site returned no data instead of redirecting me.
Well, strictly traefik redirects inbound request for https://sonarr.example.com to oauth_proxy, which redirects again to http://sonarr (the address of the container in the swarm). So once the SSL connection is terminated by traefix, the rest of the transactions are unencrypted within swarm’s networking.
I followed the recipe without so much trouble although I had to use the “3.2” as file version to be able to run it with docker stack (I’m using docker version 1.18)
However I’m having problems accessing the services under traefik.
For example I tried to add an emby service using the recipe, and after running it, the traefik web shows the service. The problem is when I try to access it, as it seems that the ssl certificate is not being created and I receive a ERR_SSL_PROTOCOL_ERROR
When I take a look to the traefik log I can see the following:
msg="Unable to obtain ACME certificate for domains \"emby.gpulido.com\" detected thanks to rule \"Host:emby.gpulido.com\" : cannot get ACME client ACME challenge not specified, please select HTTP or DNS Challenge"
For the record: gpulido.com is my domain, and I have defined the subdomain emby.gpulido.com on my dns provider (namecheap). Also I created a rule on my firewall to nat all incoming network to the server local ip.
Also I replaced to gpulido.com in the traefik.toml
I don’t know if I’m missing something here.
@sconaway I’m not sure if I understand. Where I suppose to use example.com instead of gpulido com? On the traeffic toml? Or in the configuration of each service?
What I don’t get is how it can work then.
I have defined a DNS subdomain emby.gpulido.com and it points to my wan IP.
Also y have defined two NAT rules (one rule for 80 and one rule for 443) That rule forwards the request to my server where traefik is listening. This seems to work properly the problem is that the SSL certificates for emby.gpulido.com seems to be wrong (or not exist).
Given this scenario I still doesn’t understand how can it work if I change the domain to example.com
After reviewing the traefik documentation, It worked after adding the following to the [acme] section on the toml
entryPoint = “http”
I don’t know if that is right
It looks like traefik didn’t renew my letsencrypt certs. How can I force it to renew them? I can’t seem to find any way to do that.
Are you still using SNI validation? IIRC, LetsEncrypt turned that off due to exploitability, and I’m not sure they’ve got it fixed yet. Several of the geeks in the forums / discord have ended up migrating to DNS validation…
Anyone using Traefik in front of current releases of Home Assistant? I’m trying to use homeAssistant with Trusted Networks so that my local tablets don’t have to enter a password to get into the UI. Trusted networks depends on X-Forwarded-for being set by Traefik. It’s being set for the HTTPS requests, but not for the web socket requests. Sadly it seems that part of the authentication for the UI these days is web socket and so it fails:
2018-08-28 21:00:35 INFO (MainThread) [homeassistant.components.http.view] Serving / to 192.x.x.xx5 (auth: True)
2018-08-28 21:00:35 INFO (MainThread) [homeassistant.components.http.view] Serving /api/websocket to 10.x.x.x20 (auth: False)
Notice how the web socket request doesn’t have the 192 address like the Service / call. As a result my local clients on specified addresses have to authenticate still even though they shouldn’t.
I found a forum and it sounds like I might be out of luck:
Just wanted to see if anyone here had any luck? I tried all sorts of changes and no luck:-(. In that thread someone mentions switching to Kong, anyone familiar with Kong?
In the Traefik docker-compose.yml, the subnet 10.1.0.0/24 is specified for the network “public”… Is this supposed to represent the network that our keepalived VIP is on? I’m thinking it must since Traefik must receive HTTP/HTTPS on that network, but in your other examples your nodes are in 192.168.31.0/24 and 192.168.4.0/24 so I’m just confused parsing that out.
It would be extremely helpful if the diagram or documentation on the Design page laid out a set of example networks for your VM’s, external, etc and then all the examples used the same network scheme. It gets a little confusing as we’re all NATing a public interface to a private interface with a VIP, and then all the docker swarm networks behind that. I’m assuming from my router I just need to forward 80 and 443 to the VIP and all hostnames themselves get handled by traefik, oauth, and docker swarm.
Testing testing one two three (Testing discourse -> discord integration)
Does anyone know how to force traefik to renew certs?
I am forging ahead assuming the subnet for “public” ought to be my local network… However, traefik seems to be having a problem with lets encrypt using the internal DNS at 127.0.0.11… I’m not sure how to troublehsoot this:
level=error msg=“Unable to obtain ACME certificate for domains “example.com” : cannot get ACME client get directory at ‘https://acme-v02.api.letsencrypt.org/directory’: failed to get json “https://acme-v02.api.letsencrypt.org/directory”: Get https://acme-v02.api.letsencrypt.org/directory: dial tcp: lookup acme-v02.api.letsencrypt.org on 127.0.0.11:53: read udp 127.0.0.1:36152->127.0.0.11:53: i/o timeout”
Anyone run into this sort of issue before? Using curl I can hit that URL from the box itself, so connectivity is there… Has to be something with how the docker internal DNS is working.
Sorry about the delayed response here - can you show us your Docker .yml definition?