rootless podman using pasta doesn't allow accessing the host-service ports

[slartibart70]

Issue Description

Client: Podman Engine
Version: 5.0.3
API Version: 5.0.3
Go Version: go1.22.2
Built: Fri May 10 02:00:00 2024
OS/Arch: linux/amd64

Using --network='host' or --network=slirp4netns i can access the hosts services, here sftp on port22 successfully.

With the new default 'pasta' network, this is no longer possible according to the docs (man podman-run, look for network/pasta)

But, the docs also state that the 'non-valid' pasta option --map-gw does indeed allow host-service communication coming from the container (as i understand). Sadly, this does not work:
podman run --rm -it --network=pasta:--map-gw 09db474e1757 bash
or defining this in ".config/containers/containers.conf"

[network]
default_rootless_network_cmd="pasta"
pasta_options = ["--map-gw"]

does not give me host-communications back.

Moreover, if you define the above in containers.conf AND run podman with podman run --rm -it --network=pasta:--map-gw ... podman crashes with the error:

panic: runtime error: slice bounds out of range [3:2]

Yes, i can use the options exclusively (commandline OR containers.conf) and a can use 'host' or 'slip4netns' but shouldn't this also work with pasta???
Any help is appreciated

Steps to reproduce the issue

see above

Describe the results you received

see above

Describe the results you expected

pasta network should allow a rootless-container to access host-services if configured properly

podman info output

If you are unable to run podman info for any reason, please provide the podman version, operating system and its version and the architecture you are running.

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

Yes

Additional environment details

Additional environment details

Additional information

Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting

[Luap99]

Should be the same issues as #22477 which is already fixed on main and will land in 5.1 soon

[tillmann]

shot from the hip: might not.

I have the same issue, but pasta seems to be invoked correctly.

e.g.

/usr/bin/pasta --config-net --dns-forward 169.254.0.1 -t none -u none -T none -U none --quiet --netns /run/user/1008/netns/netns-5f206c2f-29bc-8751-9875-8607f06b7f80

(no --no-map-gw 👍 )

#22477 should fix the minor issue OP was referring to ("Moreover,...")

I have no further options to pasta, yet I can't connect to ports on the host from inside the rootless container. When I use --network=slirp4netns:allow_host_loopback=true I can. Not sure if this is a podman or a pasta issue though.

[slartibart70]

i'm acknowledging the close-status of this ticket, because podman 5.1.0 works as expected.
Regarding the '--map-gw' option - this is also ok now

If i may ask, why are the host-mapped ports on the gateway-address a good idea?
Using pastas '-t' or '-T' option makes more sense to me.... can you elaborate a use case for having port-forwards on the gateway?

[tsugabloom]

I'll take your word on 5.1.0 fixing the connection to host ports; my distro packages haven't updated so I'm trying to build podman from source (I know I know). Currently none of my containers can communicate either to the host (or between each other; https://www.redhat.com/sysadmin/container-networking-podman#communicate-between-two-rootless-containers does not work even with --network=pasta:--map-gw). I agree with @tillmann that the patch seems like it won't be a fix but we'll see! 🤞

@slartibart70 This entire thread (long) #22653 (comment) might provide some idea: the tl;dr is it's kinda of an arbitrary decision, (if I understand correctly) they didn't want to use localhost (tho pods do) since that would be just as misleading and also have a lot of port conflicts, but they can't invent other interfaces because that needs root, and they don't want to change the address because that would mean every packet is then doing NAT.

I personally don't understand why NAT is seen as such a bad thing... Perf maybe? @sbrivio-rh would you be able to expand on why NAT is bad (regarding your "cons: NAT" comment I linked above just now).

[tsugabloom]

Still no connectivity even on 5.2.0-dev :( @slartibart70 did you reset your installation somehow to fix your host port access?

This used to work before a reboot last week. Hasn't work since, despite a few more reboots. Maybe I should file a new issue.

[slartibart70]

It's not working like this, you need to use 'localhost' and not the hosts ip address ... this is a port-forwarding only

Example with netcat:

podman run --rm -it --network pasta:--map-gw  09db474e1757 bash
# test
container: ip r
>> default via 192.168.3.1 dev eth0 proto dhcp metric 100
host: nc -l 1234 
container: nc 192.168.3.1 1234

Example with explict port forward:

podman run --rm -it --network pasta:-T,1234:1234  09db474e1757 bash

# test
host: nc -l 1234
container: nc localhost 1234

for rootless containers, of course

[sbrivio-rh]

@slartibart70 This entire thread (long) #22653 (comment) might provide some idea: the tl;dr is it's kinda of an arbitrary decision, (if I understand correctly) they didn't want to use localhost (tho pods do) since that would be just as misleading and also have a lot of port conflicts, but they can't invent other interfaces because that needs root, and they don't want to change the address because that would mean every packet is then doing NAT.

Exactly, thanks for the summary.

I personally don't understand why NAT is seen as such a bad thing... Perf maybe? @sbrivio-rh would you be able to expand on why NAT is bad (regarding your "cons: NAT" comment I linked above just now).

Throughput isn't affected because, from pasta's perspective, NAT would be implicit (you can imply it with --address by the way): pasta gets Layer-2 frames from the container, discards Layer-3 (IP/IPv6) addresses, and sends payload (no addresses) via Layer-4 sockets on the host (the kernel picks the address for outgoing packets). This is symmetric with the other path.

Now, if addresses match between host and container, you have, in the bigger picture, no address translation. Otherwise you do. But it's not like pasta actually goes and changes addresses in packets. It drops headers on the way out (of the container), and adds them on the way in. Whether headers have the same addresses as the host or not, the overhead is going to be the same.

The reasons why I consider NAT potentially problematic, at least in the sense of mandating it, are nicely described in Sections 6 and 9 of RFC 2993. Most relevantly, I think, it breaks applications and protocols that expect addressing to be consistent, and create a pretence of false security.

[tsugabloom]

container: ip r
>> default via 192.168.3.1 dev eth0 proto dhcp metric 100

Oh I'm so foolish, thanks @slartibart70. I was using my IP address not my router's IP address... embarrassing. Makes sense why I wasn't getting anywhere with debugging.

I was using ip a (address) not ip r (route) aaa.