pasta network missing ip, gateway, etc. with default settings

[TheRealDarklord]

Issue Description

It looks like that using network modes other than bridge result in partial working networks. I would have assumed that default params result in a 100% functional network.

context:
I am using checkmk (raw edition) container for monitoring my devices and I also want to monitor podman host machine to get stats about its load and memory usage. To get monitoring working the container needs to connect to port 6556 of monitored hosts where an agent listens and delivers stats. This will not work by default bridge network since communication with host (other than ping) is not available by design. So I tried pasta network mode and got communcation working between container and host. To access checkmk's web interface I use traefik with container labels. This works well with bridge network. Unfortunately the pasta mode only sets up a partial working network. At least it looks to me like that but I am not a networking expert. After switchting to pasta network traefik repeatedly reports the following Unable to find the IP address. container=check-mk-raw-monitoring-d9a70509bebf61c99af2ceeda4b871e9a5f72eb0e59629cf2d6d7a3f86ed11a9 providerName=docker serviceName=monitoringservice.

When using the default bridge network I can inspect the checkmk container and see its effective network settings resulting from bridge mode. These look like the following and as you can see NetworkSettings.Networks has an entry with sane values (ip address, gateway and so on).

❯ podman container inspect 5502508c3b55 | gron | grep -i network
json[0].Config.CreateCommand[37] = "--network=monitoring_default:alias=check-mk-raw";
json[0].HostConfig.NetworkMode = "bridge";
json[0].NetworkSettings = {};
json[0].NetworkSettings.Bridge = "";
json[0].NetworkSettings.EndpointID = "";
json[0].NetworkSettings.Gateway = "";
json[0].NetworkSettings.GlobalIPv6Address = "";
json[0].NetworkSettings.GlobalIPv6PrefixLen = 0;
json[0].NetworkSettings.HairpinMode = false;
json[0].NetworkSettings.IPAddress = "";
json[0].NetworkSettings.IPPrefixLen = 0;
json[0].NetworkSettings.IPv6Gateway = "";
json[0].NetworkSettings.LinkLocalIPv6Address = "";
json[0].NetworkSettings.LinkLocalIPv6PrefixLen = 0;
json[0].NetworkSettings.MacAddress = "";
json[0].NetworkSettings.Networks = {};
json[0].NetworkSettings.Networks.monitoring_default = {};
json[0].NetworkSettings.Networks.monitoring_default.Aliases = [];
json[0].NetworkSettings.Networks.monitoring_default.Aliases[0] = "check-mk-raw";
json[0].NetworkSettings.Networks.monitoring_default.Aliases[1] = "5502508c3b55";
json[0].NetworkSettings.Networks.monitoring_default.DriverOpts = null;
json[0].NetworkSettings.Networks.monitoring_default.EndpointID = "";
json[0].NetworkSettings.Networks.monitoring_default.Gateway = "10.89.0.1";
json[0].NetworkSettings.Networks.monitoring_default.GlobalIPv6Address = "";
json[0].NetworkSettings.Networks.monitoring_default.GlobalIPv6PrefixLen = 0;
json[0].NetworkSettings.Networks.monitoring_default.IPAMConfig = null;
json[0].NetworkSettings.Networks.monitoring_default.IPAddress = "10.89.0.2";
json[0].NetworkSettings.Networks.monitoring_default.IPPrefixLen = 24;
json[0].NetworkSettings.Networks.monitoring_default.IPv6Gateway = "";
json[0].NetworkSettings.Networks.monitoring_default.Links = null;
json[0].NetworkSettings.Networks.monitoring_default.MacAddress = "3e:e6:2f:92:38:24";
json[0].NetworkSettings.Networks.monitoring_default.NetworkID = "a6d1d2fa158b429f0c8682b8c872a94f7d12187b9eef636fef287a6b932eca72";
json[0].NetworkSettings.Ports = {};
json[0].NetworkSettings.Ports["5000/tcp"] = null;
json[0].NetworkSettings.Ports["6557/tcp"] = null;
json[0].NetworkSettings.Ports["8000/tcp"] = [];
json[0].NetworkSettings.Ports["8000/tcp"][0] = {};
json[0].NetworkSettings.Ports["8000/tcp"][0].HostIp = "0.0.0.0";
json[0].NetworkSettings.Ports["8000/tcp"][0].HostPort = "8000";
json[0].NetworkSettings.SandboxID = "";
json[0].NetworkSettings.SandboxKey = "/run/user/1000/netns/netns-2cacabb1-112f-6291-853f-3cb2e3bfb626";

