Proxy confusion

[treviser (Ermin Trevisan)]

@Whitestrake

TLS with CloudFlare is an interesting problem, particularly when combined with domain validation and Automatic HTTPS. You have DNS validation, though, so setting your site in CloudFlare to Full or Full (strict) SSL in the Crypto section should rectify the usual issues, if that’s the case.

I use Full strict SSL. I’m not sure if the Cloudflare credentials are properly propagated to Caddy which I have running as a systemd service on Ubuntu…but that’s another issue I should try to get clarified in a separate thread.

@Whitestrake

Specifically, any client that:

1. Sends a request to your server for a location that you have configured Caddy to:
   a. Proxy to Odoo, and;
   b. Forward the CF-Connecting-IP header in place of the remote placeholder, AND;
2. Does not actually supply a CF-Connecting-IP header (so, anyone other than CloudFlare themselves)

will leave Odoo with an empty X-Forwarded-For header, which may have strange results with IP workarounds enabled. This might happen if you “grey-cloud” the A record for (www.)gastrosoftware.ch in CloudFlare and begin sending clients directly to the origin, or if someone manually requests that address from your server. With everything correctly configured, it is still possible, but shouldn’t happen.

I have set the following for gastrosoftware.ch:

• A record gastrosoftware.ch points to the Caddy server with automatic TTL, Status DNS and HTTP Proxy
• CNAME record www as an alias for gastrosoftware.ch also with automatic TTL, Status DNS and HTTP Proxy
  Any other requests to the location gastrosoftware are not legit anyway.

But to understand you correctly, twanda.ch is another location which is not related to the other and therefore might well be served by Caddy on the same instance as it has specified a different X-Forwardefd-For-Header?

@Whitestrake

I have to admit I don’t know all the implications of the realip middleware since I don’t need it for any of my sites (I completely forgot it existed, actually ). From its description, it might actually make the header_upstream subdirective unnecessary. If it does, it’s a better idea not to bother with using CF-Connecting-IP.

It did never work if I remember it correctly, so I have realip commented out at the moment.

[Whitestrake (Matthew Fay)]

@treviser

But to understand you correctly, twanda.ch is another location which is not related to the other and therefore might well be served by Caddy on the same instance as it has specified a different X-Forwardefd-For-Header?

header_upstream isn’t a global directive. It will only work on requests that match the proxy it’s configured for. In your example Caddyfile, only gastrosoftware.ch, www.gastrosoftware.ch are set up this way.

You have not included a header_upstream directive in the www.twanda.ch, www.twanda.com, www.twanda.twanda.ch, twanda.twanda.ch block, so there will not be any header overrides (other than those specified by the transparent preset).

[treviser (Ermin Trevisan)]

OK, understood. So in that case I should at least see the proper visitor IP for twanda.ch in my Odoo logs, right? But this is not the case. In my Odoo logs I only see the local IP address of the Caddy server for all locations, Cloudflare or not.
It used to work before as I had Caddy and Odoo installed on the same server, but it does not anymore since I have installed Caddy on a dedicated server in my LAN.

[Whitestrake (Matthew Fay)]

@treviser

So in that case I should at least see the proper visitor IP for twanda.ch in my Odoo logs, right? But this is not the case. In my Odoo logs I only see the local IP address of the Caddy server for all locations, Cloudflare or not.

IP workarounds are definitely enabled in your Odoo configuration?

From your example Caddyfile, twanda.ch proxy backend will receive an X-Forwarded-For header (courtesy of the transparent preset), and if IP workarounds are enabled, Odoo should be using it.

[treviser (Ermin Trevisan)]

If I understand it correcly, this is done be setting proxy_mode = True in the Odoo configuration file (Odoo uses werkzeug) and that’s what I have done.
Can it be something with the local net? My servers are in a virtual private cloud on amazon in 2 different subnets.

[Whitestrake (Matthew Fay)]

Try proxy_mode = 1?

Only other way I can find is to add the --proxy-mode paramater to the command used to run it.

[treviser (Ermin Trevisan)]

According to the official documentation and many other sources proxy_mode = True should be correct.

[Whitestrake (Matthew Fay)]

Ehh, it was a long shot anyway. I only found one source that suggested it, not official. Figured it was worth a shot. The --proxy-mode parameter is one official method, though, as far as I can tell. I have to apologise as I’m not familiar with the software.

I’m afraid I’m out of ideas after that point. Might be worth swapping in Apache or nginx with one of the example configs people have posted for Odoo and see if the problem persists, to try and eliminate or narrow it down to a Caddy-specific problem.

[treviser (Ermin Trevisan)]

Sorry for the late response, but as an active member of www.vikinger.ch I was busy casting out wintertime
Is there a way to see/log what caddy forwards to the backend?