podman --network --host doesn't work on MacOS

[kkimdev]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description
podman --network host does not work on MacOS

Steps to reproduce the issue:

1. podman run --rm -it --network host nginxinc/nginx-unprivileged
2. Open http://0.0.0.0:8080/ on a host web browser.

Describe the results you received:
"This site can’t be reached. 0.0.0.0 refused to connect."

Describe the results you expected:
"Welcome to nginx!"

Note: podman run --rm -it -p 8080:8080 nginxinc/nginx-unprivileged works.

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

Client:       Podman Engine
Version:      4.2.0
API Version:  4.2.0
Go Version:   go1.18.5
Built:        Thu Aug 11 05:46:05 2022
OS/Arch:      darwin/amd64

Server:       Podman Engine
Version:      4.2.0
API Version:  4.2.0
Go Version:   go1.18.4
Built:        Thu Aug 11 23:42:17 2022
OS/Arch:      linux/amd64

Output of podman info:

host:
  arch: amd64
  buildahVersion: 1.27.0
  cgroupControllers:
  - cpu
  - io
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.0-2.fc36.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.0, commit: '
  cpuUtilization:
    idlePercent: 96.11
    systemPercent: 1.45
    userPercent: 2.44
  cpus: 1
  distribution:
    distribution: fedora
    variant: coreos
    version: "36"
  eventLogger: journald
  hostname: localhost.localdomain
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 1000000
    uidmap:
    - container_id: 0
      host_id: 501
      size: 1
    - container_id: 1
      host_id: 100000
      size: 1000000
  kernel: 5.18.18-200.fc36.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 661733376
  memTotal: 2064896000
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun-1.5-1.fc36.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.5
      commit: 54ebb8ca8bf7e6ddae2eb919f5b82d1d96863dea
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/user/501/podman/podman.sock
  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: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.0-0.2.beta.0.fc36.x86_64
    version: |-
      slirp4netns version 1.2.0-beta.0
      commit: 477db14a24ff1a3de3a705e51ca2c4c1fe3dda64
      libslirp: 4.6.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.3
  swapFree: 0
  swapTotal: 0
  uptime: 1h 30m 46.00s (Approximately 0.04 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - docker.io
store:
  configFile: /var/home/core/.config/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 0
    stopped: 1
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /var/home/core/.local/share/containers/storage
  graphRootAllocated: 106825756672
  graphRootUsed: 4620713984
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 6
  runRoot: /run/user/501/containers
  volumePath: /var/home/core/.local/share/containers/storage/volumes
version:
  APIVersion: 4.2.0
  Built: 1660228937
  BuiltTime: Thu Aug 11 23:42:17 2022
  GitCommit: ""
  GoVersion: go1.18.4
  Os: linux
  OsArch: linux/amd64
  Version: 4.2.0

Package info (e.g. output of rpm -q podman or apt list podman):

$ brew info podman
==> podman: stable 4.2.0 (bottled), HEAD
Tool for managing OCI containers and pods
https://podman.io/
/usr/local/Cellar/podman/4.2.0 (178 files, 48.5MB) *
  Poured from bottle on 2022-09-07 at 13:41:20
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/podman.rb
License: Apache-2.0
==> Dependencies
Build: go-md2man ✘, [email protected] ✘
Required: qemu ✔
==> Options
--HEAD
	Install HEAD version
==> Caveats
Bash completion has been installed to:
  /usr/local/etc/bash_completion.d
==> Analytics
install: 24,749 (30 days), 60,086 (90 days), 198,346 (365 days)
install-on-request: 24,099 (30 days), 59,090 (90 days), 197,229 (365 days)
build-error: 16 (30 days)

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)

Yes

Additional environment details (AWS, VirtualBox, physical, etc.):
Macbook Pro 2019

[vrothberg]

Thanks for reaching out, @kkimdev !
@Luap99 WDYT?

[Luap99]

The podman machine vm has its own network stack, --network host will use that and not the macos one. I don't think it is possible to share the macos network stack with the linux VM. Does it work with docker-desktop?

[kkimdev]

I see, thanks for the context! I just tried with docker-desktop but it doesn't work either.

