Bug 49 - pasta does not work with tap-style interface
Summary: pasta does not work with tap-style interface
Status: CONFIRMED
Alias: None
Product: passt
Classification: Unclassified
Component: pasta (show other bugs)
Version: unspecified
Hardware: All Linux
: High feature
Assignee: nobody
URL:
Depends on:
Blocks:
 
Reported: 2023-03-29 09:10 UTC by me
Modified: 2023-06-02 00:10 UTC (History)
2 users (show)

See Also:


Attachments

Description me 2023-03-29 09:10:26 UTC
pasta dies with no external usable interface found, if I try to pass a tap-style interface (eg: wireguard) to my podman container

repro:

podman --network=pasta:-i,wg0
Comment 1 me 2023-03-29 09:14:22 UTC
As a follow up, if I disable the code bit that dies with no external usable interface found. The next problem is that internet is not available within the container (due to no default gateway). 

A workaround is to run with

-i <some-other-iface> --outbound-if4 wg0 --outbound-if6 wg0 --config-net
Comment 2 me 2023-05-22 16:58:48 UTC
It appears that using --map-gw **without** an explicit DNS causes an error in NAT translation in UDP traffic.

See example tcpdump of `dig` here: https://pastebin.com/6Qx10eMj
Comment 3 David Gibson 2023-06-01 02:51:24 UTC
So, I'm guessing this is actually a "tun"-style interface (raw IP), rather than a "tap"-style interface (pretend Ethernet).   IIUC, it's the lack of L2 addressing that's causing the problem here.
Comment 4 Stefano Brivio 2023-06-01 17:27:53 UTC
Sorry, I should have added some context here after discussing this with me@yawnt.com over IRC:

(In reply to David Gibson from comment #3)
> So, I'm guessing this is actually a "tun"-style interface (raw IP), rather
> than a "tap"-style interface (pretend Ethernet).   IIUC, it's the lack of L2
> addressing that's causing the problem here.
Right. There seem to be three remaining issues:

- we need to generate a MAC address if we don't find any on the configured interface, because wg0 doesn't have one. I had a look at RFC 5798 (otherwise unrelated) for ideas about "safe" MAC addresses we could use, but didn't really reach a conclusion. That MAC address isn't exposed, so we could in theory use whatever we want, but I guess we want at least to have something easily identifiable for traffic captures and debugging, so something like 00-00-5E-00-01-01 for IPv4 and 00-00-5E-00-02-01 is probably not a bad idea

- if there's no route at all (obtained with "Table = off" in wg.conf), we should probably create one for the container -- I don't see any problematic aspect in that, anything that fits the address should work

- ...there seems to be an actual issue with DNS query forwarding as reported in comment #2, but I didn't really investigate that.
Comment 5 David Gibson 2023-06-02 00:10:06 UTC
(In reply to Stefano Brivio from comment #4)
> Sorry, I should have added some context here after discussing this with
> me@yawnt.com over IRC:
> 
> (In reply to David Gibson from comment #3)
> > So, I'm guessing this is actually a "tun"-style interface (raw IP), rather
> > than a "tap"-style interface (pretend Ethernet).   IIUC, it's the lack of L2
> > addressing that's causing the problem here.
> Right. There seem to be three remaining issues:
> 
> - we need to generate a MAC address if we don't find any on the configured
> interface, because wg0 doesn't have one.

Well.. in the short term I guess we do.  Longer term we could ourselves use a tun style interface without MAC addresses as the guest facing interface.  Although not with qemu, easily, at least.

> I had a look at RFC 5798 (otherwise
> unrelated) for ideas about "safe" MAC addresses we could use, but didn't
> really reach a conclusion. That MAC address isn't exposed, so we could in
> theory use whatever we want, but I guess we want at least to have something
> easily identifiable for traffic captures and debugging, so something like
> 00-00-5E-00-01-01 for IPv4 and 00-00-5E-00-02-01 is probably not a bad idea

We should be able to use basically anything as long as as the LSB in byte 0 is 0 (unicast) and the second-to-LSB in byte 0 is 1 (locally administered).  I believe that's how qemu generates MACs.

> - if there's no route at all (obtained with "Table = off" in wg.conf), we
> should probably create one for the container -- I don't see any problematic
> aspect in that, anything that fits the address should work

Right... what we need to do with the routing I think intersects with these concepts of "interface bound" or "host bound" modes that I've been talking about.

> - ...there seems to be an actual issue with DNS query forwarding as reported
> in comment #2, but I didn't really investigate that.

Note You need to log in before you can comment on or make changes to this bug.