My goal is to create (at least) two isolated networks for reverse proxying and have two exposed ports with correct IPs.

I tried different options, but I will need to set the IP-Address static for at least one of the isolated networks, so the bridge driver is a requirement.

This won't work at present, due to the way our parsing of the --network flag works. I'm going to re-mark this as a feature request, to add the ability to set custom slirp4netns options while simultaneously joining networks.

As a workaround, in the meantime I suggest you retain --net slirp4netns:options... and manually join the other networks with podman network connect after creation.

This cannot work! You cannot use both slirp4netns and networks.

First the bridge option is just an alias for the default network name podman. So when you want to join to you networks you have to use --net nextcloud-pub --net synapse-pub, the alias key word is used to set network alias names for the container which can be used to resolve this given name via the dns server from other containers.

Second, you cannot set slirp4netns option because slirp4netns is not used per container when you use rootless networks. We only spawn one slirp4netns process for the rootless network namespace. Rootless containers which use networks will always use the rootlesskit port handler since the slirp4netns one does not work for this at the moment.

I will close the issue since this is not a bug or something we can fix with the way it is designed but feel free to continue the conversation.

This won't work at present, due to the way our parsing of the --network flag works. I'm going to re-mark this as a feature request, to add the ability to set custom slirp4netns options while simultaneously joining networks.

As a workaround, in the meantime I suggest you retain --net slirp4netns:options... and manually join the other networks with podman network connect after creation.

This doesn't work.

$ podman run --name=reverse-proxy -d --net slirp4netns:port_handler=slirp4netns -p 8080:80 -p 8443:443 docker.io/library/nginx:1-alpine
12d40fe65da76e36971e8417725513af4f8108fac2fefe4439ca8eaa094fa5f8
$ podman network connect --ip 10.89.0.2 nextcloud-pub reverse-proxy 
Error: "slirp4netns" is not supported: invalid network mode

Maybe reopen this issue? @mheon

First the bridge option is just an alias for the default network name podman. So when you want to join to you networks you have to use --net nextcloud-pub --net synapse-pub, the alias key word is used to set network alias names for the container which can be used to resolve this given name via the dns server from other containers.

Ok - thanks for the explanation.

Second, you cannot set slirp4netns option because slirp4netns is not used per container when you use rootless networks. We only spawn one slirp4netns process for the rootless network namespace. Rootless containers which use networks will always use the rootlesskit port handler since the slirp4netns one does not work for this at the moment.

Totally my mistake - sorry.
slirp4netns port handler is the one I need, because it forwards the correct IP.
With rootlesskit port handler I just see the internal IP of the container.
Thus slirp4netns port handler does work? - still podman v4.0.0-dev
@Luap99

I also haven't worked with namespaces and pods yet - I am at the beginning of understanding podman without helping tools.

You cannot use slirp4netns port_handler with the networks at the moment, see #8193

I am facing the same problem, with a similar use case:

• two different bridge networks with containers running on them
• one container that has access to both networks, publishes the https port and acts as a web reverse proxy

I would like to have my reverse proxy to see the IP that originated the request, however, I see the internal IP of the container.

Is there any workaround for that? Apparently using pasta or slirp4netns is incompatible with containers operating in bridge mode.

@Loader009 have you found a working solution for that case?

I'm using a bare-installed nginx as the first reverse proxy (which I actually could put in a container) and another reverse proxy for all container, everything with default network driver. The second reverse proxy allows me to use the headers from the first reverse proxy and "correct" the IP.
This ofc doesn't work with container which are not able to process the forwarded-for headers.

For those I try to directly open a port - but since I stopped using synapse (it definitely needs a SSD for the database, with about 80GB of new data per day), I kinda don't need to resolve other issues.

Beside that I also have conntrack issues with podman, but that's a completely different issue.