On Thu, Nov 27, 2025 at 01:48:54PM +0100, Jan Wrobel wrote:

Hi,

For pasta, would you consider an option to enable automatic forwarding of ports bound in a namespace, but make the forwarded ports available only via localhost, not all addresses?

I'm working on a sandboxing program which uses pasta. The option -t "auto" is super convenient, but requires extra care, without proper firewall setup bound ports become automatically available to outside world. For a sandboxing program like mine, it is not a safe default to run with, because the program shouldn't assume the user will have a firewall configured.

If something like "localhost/auto" was supported, it would match the convenience of "auto", no manual port mapping config would be needed, but would be safer for uses cases where exposing ports to outside world is problematic.

Short answer: yes, but it might be a while. Long answer: We want to make our forwarding / NAT configuration more flexible in ways that would allow a bunch of things, including this. There are a lot of different features people have requested, each individually simple, but together adding up to quite a lot of work. I'm actively working on making our internal data structures more flexible to allow more general configuration. However, it's fairly slow going, between other firefighting and unravelling some technical debt. If you want to make sure your specific use case isn't forgotten, the best way would be to file a ticket for it on passt.top - it will probably be blocked on https://bugs.passt.top/show_bug.cgi?id=140 but that will keep a record to look back at later. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson

On Fri, Nov 28, 2025 at 12:03:06PM +0100, Jan Wrobel wrote:

On Fri, Nov 28, 2025 at 2:10 AM David Gibson wrote:

...

On Thu, Nov 27, 2025 at 01:48:54PM +0100, Jan Wrobel wrote:

...

Hi,

For pasta, would you consider an option to enable automatic forwarding of ports bound in a namespace, but make the forwarded ports available only via localhost, not all addresses?

I'm working on a sandboxing program which uses pasta. The option -t "auto" is super convenient, but requires extra care, without proper firewall setup bound ports become automatically available to outside world. For a sandboxing program like mine, it is not a safe default to run with, because the program shouldn't assume the user will have a firewall configured.

If something like "localhost/auto" was supported, it would match the convenience of "auto", no manual port mapping config would be needed, but would be safer for uses cases where exposing ports to outside world is problematic.

Short answer: yes, but it might be a while.

Long answer:

We want to make our forwarding / NAT configuration more flexible in ways that would allow a bunch of things, including this. There are a lot of different features people have requested, each individually simple, but together adding up to quite a lot of work. I'm actively working on making our internal data structures more flexible to allow more general configuration. However, it's fairly slow going, between other firefighting and unravelling some technical debt.

If you want to make sure your specific use case isn't forgotten, the best way would be to file a ticket for it on passt.top - it will probably be blocked on https://bugs.passt.top/show_bug.cgi?id=140 but that will keep a record to look back at later.

Thanks, for considering adding this feature!

I'll add the ticket, but currently there is some problem with the passt ticket system. I've seen it working at some point but today and yesterday https://passt.top/passt/bugs is just an empty page, and https://bugs.passt.top/index.cgi gives 403 error

Oh, weird. https://bugs.passt.top is the address to use, but I haven't noticed it being down in the last couple of days. It seems to me working for me right now. Note that signing up for an account is likely to be somewhat slow - Stefano has to manually intervene for each sign up, to avoid inundation by bots. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson

On Sun, Nov 30, 2025 at 11:43 AM Stefano Brivio wrote:

On Fri, 28 Nov 2025 12:03:06 +0100 Jan Wrobel wrote:

...

On Fri, Nov 28, 2025 at 2:10 AM David Gibson wrote:

...

On Thu, Nov 27, 2025 at 01:48:54PM +0100, Jan Wrobel wrote:

...

Hi,

For pasta, would you consider an option to enable automatic

forwarding

...

...

...

of ports bound in a namespace, but make the forwarded ports available only via localhost, not all addresses?

I'm working on a sandboxing program which uses pasta. The option -t "auto" is super convenient, but requires extra care, without proper firewall setup bound ports become automatically available to outside world. For a sandboxing program like mine, it is not a safe default to run with, because the program shouldn't assume the user will have a firewall configured.

If something like "localhost/auto" was supported, it would match the convenience of "auto", no manual port mapping config would be needed, but would be safer for uses cases where exposing ports to outside world is problematic.

Short answer: yes, but it might be a while.

Long answer:

We want to make our forwarding / NAT configuration more flexible in ways that would allow a bunch of things, including this. There are a lot of different features people have requested, each individually simple, but together adding up to quite a lot of work. I'm actively working on making our internal data structures more flexible to allow more general configuration. However, it's fairly slow going, between other firefighting and unravelling some technical debt.

If you want to make sure your specific use case isn't forgotten, the best way would be to file a ticket for it on passt.top - it will probably be blocked on https://bugs.passt.top/show_bug.cgi?id=140 but that will keep a record to look back at later.

Thanks, for considering adding this feature!

I'll add the ticket, but currently there is some problem with the passt ticket system. I've seen it working at some point but today and yesterday https://passt.top/passt/bugs is just an empty page, and https://bugs.passt.top/index.cgi gives 403 error

Weird, sorry for the inconvenience, both work for me. I did some maintenance last week but I didn't expect any downtime as a result.

Can you try again and, if things fail, give me an exact timestamp of when you tried, so that I can try to find out something from logs?

This still doesn't work for me with the same 403 error. Perhaps it works for you because you already have an account and are logged-in to the ticket system? Try accessing https://bugs.passt.top/index.cgi from a private browser window, maybe then you will also trigger the error? Today the failure happened for example at Mon, 01 Dec 2025 10:02:47 GMT Cheers, Jan

On Mon, Dec 1, 2025 at 11:32 AM Stefano Brivio wrote:

On Mon, 1 Dec 2025 11:12:20 +0100 Jan Wrobel wrote:

...

This still doesn't work for me with the same 403 error. Perhaps it works for you because you already have an account and are logged-in to the ticket system? Try accessing https://bugs.passt.top/index.cgi from a private browser window, maybe then you will also trigger the error?

Today the failure happened for example at Mon, 01 Dec 2025 10:02:47 GMT

Oops, my bad! The whole registered subnet was denied access, specifically for Bugzilla, because of some recent "AI" bot scraping from there.

I'll need to come up with a better approach. I don't want to make it slower for everybody with Anubis (https://anubis.techaro.lol/) but the risk of banning people like it happened to you is also pretty bad. :(

Maybe it would make sense to use Anubis just for Bugzilla. The rest seems to be fast/robust enough for the moment.

It should work now. Sorry for that.

Thanks, it works well now. I've added a ticket. Cheers, Jan