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
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
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
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.
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.
(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.