Hi there, I was tweaking around pasta and its usage with podman, and I realized that from pasta guest namespaces it is possible to access host ports through the address of secondary interfaces on the host. Say I have two interfaces on host, with eth0 connecting to a gateway and eth1 connected to another LAN:$ # On host $ ifconfig eth0 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.2 netmask 255.255.255.0 broadcast 192.168.1.255 ... $ ifconfig eth1 eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.110.1 netmask 255.255.255.0 broadcast 192.168.110.255 ... $ ip route default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.2 metric 1024 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2 metric 1024 192.168.1.1 dev eth0 proto dhcp scope link src 192.168.1.2 metric 1024 192.168.110.0/24 dev eth1 proto kernel scope link src 192.168.110.1If there is some service started on host:$ python -m http.server Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...From a pasta namespace, it is impossible to access the host ports by the address of the main interface:$ pasta --config-net $ # Now in pasta namespace $ curl 192.168.1.2:8000 curl: (7) Failed to connect to 192.168.1.2 port 8000 after 0 ms: Couldn't connect to serverHowever I found that it is possible to do so by the address of the secondary interface:$ # In same pasta environment as above $ curl 192.168.110.1:8000 <!DOCTYPE HTML> <html lang="en"> ...Is this an expected behavior? I believe this is a security escape in the container context, since containerized services can gain access to unintended resources. Thanks, Chaser Huang -- Kangjing "Chaser" Huang