After switching to pasta settings (--network=pasta:--map-gw,-T,6556) a connection from the container to the hosts port by accessing it via localhost:6556 can be established. But it results in traefik not working with that container anymore (see message above). When I inspect the container set up with pasta network it looks like this:

❯ podman container inspect ea47d66a6457 | gron | grep -i network
json[0].Config.CreateCommand[37] = "--network=pasta:--map-gw,-T,6556";
json[0].HostConfig.NetworkMode = "pasta";
json[0].NetworkSettings = {};
json[0].NetworkSettings.Bridge = "";
json[0].NetworkSettings.EndpointID = "";
json[0].NetworkSettings.Gateway = "";
json[0].NetworkSettings.GlobalIPv6Address = "";
json[0].NetworkSettings.GlobalIPv6PrefixLen = 0;
json[0].NetworkSettings.HairpinMode = false;
json[0].NetworkSettings.IPAddress = "";
json[0].NetworkSettings.IPPrefixLen = 0;
json[0].NetworkSettings.IPv6Gateway = "";
json[0].NetworkSettings.LinkLocalIPv6Address = "";
json[0].NetworkSettings.LinkLocalIPv6PrefixLen = 0;
json[0].NetworkSettings.MacAddress = "";
json[0].NetworkSettings.Ports = {};
json[0].NetworkSettings.Ports["5000/tcp"] = null;
json[0].NetworkSettings.Ports["6557/tcp"] = null;
json[0].NetworkSettings.Ports["8000/tcp"] = [];
json[0].NetworkSettings.Ports["8000/tcp"][0] = {};
json[0].NetworkSettings.Ports["8000/tcp"][0].HostIp = "0.0.0.0";
json[0].NetworkSettings.Ports["8000/tcp"][0].HostPort = "8000";
json[0].NetworkSettings.SandboxID = "";
json[0].NetworkSettings.SandboxKey = "/run/user/1000/netns/netns-be1da890-bcda-1d8a-4bfe-5ae2da1fc875";

As you can see the whole NetworkSettings.Networks block is missing. I would assume that's the reason why traefik cannot pick up the container anymore to do its routing magic.

So it seems like the default options for pasta aren't enough to create a functional network entry. I did try using slirp4netns but had very similar results.

Steps to reproduce the issue

To reproduce the issue in a basic form you need an open port on your host, then you can do:
bridge

1. podman run --rm -it --network=bridge debian:bookworm bash
2. once inside the container apt-get update && apt-get install -y telnet
3. telnet [ip of host] [your open port]

root@8a5f3cd1c848:/# telnet 192.168.200.150 6556
Trying 192.168.200.150...
telnet: Unable to connect to remote host: Connection refused

4. inspect the created container to see the fully created network (named podman by default, having ip address, gateway, etc. set up correctly).

pasta

1. podman run --rm -it --network=pasta:--map-gw,-T,6556 debian:bookworm bash
2. once inside the container apt-get update && apt-get install -y telnet
3. pasta mapping the host access through localhost so telnet 127.0.0.1 [your open port] does work now

root@c53eb0e90fad:/# telnet 127.0.0.1 6556
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
16

4. connection to the host now is working but inspecting the container now you can see additional network params (any of the above like ip address, gateway) are missing

Describe the results you received

The result in my traefik context is that the container using pasta network is skipped for traefik routing since traefik cannot get any ip for that container and therefore cannot route requests to that container anymore.

Describe the results you expected

