From: Stefano Brivio <sbrivio@redhat.com>
To: "Ben Woods" <pasta@ben.woods.am>
Cc: passt-user@passt.top
Subject: Re: pasta behaviour with multiple NICs
Date: Fri, 25 Apr 2025 09:26:20 +0200 [thread overview]
Message-ID: <20250425092620.074e2cce@elisabeth> (raw)
In-Reply-To: <38893f85-ca3d-4e1e-929d-236df89ab9f6@app.fastmail.com>
Hi Ben,
On Fri, 25 Apr 2025 14:54:18 +0800
"Ben Woods" <pasta@ben.woods.am> wrote:
> Hi everyone,
>
> I'm struggling to understand how pasta will behave when the host has
> multiple network interfaces. I can't see this mentioned in the
> website or man page.
Right, yeah, it's not really mentioned anywhere, sorry for that, and
thanks for your question.
> I'm using pasta with podman if that makes a difference.
It shouldn't make a difference.
> Example Scenario - 2 interfaces - eth0 (with default route) and eth1
> in a different subnet.
>
> When the podman container is created, inside the container there is a
> single interface shown that mimics the eth0 interface name, IP,
> gateway.
>
> If traffic is initiated from the container to an IP within the eth1
> subnet - how does pasta make it appear to come from the eth1 IP
> address? Does it automatically apply NAT to achieve this?
The operating system (unfortunately it's Linux only, so far) takes care
of all that, pasta has no idea: it just opens a socket and connect()s
it to the destination address (that might be bind() _and_ connect(), for
UDP). The kernel then decides based on routing rules and tables.
But yes, this typically results in NAT, at least with the default
source address selection Linux does.
In other words: it's as if your container and everything inside it
behaved like a local process, network-wise, as seen from outside.
Given that pasta isn't in charge of network (or even transport) headers
"outside", it doesn't really "do NAT", but, with default options and a
matching upstream interface, it avoids that NAT is done in the bigger
picture.
> If the host has a static route for a subnet not directly connected to
> either eth0 or eth1, but the static route uses a next hop IP address
> within the eth1 subnet - will pasta apply NAT to the eth1 IP address,
> and the use the static route to send it via the next-hop router?
This also reduces to a question about Linux, essentially. Yes, as far
as I know, that would be the outcome: source NAT using a matching
address assigned to eth1, if any (preferred source address).
Does that answer your question?
--
Stefano
next parent reply other threads:[~2025-04-25 7:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <38893f85-ca3d-4e1e-929d-236df89ab9f6@app.fastmail.com>
2025-04-25 7:26 ` Stefano Brivio [this message]
2025-04-25 7:49 ` pasta behaviour with multiple NICs Ben Woods
2025-04-25 8:49 ` Stefano Brivio
2025-04-25 7:03 ` Ben Woods
[not found] ` <174557100872.151934.16258096252005211440@maja>
2025-04-28 4:02 ` David Gibson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250425092620.074e2cce@elisabeth \
--to=sbrivio@redhat.com \
--cc=passt-user@passt.top \
--cc=pasta@ben.woods.am \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).