How to get apt to access the internet on fresh UTM + Debian on M1 ?

[HenkPoley]

Fairly straightforward question, recipe:

• MacBook Pro M1, connected to WiFi (IPv4 + v6 dual stack on xs4all.nl fiber internet)
• Download utm.dmg: https://github.com/utmapp/UTM/releases/tag/v2.0.25
• Download Debian 10.4 (Xfce) ARM64 from the Gallery: https://mac.getutm.app/gallery/debian-10-4-xfce
• Log in as debian/debian
• Open 'Terminal Emulator'
• Enter sudo apt update, enter the 'debian' password again
  • You will see the error "Temporary failure resolving 'deb.debian.org'" a couple of times.

How do you get apt to access the internet ?

Or is this just not supposed to work at this point ? (I mean, that's also fine, just would be nice to know.)

There is supposed to be some kind of answer in here: #2353 (comment) . But I can't make much sense of it, or at least it doesn't work as handwavingly described. And I'm not sure what I have to do with "slirp" on the guest or the host.

ip a output on the guest:

rtl8139 config (which is enabled, yes):

Notice the nonsense 5 digit "IPv4" (+1?) addresses for DHCP Start and DNS Server.

Installed Wireshark:

• brew install wireshark
• % sudo /opt/homebrew/Cellar/wireshark/3.4.4/bin/tshark | rg example
• On the host open example.com in Safari to check if anything shows up
• On the guest run getent hosts example.com
• Do that last step again

Output:

Capturing on 'Wi-Fi: en0'
1116  1044  10.244460 192.168.178.51 → 192.168.178.1 DNS 71 Standard query 0xaee2 HTTPS example.com
 1045  10.244487 192.168.178.51 → 192.168.178.1 DNS 71 Standard query 0xbfcf AAAA example.com
 1046  10.244553 192.168.178.51 → 192.168.178.1 DNS 71 Standard query 0x43b6 A example.com
 1052  10.263920 192.168.178.1 → 192.168.178.51 DNS 99 Standard query response 0xbfcf AAAA example.com AAAA 2606:2800:220:1:248:1893:25c8:1946
 1053  10.265697 192.168.178.1 → 192.168.178.51 DNS 87 Standard query response 0x43b6 A example.com A 93.184.216.34
 1058  10.343510 192.168.178.1 → 192.168.178.51 DNS 127 Standard query response 0xaee2 HTTPS example.com SOA ns.icann.org
-- ^^ Safari -- vv UTM Guest 1st getent --
1619  1536  27.065703 2001:981:9c35:1:a90c:18e8:bf22:caa2 → 0:0:fd00::2e3a:fdff DNS 91 Standard query 0xcd07 AAAA example.com
1754  1688  37.077824 2001:981:9c35:1:a90c:18e8:bf22:caa2 → 0:0:fd00::2e3a:fdff DNS 91 Standard query 0xcd07 AAAA example.com
1866  1817  47.091914 2001:981:9c35:1:a90c:18e8:bf22:caa2 → 0:0:fd00::2e3a:fdff DNS 91 Standard query 0x90a1 A example.com
1951  1929  57.111205 2001:981:9c35:1:a90c:18e8:bf22:caa2 → 0:0:fd00::2e3a:fdff DNS 91 Standard query 0x90a1 A example.com
-- ^^ UTM Guest 1st getent -- vv UTM Guest 2nd getent --
7299  7260  97.783822 2001:981:9c35:1:a90c:18e8:bf22:caa2 → 0:0:fd00::2e3a:fdff DNS 91 Standard query 0x74ce AAAA example.com
7425  7376 107.799005 2001:981:9c35:1:a90c:18e8:bf22:caa2 → 0:0:fd00::2e3a:fdff DNS 91 Standard query 0x74ce AAAA example.com
7529  7453 117.820364 2001:981:9c35:1:a90c:18e8:bf22:caa2 → 0:0:fd00::2e3a:fdff DNS 91 Standard query 0x5150 A example.com
 7514 127.840715 2001:981:9c35:1:a90c:18e8:bf22:caa2 → 0:0:fd00::2e3a:fdff DNS 91 Standard query 0x5150 A example.com

These requests trickle out very slowly. It takes seconds for the first request to come out after starting getent. And then a few seconds for every next step.

I don't see any 'query response' to the DNS requests coming from UTM.

---

Ah.. I've got it to work, by setting the DNS on the host to 1.1.1.1 and 8.8.4.4.

But this is not a configuration I would like to run in. As this means my laptop won't know many of the local devices. And these third party DNS servers tend to do sneaky things like insert advertisement for unknown domains. Or they will point me to remote CDN. I surely trust XS4ALL's DNS servers more.

---

Maybe the IPv6 address for the DNS server (fd00::2e3a:fdff:feec:7839) gets read wrong? Like it reads 4 bytes of 'borrowed' data in front 0:0: and then drops the :feec:7839.

[HenkPoley]

To fix this on the 'Debian 10.4 (XFCE) ARM64' from the UTM Gallery:

Note that ping/ping6 will not work on UTM guests.

On the guest:

• Login as debian/debian
• At the top right click the little blocky thing that's supposed to look like a network card
• Choose 'Edit Connections...'
• Double click 'Wired Connection 1'
• Go to tab 'IPv4 Settings'
• Switch method to 'Automatic (DHCP) addresses only'
• For DNS Servers enter '1.1.1.1, 8.8.4.4'
• [Save]
• Close the Network Connections window
• Tap the network card icon in the top right and click 'Wired Connection 1' to apply the new configuration.

This will bypass the DNS resolver in UTM's slirp VLAN, and thus bypass your modem and your provider's DNS servers.

[mcaserta]

I can confirm this also works on Debian 10.4 (LXDE) ARM64. Does anyone have any idea why ping doesn't work inside the vm?

[HenkPoley]

To make it work on an Ubuntu Server (ARM64) guest.

Note that ping/ping6 will not work on UTM guests.

Edit /etc/netplan/00-installer-config.yaml to read:

network:
    version: 2
    ethernets:
        enp0s4:
            dhcp4: true
            nameservers:
                addresses: [1.1.1.1, 8.8.4.4]

• sudo netplan try
• sudo netplan apply

This will bypass the DNS resolver in UTM's slirp VLAN, and thus bypass your modem and your provider's DNS servers.

[mlaves]

There's a typo in the last line (addressES). It should be:

                addresses: [1.1.1.1, 8.8.4.4]

[HenkPoley]

Fixed that. Still better would be if we fixed the IPv6 bug in UTM/slirp/.. 😉

[rvgeerligs]

From what I see ICMP goes out OK but is blocked on retour:
debian@debian:$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 10.0.2.2 (10.0.2.2) 0.284 ms 0.239 ms 0.145 ms
2 10.0.2.2 (10.0.2.2) 0.114 ms !N 0.154 ms !N 0.085 ms !N
debian@debian:$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 10.0.2.2 (10.0.2.2) 0.281 ms 0.090 ms 0.084 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *

in Wireshark:
No. Time Source Destination Protocol Length Info
508 66.871765 8.8.8.8 192.168.178.37 ICMP 70 Destination unreachable (Port unreachable)

Also I see NO DNS requests from guest in TCPv4, I do in TCPv6, and the snwer is blocked the same way as the ICMP