On Thu, 30 Jan 2025 10:05:14 +0000 Prafulla Giri <prafulla.giri(a)protonmail.com> wrote:I didn't have auditd installed on Debian and installed it, and running everything with the default auditd config (with my Apparmor disabled for passt, as mentioned previously) does not result in anything. Do I have to configure auditd manually? Any pointers on that, please?No, the default configuration is just fine. But you should re-enable AppArmor for passt so that we can see meaningful messages in the logs.$ passt -f -d # on Debian Testing/Trixie 0.0016: No interfaces with usable IPv6 routes 0.0017: Failed to detect external interface for IPv6 0.0028: UNIX domain socket bound at /tmp/passt_1.socket 0.0029: Template interface: enp1s0 (IPv4) 0.0029: MAC: 0.0029: host: 9a:55:9a:55:9a:55 0.0029: NAT to host 127.0.0.1: 192.168.100.1 0.0029: DHCP: 0.0029: assign: 192.168.100.157 0.0029: mask: 255.255.255.0 0.0029: router: 192.168.100.1 0.0029: DNS: 0.0029: 192.168.100.1So, judging from this configuration, it looks like we advertise to the guest (via DHCP) 192.168.100.1 as resolver (copied from the host), and when we receive packets from the guest for 192.168.100.1, we'll re-map them to the host. Nothing strange so far, systemd-resolved is running on the host, it should get our queries and reply to them.$ cat /etc/resolv.conf # On Debian Trixie # This is /run/systemd/resolve/resolv.conf managed by man:systemd-resolved(8). [...] nameserver 192.168.100.1 search . $ cat /etc/resolv.conf # On a Debian 11 OS # Generated by NetworkManager nameserver 192.168.100.1 Also the output of `resolvectl status` for good measure: # On Fedora 41 Global Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub Link 2 (wlp0s20f3) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 192.168.100.1 DNS Servers: 192.168.100.1 # On Debian Trixie Global Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: uplink Link 2 (enp1s0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported DNS Servers: 192.168.100.1 Default Route: yesEverything as expected here, I don't see any obvious reason why systemd-resolved should discard our queries.The log from Debian Trixie host for VM1: passt 0.0~git20250121.4f2c8e7-1: /usr/bin/passt.avx2 (6428) 0.0017: info: No interfaces with usable IPv6 routes 0.0029: info: UNIX domain socket bound at /run/user/1000/libvirt/qemu/run/passt/2-vm1-net0.socket 0.0030: info: Template interface: enp1s0 (IPv4) 0.0030: info: MAC: 0.0030: info: host: 9a:55:9a:55:9a:55 0.0030: info: NAT to host 127.0.0.1: 192.168.100.1 0.0030: info: DHCP: 0.0031: info: assign: 192.168.100.157 0.0031: info: mask: 255.255.255.0 0.0031: info: router: 192.168.100.1 0.0031: info: DNS: 0.0031: info: 192.168.100.1 0.0031: info: DNS search list: 0.0031: info: . 0.0066: info: You can now start qemu (>= 7.2, with commit 13c6be96618c): 0.0066: info: kvm ... -device virtio-net-pci,netdev=s -netdev stream,id=s,server=off,addr.type=unix,addr.path=/run/user/1000/libvirt/qemu/run/passt/2-vm1-net0.socket 0.0066: info: or qrap, for earlier qemu versions: 0.0066: info: ./qrap 5 kvm ... -net socket,fd=5 -net nic,model=virtio 0.0617: info: accepted connection from PID 0 38.6257: info: DHCP: offer to discover 38.6257: info: from 52:54:00:a0:e1:7c 38.6471: info: DHCP: ack to request 38.6471: info: from 52:54:00:a0:e1:7c 451.4989: info: Client connection closed, exitingUnfortunately libvirt doesn't let us enable more verbose logging. I hoped to see DNS queries there, but without --debug given to passt, that won't work. Another idea: pasta(1) does the same job as passt(1) (it's the same code and same binary) and it's intended for containers, but it has a stand-alone mode that can probably help us to debug this, because it's a network namespace that will look like your guest, and it can also take packet captures. What happens if you run: pasta --config-net --trace --pcap /tmp/dns.pcap -- nslookup fsf.org ? If the query fails (that's what I would expect), can you please attach the output and the resulting packet capture? Note that the packet capture might have sensitive data, please have a look at it with e.g. Wireshark/tshark before sharing it. By the way, if you run this without specifying any command, for example: pasta --config-net --pcap /tmp/dns.pcap you will get a shell where you can play around in a separate network namespace and with a network stack that looks pretty much the same as passt for your guest. -- Stefano