Document that source IP for rootless containers is always 10.0.2.100 and slirp4netns workaround with it's (dis)advantages

[rugk]

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

/kind documentation
(?)

Problem

I had a curious "problem" with the webserver caddy, where each source IP was always 10.0.2.100. I could trace it back to podman being the obvious fault, because it's the "inside of container" vs "outside of container" view… 🙃
In the end, I solved this by switching to host networking…

Later I noticed this comment by @AkihiroSuda:

Also it should be documented that apps will always see 10.0.2.100 (or CNI IP) as the source address.

#9052 (comment)

Documentation

Searching the docs it seems that this comment was forgotten and nothing was actually documented.

As such, here is an issue to document the fact that this happens and explain the workaround/solution in this case (which AFAIK are either using rootfull containers or host networking as I did).
Edit: or… --network slirp4netns:port_handler=slirp4netns, apparently, as I was made ware, ref #9052 (anyway, that also needs documentation)

Relevance

IMHO this is important to document, because the use case of having a proper ingoing IP address is quite popular for all webservers, I guess.
Also, it's a difference to Docker/limitation of rootless containers, so IMHO, it should also be documented here.

[openshift-ci]

@rugk: The label(s) kind/docs cannot be applied, because the repository doesn't have them.

In response to this:

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

/kind docs
(?)

Problem

I had a curious "problem" with the webserver caddy, where each source IP was always 10.0.2.100. I could trace it back to podman being the obvious fault, because it's the "inside of container" vs "outside of container" view… 🙃
In the end, I solved this by switching to host networking…

Later I noticed this comment by @AkihiroSuda:

Also it should be documented that apps will always see 10.0.2.100 (or CNI IP) as the source address.

#9052 (comment)

Documentation

Searching the docs it seems that this comment was forgotten and nothing was actually documented.

As such, here is an issue to document the fact that this happens and explain the workaround/solution in this case (which AFAIK are either using rootfull containers or host networking as I did).

Relevance

IMHO this is important to document, because the use case of having a proper ingoing IP address is quite popular for all webservers, I guess.
Also, it's a difference to Docker/limitation of rootless containers, so IMHO, it should also be documented here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[rugk]

@openshift-ci-robot retry

Edit: does not work… 😞

[mheon]

Worth noting that this behavior can be worked around by specifying --net slirp4netns:port_handler=slirp4netns when creating the container. This forces the old slirp4netns port forwarding, as opposed to rootlesskit - it's slower, but does preserve source address (at the cost of some other quirks)

[rugk]

it's slower, but does preserve source address (at the cost of some other quirks)

Very worth noting to also document these two things and whatever quirks are there. Especially for a webserver (as I use it), the performance thing actually matters (especially if you use "multiple" reverse-proxies or so…).
So I would be very interested in hearing that…

---

Unrelated: Could someone add the kind/documentation tag, please? (I messed up with the bot I know 😅 )

[rugk]

This forces the old slirp4netns port forwarding, as opposed to rootlesskit

Do I understand this correctly that the new method is rootlesskit for rootless containers, and the old one was slirp4netns?
If yes, then the doc is outdated here too, as it says:

slirp4netns[:OPTIONS,...]: use slirp4netns(1) […]. This is the default for rootless containers.

It's then not the default anymore, as far as I get that.

Edit: Ah forget it, you said "slirp4netns port forwarding", which is only a part of slirp4netns, now this makes sense.

[github-actions]

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

[rhatdan]

@mheon @Luap99 is this still an issue?

[mheon]

I don't recall seeing a docs PR, so this still requires attention.

[Luap99]

I opened #11177