Though, then is there an ip / hostname of the linux VM exposed to the host Mac that I can access?

[Luap99]

Since we use user space networking for the VM it is impossible to access the VM via ip address from the host. You have to forward ports to access it.

From within the VM you can use host.containers.internal to access the host.

[kkimdev]

I see, that's unfortunate :( I wanted to avoid having to specify exact ports to access but that seems unavoidable.

[kkimdev]

Note on a usecase:

We have a shared development environment container image, which we do many random stuff inside, and it would be very convenient not having to specify which port to expose ahead, and not even think about it, just like developing on the host machine.

[baude]

well, in many ways the networking is similar to --network host. If you choose to publish a port of 8888, you can access this on the macos as localhost:8888. isnt that sort of what you described?

[kkimdev]

Yes. But let's say while working inside the container, you suddenly want to run a test server on port :8889. With --network host, you don't even need to think about the network structure. Without, you need to exit the container and add an option -p8889:8889 and enter again.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@kkimdev @baude What is going on with this issue? Is this still relavent?

[kkimdev]

It will be a good feature to support but it seems there is no good way to implement it at this moment.

I think it's good to update the document and close the bug as "won't fix".

[btrepp]

Since we use user space networking for the VM it is impossible to access the VM via ip address from the host. You have to forward ports to access it.

From within the VM you can use host.containers.internal to access the host.

Is it possible to elaborate?. I seem to need to use net host to run some containers.
I'd accept this is the 'qemu host', but I am surprised that I can't access the QEMU host from the MacOS host via some sort of IP?. How on earth is QEMU speaking to the outside world (e.g even just pulling containers, it needs some kind of network, which is only one way?).
I would have thought it was some sort of NAT behind the MacOS layer. So we would be able to at least get to the 'qemu' machine which is exposing things via net host.

How does podman -p expose ports to begin with?

[Luap99]

@btrepp I recommend to open a discussion if you have general questions instead of commenting on existing issues.
But the answer to your question is gvproxy, https://github.com/containers/gvisor-tap-vsock.

[btrepp]

Hi @Luap99. That link is greatly useful. I came to this thread because I had this exact bug, so I don't think this is a general question, more discussion about this actual bug, so others can help understand the issue.

In fact the gvisor-tap-vsock repo has some inspiration as to a work-around so at least I can 'sort-of' use net host, even if there's a bit of futzing.

Hack to at least get some ports forwarded

Gvproxy is exposing a ssh port, so we can be cheeky and use SSH port forwarding. You can do this in gvproxy too, but I am not 100% sure it is safe to connect to that auto-generated sock that gvproxy is currently using.

  501 22429     1   0  8:27pm ??         0:05.96 /opt/homebrew/Cellar/podman/4.3.0/libexec/podman/gvproxy -listen-qemu unix:///var/folders/c1/vbnsmxm507n4tymmlvzvx45r0000gn/T/podman/qmp_podman-machine-default.sock -pid-file /var/folders/c1/vbnsmxm507n4tymmlvzvx45r0000gn/T/podman/podman-machine-default_proxy.pid -ssh-port 55816 -forward-sock /Users/beautrepp/.local/share/containers/podman/machine/podman-machine-default/podman.sock -forward-dest /run/podman/podman.sock -forward-user root -forward-identity /Users/beautrepp/.ssh/podman-machine-default

So we can see my SSH is on port 55816. Using root, with an identity file.
Thus I can tweak to

ssh [email protected] -p 55816 -i /Users/beautrepp/.ssh/podman-machine-default -v -L 4646:127.0.0.1:4646

Which lets me at least expose the ports needed by hand. This is obviously not 'exactly' the same as net=host, but could be helpful for someone who needs to use net=host, and doesn't want to spin up a whole seperate VM stack to do so. Which was my case.

There is also probably a much better way speaking to the gvsock socket directly, but I think Podman is only spinning up a tcp port for ssh at the moment.. which makes sense, but perhaps this is configurable

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@baude @Luap99 should we close this issue?

[vlad-rw]

Yeah it would be nice to have configurability of the gvisor-vsock to be able to emulate net=host a bit better.