I would have expected a fully funcitonal network with ip, gateway and so on based on sane default settings without me setting them all up-

podman info output

❯ podman info
host:
  arch: amd64
  buildahVersion: 1.40.1
  cgroupControllers:
  - cpu
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.13-1.fc42.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.13, commit: '
  cpuUtilization:
    idlePercent: 98.88
    systemPercent: 0.47
    userPercent: 0.64
  cpus: 16
  databaseBackend: sqlite
  distribution:
    distribution: fedora
    variant: server
    version: "42"
  eventLogger: journald
  freeLocks: 2002
  hostname: power
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 524288
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 524288
      size: 65536
  kernel: 6.15.5-200.fc42.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 1942278144
  memTotal: 16124416000
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    dns:
      package: aardvark-dns-1.15.0-1.fc42.x86_64
      path: /usr/libexec/podman/aardvark-dns
      version: aardvark-dns 1.15.0
    package: netavark-1.15.2-1.fc42.x86_64
    path: /usr/libexec/podman/netavark
    version: netavark 1.15.2
  ociRuntime:
    name: crun
    package: crun-1.22-1.fc42.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.22
      commit: 4de19b63a85efd9ea8503452179c371181750130
      rundir: /run/user/1000/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
  os: linux
  pasta:
    executable: /usr/bin/pasta
    package: passt-0^20250611.g0293c6f-1.fc42.x86_64
    version: |
      pasta 0^20250611.g0293c6f-1.fc42.x86_64
      Copyright Red Hat
      GNU General Public License, version 2 or later
        <https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
      This is free software: you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
  remoteSocket:
    exists: true
    path: /run/user/1000/podman/podman.sock
  rootlessNetworkCmd: pasta
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.3.1-2.fc42.x86_64
    version: |-
      slirp4netns version 1.3.1
      commit: e5e368c4f5db6ae75c2fce786e31eef9da6bf236
      libslirp: 4.8.0
      SLIRP_CONFIG_VERSION_MAX: 5
      libseccomp: 2.5.5
  swapFree: 8532684800
  swapTotal: 8589930496
  uptime: 60h 39m 15.00s (Approximately 2.50 days)
  variant: ""
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
store:
  configFile: /home/therealdarklord/.config/containers/storage.conf
  containerStore:
    number: 19
    paused: 0
    running: 17
    stopped: 2
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/therealdarklord/.local/share/containers/storage
  graphRootAllocated: 510355570688
  graphRootUsed: 33358622720
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Supports shifting: "false"
    Supports volatile: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 51
  runRoot: /run/user/1000/containers
  transientStore: false
  volumePath: /home/therealdarklord/.local/share/containers/storage/volumes
version:
  APIVersion: 5.5.2
  BuildOrigin: Fedora Project
  Built: 1750723200
  BuiltTime: Tue Jun 24 02:00:00 2025
  GitCommit: e7d8226745ba07a64b7176a7f128e4ef53225a0e
  GoVersion: go1.24.4
  Os: linux
  OsArch: linux/amd64
  Version: 5.5.2

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

Yes

Additional environment details

No response

Additional information

No response

[Luap99]

That is the expected behavior, pasta and slirp4netns are network modes that function fundamentally different from bridge networks. They only connect a single namespace an the ip there isn't actually routeable from anywhere besides that ns so it would be pointless to list in inspect as that would just mean other containers would assume they connect to it when they don't.

As for why you cannot reach the host ip that is also because pasta copies it into its namespace, see
https://blog.podman.io/2024/10/podman-5-3-changes-for-improved-networking-experience-with-pasta/
#26502
#22943 (comment)

So what you should do is use bridge and then connect to host.containers.internal instead to reach the host.

[TheRealDarklord]

Ok, thanks for the explanation. And big thumbs up for that easy solution. That host.containers.internal works flawlessly when I tried connecting to the host port by either the basic test with debian:bookworm image or the actual checkmk container. I'm amazed that I did not stumble across that solution earlier. I spent hours figuring out what the actual problem was and in which ways it could be solved. I'm glad it works now :)