Virtualmin repos timing out on IPv6, reachable on IPv4

Virtualmin
1
SYSTEM INFORMATION
OS type and version: Ubuntu 20.x
Webmin version: latest
Virtualmin version: latest
Related products version: -

On a system with only IPv6 access to the internet Virtualmin cannot be installed because the installation script download is timing out on the IPv6 address.
Also the installer itself is unable to download packages on IPv6 for the same reason, I guess.

By enabling IPv4 access as a secondary interface/gateway, things work, but only after attempts to connect over IPv6 time out.

I thought I’d point this out, perhaps the IPv6 config on the Virtualmin servers is not correct.

Thank you.

2

Hmmm…I’m not sure how that’d be a problem on our side. We don’t have IPv6 records for software.virtualmin.com, so your system should be using the IPv4 address (via an IPv6 to IPv4 gateway if your system doesn’t have IPv4).

We do have the ability to enable IPv6 for our mirrors, but it’s never come up as an issue, and I’m pretty sure I’ve tested downloads from it (I test on VMs at vultr and their cheapest VM only has IPv6 unless you pay more). But, I’ll experiment with that when I’m doing VM7 testing.

1 Like
3

Hi Joe…
Here is how it looks on a test server:

root@test:~# wget https://software.virtualmin.com/gpl/scripts/install.sh
--2022-01-27 04:12:57--  https://software.virtualmin.com/gpl/scripts/install.sh
Resolving software.virtualmin.com (software.virtualmin.com)... 64:ff9b::a3ac:a2fe, 163.172.162.254
Connecting to software.virtualmin.com (software.virtualmin.com)|64:ff9b::a3ac:a2fe|:443... failed: Connection timed out.
Connecting to software.virtualmin.com (software.virtualmin.com)|163.172.162.254|:443... failed: Network is unreachable.
root@test:~#
root@test:~# wget http://www.example.com/
--2022-01-27 04:15:38--  http://www.example.com/
Resolving www.example.com (www.example.com)... 2606:2800:220:1:248:1893:25c8:1946, 93.184.216.34
Connecting to www.example.com (www.example.com)|2606:2800:220:1:248:1893:25c8:1946|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1256 (1.2K) [text/html]
Saving to: 'index.html'

index.html                                                  100%[========================================================================================================================================>]   1.23K  --.-KB/s    in 0s

2022-01-27 04:15:38 (85.8 MB/s) - 'index.html' saved [1256/1256]

root@test:~#

And the DNS lookup result:

root@test:~# nslookup software.virtualmin.com
Server:         2606:4700:4700::64
Address:        2606:4700:4700::64#53

Non-authoritative answer:
Name:   software.virtualmin.com
Address: 163.172.162.254
Name:   software.virtualmin.com
Address: 64:ff9b::a3ac:a2fe

It seems the the host software.virtualmin.com has an AAAA record configured…

4

Providers can give you a public IPv6 yet a private IPv4 to allow for NATing only outgoing IPv4 connections. (this is what I do myself)

5

I don’t see how that’s possible. Our name servers have 0 AAAA records.

$ host -t aaaa software.virtualmin.com ns.virtualmin.com
Using domain server:
Name: ns.virtualmin.com
Address: 108.60.199.108#53
Aliases: 

software.virtualmin.com has no AAAA record
1 Like
6

Weird…
Cloudflare & Google’s DNS64 resolvers in Europe are responding with

Name:   software.virtualmin.com
Address: 64:ff9b::a3ac:a2fe

And these same resolvers when accessed from Turkey show that no AAAA record exists.

Can you please check from your location with:
Google’s resolver: 2001:4860:4860::6464
Cloudflare’s resolver: 2606:4700:4700::64

Steps (to whom it may concern):

  1. Run nslookup.
  2. Enter the command: server <DNS_Resolver>
  3. Enter the command: set type=aaaa
  4. Enter the host name to look it up: software.virtualmin.com
7

Dude, it really doesn’t…

; <<>> DiG 9.16.22-Debian <<>> AAAA software.virtualmin.com @dns.google
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6245
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;software.virtualmin.com. IN AAAA

;; AUTHORITY SECTION:
virtualmin.com. 1780 IN SOA ns.virtualmin.com. root.ns.virtualmin.com. 1316044328 10800 3600 604800 38400

;; Query time: 0 msec
;; SERVER: 2001:4860:4860::8844#53(2001:4860:4860::8844)

Suggest you check your setup instead.

8

Thank you for your help in this.
Can you please try the test with the two DNS resolvers I mentioned in my previous reply?

Google’s resolver: 2001:4860:4860::6464
Cloudflare’s resolver: 2606:4700:4700::64

9

While you are right in that those two resolvers show some strange AAAA record, those aren’t the resolvers in use by Google and CF.

Google Public DNS IP addresses

The Google Public DNS IP addresses (IPv4) are as follows:

  • 8.8.8.8
  • 8.8.4.4

The Google Public DNS IPv6 addresses are as follows:

  • 2001:4860:4860::8888
  • 2001:4860:4860::8844

Cloudflare

  • For IPv4: 1.1.1.1 and 1.0.0.1
  • For IPv6: 2606:4700:4700::1111 and 2606:4700:4700::1001

So where you found those addresses beats me.

:memo:  
Found this page explaining some more around that. It mentions something about that specific prefix (64:ff9b::/96).

Still, it has nothing to do with Virtualmin though.

1 Like
10

I found out my mistake. I wasn’t in proper understanding of what DNS64 means.
I thought it was just a resolver that returns proper DNS records over IPv6 (but then it should’ve been named DNS128). But it turns out it is a resolver that synthesizes the IPv6 address of a DNS record if such address did not exist. :man_facepalming:

I was searching for the incorrect term (DNS64) and eventually using unwanted resolvers.

Thank you all for your feed back and assistance :+1:

1 Like
11

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.