"Connection refused" from inside containers to the host's public IP
Hi all, We have a bunch of rootless containers running as a non-privileged user on a Ubuntu 22.04 server under Podman 4.5.0. One of them is running Browserless Chrome to render PDFs of the output of a Django-served URL of another container. The Django container is set up so that its CSS/JS/etc. static files are stored on the host machine and served by the host's Nginx. To correctly display the styles, Chrome therefore needs to access the endpoint via the public URL of the site. This is not working, because any connection attempts to the public IP from within any of the running containers fail with a Connection Refused error: - - - - $ curl -vvv https://our.nice.site * Trying <redacted IPv6>:443... * connect to <redacted IPv6> port 443 failed: Connection refused * Trying <redacted IPv4>:443... * connect to <redacted IPv4> port 443 failed: Connection refused * Failed to connect to our.nice.site port 443: Connection refused * Closing connection 0 curl: (7) Failed to connect to our.nice.site port 443: Connection refused - - - - The host itself is, of course, able to access itself with the public URL/IP just fine; this only occurs inside the containers. The containers are also able to access any other public URL, just not the one pointing to the host's own public IP. We're using pasta networking. All containers are set up with quadlet. Here's the Chrome container's quadlet generator: - - - - [Unit] Description=Browserless Chrome Wants=network-online.target After=network-online.target [Container] Image=browserless/chrome:1.59.0-chrome-stable ContainerName=browserless-chrome Network=pasta:-t,auto,-T,auto LogDriver=journald [Install] WantedBy=default.target - - - - All the other containers also use "Network=pasta:-t,auto,-T,auto". I tried to add --map-gw to the command line, since it seemed possibly relevant, but without success. "Network=pasta:--map-gw,-t,auto,-T,auto" failed on container startup with this error: Error: failed to start pasta: Port forwarding mode 'none' conflicts with previous mode "Network=pasta:-t,auto,-T,auto,--map-gw" started the container fine, but did not fix the Connection Refused error. Finally, the contents of containers.conf: - - - - [containers] log_driver="journald" tz="local" [network] network_backend="netavark" [engine] runtime="crun" - - - - Is this a bug, a misconfiguration on my part, or an intentional security feature of Podman networking and/or Podman with pasta, specifically? Is there any way for the containers to access the hosts's public IP? If not, we'll need to arrange some kind of awkward static file serving container for use by the Chrome container, but we'd really like to avoid that. - JL
On 21/06/2023 11:33, jklaiho@iki.fi wrote:
Hi all,
We have a bunch of rootless containers running as a non-privileged user on a Ubuntu 22.04 server under Podman 4.5.0.
One of them is running Browserless Chrome to render PDFs of the output of a Django-served URL of another container.
The Django container is set up so that its CSS/JS/etc. static files are stored on the host machine and served by the host's Nginx. To correctly display the styles, Chrome therefore needs to access the endpoint via the public URL of the site.
This is not working, because any connection attempts to the public IP from within any of the running containers fail with a Connection Refused error:
- - - -
$ curl -vvv https://our.nice.site * Trying <redacted IPv6>:443... * connect to <redacted IPv6> port 443 failed: Connection refused * Trying <redacted IPv4>:443... * connect to <redacted IPv4> port 443 failed: Connection refused * Failed to connect to our.nice.site port 443: Connection refused * Closing connection 0 curl: (7) Failed to connect to our.nice.site port 443: Connection refused
- - - -
The host itself is, of course, able to access itself with the public URL/IP just fine; this only occurs inside the containers. The containers are also able to access any other public URL, just not the one pointing to the host's own public IP.
We're using pasta networking. All containers are set up with quadlet. Here's the Chrome container's quadlet generator:
- - - -
[Unit] Description=Browserless Chrome Wants=network-online.target After=network-online.target
[Container] Image=browserless/chrome:1.59.0-chrome-stable ContainerName=browserless-chrome
Network=pasta:-t,auto,-T,auto LogDriver=journald
[Install] WantedBy=default.target
- - - -
All the other containers also use "Network=pasta:-t,auto,-T,auto". I tried to add --map-gw to the command line, since it seemed possibly relevant, but without success.
"Network=pasta:--map-gw,-t,auto,-T,auto" failed on container startup with this error:
Error: failed to start pasta: Port forwarding mode 'none' conflicts with previous mode
"Network=pasta:-t,auto,-T,auto,--map-gw" started the container fine, but did not fix the Connection Refused error.
Finally, the contents of containers.conf:
- - - - [containers] log_driver="journald" tz="local" [network] network_backend="netavark" [engine] runtime="crun"
- - - -
Is this a bug, a misconfiguration on my part, or an intentional security feature of Podman networking and/or Podman with pasta, specifically? Is there any way for the containers to access the hosts's public IP? If not, we'll need to arrange some kind of awkward static file serving container for use by the Chrome container, but we'd really like to avoid that.
- JL
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io Hi,
You are on the right track. By default pasta copies the host ip in the container so both have the same ip address, therefore you cannot connect to that ip because it is local to the container namespace. With `--map-gw` pasta remaps the gateway ip to the host ip. So with that option you have to connect to the gateway ip instead which pasta then remaps to the actual host ns. --- Paul
participants (2)
-
jklaiho＠iki.fi -
Paul Holzinger