Inconsistent / missing registration & last IP

We have a Discourse installation, carried forward for several years but currently on the latest version (2.4.0beta2) using the latest Docker image, on a public IP address, no proxy or other things in front, LetsEncrypt certs.

Sometimes user registration IP and last IP works perfectly, sometimes it does not. I see no rhyme or reason. For example, here is a user created 7h ago, with nonsense addresses:

Another user created 17h ago is perfectly fine:

And so it goes, on some users it’s cool on some others it isn’t. Any ideas what’s going on here?

One thing that strikes me now that I look at it is that it could be that these users are coming in via IPv6, as I’ve never seen an IPv6 address in these fields. Does Discourse not understand IPv6? Does the Docker proxy not understand/pass through the relevant information? Something else?

Discourse definitely does, but you’d need to configure your server and whatever else is in front of it so that IPv6 is functional, etc.

IPv6 is very functional, and using the recommended Docker images setup with the web + data templates. There is nothing else in front. What is there we should tweak?

Mind you, out container yml has been around for a few years, although it includes the latest templates and the images themselves are rebuilt frequently. Is this something that might have changed along the way?

Looks like other people running the default docker setup have the same issue.

https://meta.discourse.org/t/why-are-my-301-redirects-not-working-ipv6-users-also-show-as-localhost/80442/9

Hard to say. I just audited the last ~8 new users who signed up at talk.commonmark.org which is a very default standard install and they all had valid IPv4 addresses for Last IP and Registration IP (sometimes the two differed, as well).

I know if user accounts come in through SSO or other unusual avenues that can affect the IPs reported there. Are all these users you are referring to regular signups through the standard new user signup dialog in Discourse?

1 Like

Were any of those addresses IPv6?

Nope, none of them were, but I don’t know if this colocation host even does IPv6.

Then I’m sure it won’t exhibit the problem of showing localhost instead of IPv6 addresses for users who come in over IPv6. Doesn’t mean the problem doesn’t exist.

Problem doesn’t exist on Discourse official hosting, at least, and that’s IPv6 capable. Nor do I see problems on a vanilla install at a random colocation host. Not sure what else to tell you, other than you didn’t answer my rather important question

Ah, yes, those are regular signups, no SSO or associated accounts.

I don’t doubt that it works in your hosting, but you don’t use the “standard” Docker setup that most users do, I think? I mean, I’m sure it’s possible for it to work given a proxy setting the right headers etc, the question is just if the default setup is doing that and, if not, if we can make it do so.

2 Likes

I’m pretty sure that you need to add a bit to your app.yml that tells nginx to recognize your ipv6 address and pass through the client address. I haven’t figured out how to do that yet myself, though. The topics about running a reverse proxy have ipv6 examples, which provide hints.

This is on my list of things to figure out, but I have a rather long list. I ended up disabling ipv6, I think because of this problem, but maybe due to some other ignorance of ipv6.

(Jeff you can get an ipv6 block routed, but you have to ask for it and then configure your hosts to use it.)

Meta is just a standard docker install + external reverse proxy and does IPv6 greatly:

image

Is there a section in your discourse.conf that tells it to set_real_ip with your IPv6 address, something like this?

    - replace:
        filename: /etc/nginx/conf.d/discourse.conf
        from: "types {"
        to: |
          set_real_ip_from 192.168.1.0/24;
          set_real_ip_from 172.18.0.0/24;
          set_real_ip_from 172.17.0.0/24;
          set_real_ip_from <SOME_IP_V6_ADDRESS_THING_HERE?>
          real_ip_recursive on;
          real_ip_header X-Forwarded-For;
          types {
1 Like

I think the external reverse proxy is the key - I don’t think this is solvable at all, or at least not easily, from just within the Docker container.

I’ve solved it now by having the Discourse Docker listen on a Unix socket and front it with a Caddy on the same machine (outside Docker). The Caddy setup is trivial, includes Let’s Encrypt, and now it works as expected for IPv6 as well.

forum.example.com {
  proxy / unix:/var/discourse/shared/web-only/nginx.http.sock {
    transparent
    websocket
  }
}
3 Likes