0

My network flow looks like this:

Public Client
     ∟--> CDN Reverse Proxy (Cloudflare) - ONLY used for HTTP/S traffic, all else goes direct
          ∟--> Cloud Server w/ firewalld forwarding 
               ∟--> Private Server  
                         ∟--> Docker Reverse Proxy (Traefik) 
                                   ∟--> Docker Containers
                                   ∟--> Docker Reverse Proxy (NGINX) 
                                            ∟--> Docker Containers

I'm trying to get the Public Client's IP to show up in the logs files of the various docker containers, but they only log the docker network address of the applicable docker reverse proxy.

To further complicate things, I am forwarding a combination of TCP and UDP traffic, and not all of the traffic is HTTP/S. I mainly want the source IP coming through so that I can take advantage of rate limiting and blocking.

Is this configuration ungodly complicated? Yes. Does it somehow all work shockingly well? Yes! Except for the elusive logging of the true source's IP...

The Cloud Server's firewall is configured with the following commands:

echo 'net.ipv4.ip_forward = 1' >> /etc/sysctl.conf
sysctl -p
# Enable masquerade on the VPN client address
sudo firewall-cmd --add-rich-rule "rule family=ipv4 destination address={Private Server Private IP]/32 masquerade" --permanent
# These rules receive traffic coming into the server's main ipv4 address - web 
sudo firewall-cmd --add-rich-rule "rule family=ipv4 destination address={Cloud Server Public IP]/32 forward-port port=80 protocol=tcp to-port=80 to-addr={Private Server Private IP]" --permanent
sudo firewall-cmd --add-rich-rule "rule family=ipv4 destination address={Cloud Server Public IP]/32 forward-port port=443 protocol=tcp to-port=443 to-addr={Private Server Private IP]" --permanent
sudo firewall-cmd --add-rich-rule "rule family=ipv4 destination address={Cloud Server Public IP]/32 forward-port port=25 protocol=tcp to-port=25 to-addr={Private Server Private IP]" --permanent
sudo firewall-cmd --add-rich-rule "rule family=ipv4 destination address={Cloud Server Public IP]/32 forward-port port=143 protocol=tcp to-port=143 to-addr={Private Server Private IP]" --permanent
sudo firewall-cmd --add-rich-rule "rule family=ipv4 destination address={Cloud Server Public IP]/32 forward-port port=465 protocol=tcp to-port=465 to-addr={Private Server Private IP]" --permanent
sudo firewall-cmd --add-rich-rule "rule family=ipv4 destination address={Cloud Server Public IP]/32 forward-port port=587 protocol=tcp to-port=587 to-addr={Private Server Private IP]" --permanent
sudo firewall-cmd --add-rich-rule "rule family=ipv4 destination address={Cloud Server Public IP]/32 forward-port port=993 protocol=tcp to-port=993 to-addr={Private Server Private IP]" --permanent

and to give an excerpt of one of the ports that Traefik passes straight through to the NGINX reverse proxy, these are the docker-compose lines:

        - "traefik.tcp.routers.mailu_smtp_ssl.rule=HostSNI(`*`)"
        - "traefik.tcp.routers.mailu_smtp_ssl.entrypoints=smtp-ssl"
        - "traefik.tcp.routers.mailu_smtp_ssl.tls.passthrough=true"
        - "traefik.tcp.routers.mailu_smtp_ssl.service=mailu_smtp_ssl"
        - "traefik.tcp.services.mailu_smtp_ssl.loadbalancer.server.port=465"

I'm guessing that a starting point would be swapping SNAT for the current masquerade config. I'm also guessing that some settings for x-layers-deep X-FORWARDED-FOR substitution would be necessary (although that wouldn't help for the non-http/s packets)...but I'm stumped on how to put it all together.

5
  • Check the logs at every layer to find where the IP address is being lost. Feb 11, 2021 at 12:29
  • Should I also try turning it off and turning it on again?
    – Christian
    Feb 11, 2021 at 22:25
  • No, you should check your logs. Feb 11, 2021 at 22:28
  • Excellent contribution, glad you're on the case. Half the services involved don't even have logs...
    – Christian
    Feb 12, 2021 at 1:34
  • The attitude is completely uncalled for. We are trying to help you here. You need more details to track down the problem. Without looking at the logs you do have, you can only make wild (and wrong) guesses, which seems to be what you proposed to do. With the logs, we can at least begin to narrow it down. Feb 12, 2021 at 1:42

0

You must log in to answer this question.

Browse other questions tagged .