Unable to access exposed port of containerA from within containerB #23573

rlenferink · 2024-08-11T17:57:42Z

rlenferink
Aug 11, 2024

Hello,

I am not sure if this is expected podman behaviour, or whether this actually is a bug.

I am trying to do the following:

Start a container with a webserver, we'll call this containerA
containerA exposes a port, e.g. port 9999
A new container is started - containerB - which tries to connect to this exposed port via the host its IP address. This doesn't work.

Scenario 1: Without a custom network created

## TERMINAL 1 - Start containerA, which exposes a webserver on port 9999 ##
[rlenferink@fedora ~]$ podman run -it --rm -p 9999:80 httpd:2.4
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 192.168.1.94. Set the 'ServerName' directive globally to suppress this message
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 192.168.1.94. Set the 'ServerName' directive globally to suppress this message
[Sun Aug 11 17:34:11.592829 2024] [mpm_event:notice] [pid 1:tid 139653171509120] AH00489: Apache/2.4.58 (Unix) configured -- resuming normal operations
[Sun Aug 11 17:34:11.592937 2024] [core:notice] [pid 1:tid 139653171509120] AH00094: Command line: 'httpd -D FOREGROUND'
192.168.1.1 - - [11/Aug/2024:17:34:13 +0000] "GET / HTTP/1.1" 200 45

## TERMINAL 2 - Connect to the webserver exposed on port 9999 ##
# On the host => works as expected
[rlenferink@fedora ~]$ curl -L http://192.168.1.94:9999
<html><body><h1>It works!</h1></body></html>

# Start containerB
[rlenferink@fedora ~]$ podman run -it --rm registry.access.redhat.com/ubi8/ubi:8.10
[root@947570946e79 /]# dnf install -y ip-utils
<snip>

# Pinging from containerB to host works
[root@947570946e79 /]# ping 192.168.1.94
PING 192.168.1.94 (192.168.1.94) 56(84) bytes of data.
64 bytes from 192.168.1.94: icmp_seq=1 ttl=64 time=0.018 ms

# Connecting from containerB to the exposed port 9999 does not work
[root@947570946e79 /]# curl -L http://192.168.1.94:9999
curl: (7) Failed to connect to 192.168.1.94 port 9999: Connection refused
[root@947570946e79 /]# exit

When manually creating a container network it starts to work.

Scenario 2: With a custom network created

## TERMINAL 1 - Create network and start container A, which exposes a webserver on port 9999 ##
[rlenferink@fedora ~]$ podman network create test-network
test-network
[rlenferink@fedora ~]$ podman run -it --rm --network test-network -p 9999:80 httpd:2.4
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 10.89.2.2. Set the 'ServerName' directive globally to suppress this message
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 10.89.2.2. Set the 'ServerName' directive globally to suppress this message
[Sun Aug 11 17:39:23.897214 2024] [mpm_event:notice] [pid 1:tid 139702969194368] AH00489: Apache/2.4.58 (Unix) configured -- resuming normal operations
[Sun Aug 11 17:39:23.897291 2024] [core:notice] [pid 1:tid 139702969194368] AH00094: Command line: 'httpd -D FOREGROUND'

## TERMINAL 2 - Connect to the webserver exposed on port 9999 ##
# On the host
[rlenferink@fedora ~]$ curl -L http://192.168.1.94:9999
<html><body><h1>It works!</h1></body></html>

# Within a newly started container B (connected to the test-network)
[rlenferink@fedora ~]$ podman run -it --rm --network test-network registry.access.redhat.com/ubi8/ubi:8.10

# Connecting from container B to the exposed port 9999 works
[root@f3fe24aa27b3 /]# curl -L http://192.168.1.94:9999
<html><body><h1>It works!</h1></body></html>

I am not sure why a network needs to be created for containerB to access a service already exposed to the host.

This is with podman 5.1.1:

[rlenferink@fedora ~]$ podman --version
podman version 5.1.1
[rlenferink@fedora ~]$ podman info | grep -i network
  networkBackend: netavark
  networkBackendInfo:
  rootlessNetworkCmd: pasta
  network:

Roy

Luap99 · 2024-08-12T11:08:07Z

Luap99
Aug 12, 2024
Maintainer

Without a custom network you use the pasta network mode as default and because that copies your host ip into the container so it will not reach that ip on the host anymore.
#22653 (comment)
If you have a second host ip using the host.containers.internal name to connect is the easiest IMO.

In the custom network case we still use pasta but there is a extra network namespace involved, see something like #22943 (comment)
This means that if you now connect to the host ip from the container you land in the rootless-netns and inside there we have DNAT rules to redirect the traffic into the container so that works.
You however would still not reach any service from the host via that address.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Unable to access exposed port of containerA from within containerB #23573

{{title}}

Replies: 1 comment

{{title}}

Select a reply

Unable to access exposed port of containerA from within containerB #23573

rlenferink Aug 11, 2024

Replies: 1 comment

Luap99 Aug 12, 2024 Maintainer

rlenferink
Aug 11, 2024

Luap99
Aug 12, 2024
Maintainer