VMware Communities
WhiteKnight
Hot Shot
Hot Shot
Jump to solution

IPv6 - when?

By using the new Windows operating systems (Windows 7 and Windows Server 2008 R2) I'd like to switch from the obsolete IPv4 to the new IPv6 Internet Protocol standard.

Is there a roadmap about when VMware Workstation is going to fully support IPv6?

Axel Dahmen



[VMware]: Workstation 17 Pro; --
[host]: Windows 10x64 host; --
[guests]: Windows 10x64, Windows 8x64.
Tags (3)
27 Replies
ziw9Z7AaTGq
Contributor
Contributor
Jump to solution

Thanks for your reply, - everything on the Linux Fedora 33 (x64) guest shows that IPv6 is present and should be working, even though it is not:

 

 

 

 

 

 

 

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:0c:29:aa:22:e8 brd ff:ff:ff:ff:ff:ff
    altname enp2s1
    inet 188.240.187.18/29 brd 188.240.187.23 scope global noprefixroute ens33
       valid_lft forever preferred_lft forever
    inet 10.200.0.5/24 brd 10.200.0.255 scope global dynamic noprefixroute ens33
       valid_lft 85554sec preferred_lft 85554sec
    inet 188.240.187.19/29 brd 188.240.187.23 scope global secondary noprefixroute ens33
       valid_lft forever preferred_lft forever
    inet 188.240.187.20/29 brd 188.240.187.23 scope global secondary noprefixroute ens33
       valid_lft forever preferred_lft forever
    inet 188.240.187.21/29 brd 188.240.187.23 scope global secondary noprefixroute ens33
       valid_lft forever preferred_lft forever
    inet 188.240.187.22/29 brd 188.240.187.23 scope global secondary noprefixroute ens33
       valid_lft forever preferred_lft forever
    inet6 2a00:b900:10a4::4/64 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 2a00:b900:10a4::2/64 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 2a00:b900:10a4:1:c3f3:74f9:3d11:7c36/64 scope global temporary dynamic
       valid_lft 603957sec preferred_lft 85014sec
    inet6 2a00:b900:10a4:1:20c:29ff:feaa:22e8/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 2591891sec preferred_lft 604691sec
    inet6 fe80::20c:29ff:feaa:22e8/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:cd:93:37 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000
    link/ether 52:54:00:cd:93:37 brd ff:ff:ff:ff:ff:ff

 

 

 

 

 

 

 

 

 

 

 

 

 

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 192.168.122.1:53        0.0.0.0:*               LISTEN      746/named
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      746/named
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      651/systemd-resolve
tcp        0      0 10.200.0.5:22           0.0.0.0:*               LISTEN      1536/sshd: /usr/sbi
tcp        0      0 127.0.0.1:953           0.0.0.0:*               LISTEN      746/named
tcp        0      0 0.0.0.0:5355            0.0.0.0:*               LISTEN      651/systemd-resolve
tcp6       0      0 :::80                   :::*                    LISTEN      819/httpd
tcp6       0      0 :::53                   :::*                    LISTEN      746/named
tcp6       0      0 :::443                  :::*                    LISTEN      819/httpd
tcp6       0      0 :::5355                 :::*                    LISTEN      651/systemd-resolve
udp        0      0 192.168.122.1:53        0.0.0.0:*                           1315/dnsmasq
udp        0      0 192.168.122.1:53        0.0.0.0:*                           746/named
udp        0      0 188.240.187.22:53       0.0.0.0:*                           746/named
udp        0      0 188.240.187.21:53       0.0.0.0:*                           746/named
udp        0      0 188.240.187.20:53       0.0.0.0:*                           746/named
udp        0      0 188.240.187.19:53       0.0.0.0:*                           746/named
udp        0      0 10.200.0.5:53           0.0.0.0:*                           746/named
udp        0      0 188.240.187.18:53       0.0.0.0:*                           746/named
udp        0      0 127.0.0.1:53            0.0.0.0:*                           746/named
udp        0      0 127.0.0.53:53           0.0.0.0:*                           651/systemd-resolve
udp        0      0 0.0.0.0:67              0.0.0.0:*                           1315/dnsmasq
udp        0      0 127.0.0.1:323           0.0.0.0:*                           691/chronyd
udp        0      0 0.0.0.0:5355            0.0.0.0:*                           651/systemd-resolve
udp6       0      0 :::53                   :::*                                746/named
udp6       0      0 ::1:323                 :::*                                691/chronyd
udp6       0      0 :::5355                 :::*                                651/systemd-resolve

 

 

 

 

 

 

 

...but IPv6 requests to the virtual guest are not working (neither the root servers for DNS, nor zonemaster.net, are able to connect to my machine via IPv6).

 

I am currently using a Bridged Connection to the host and know for a fact that IPv6 is fully working on the host; so bridging to the host should, I would have thought, have meant that my guest system, too, would have full IPv6 connectivity.

 

Also, the only firewall on the guest system is Config Server Firewall, and I have eliminated that as the problem. Further, I have enabled the NAT IPv6 side of things, too (2a00:b900:10a4::/48) and can confirm that it made not the slightest bit of difference, regardless of whether I was using the bridged or the NAT adaptor.

 

Just to confuse things further, the Windows 7 (x64) guest has IPv6 which is working perfectly (test-ipv6.com):

 

 

 

 

 Test your IPv6 connectivity.

    For the Help Desk
    Summary Tests Run Share Results / Contact Other IPv6 Sites 

	Your IPv4 address on the public Internet appears to be 96.10.21.14

	Your IPv6 address on the public Internet appears to be 2a00:b900:10a4:1:6d0d:55e5:9f06:7c02

	Your Internet Service Provider (ISP) appears to be AS-IS

	Since you have IPv6, we are including a tab that shows how well you can reach other IPv6 sites. [more info]

	HTTPS support is now available on this site. [more info]

	Your DNS server (possibly run by your ISP) appears to have IPv6 Internet access.
Your readiness score
10/10

 

 

 

...so it would appear that there is some issue between VMWare Workstation 16 and Linux, Fedora 33 (x64), and that IPv6 may be supported for Windows, but evidently not for Linux.

Reply
0 Kudos
ziw9Z7AaTGq
Contributor
Contributor
Jump to solution

Thanks for your reply, - everything on the Linux Fedora 33 (x64) guest shows that IPv6 is present and working:

 

 

 

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:0c:29:aa:22:e8 brd ff:ff:ff:ff:ff:ff
    altname enp2s1
    inet 188.240.187.18/29 brd 188.240.187.23 scope global noprefixroute ens33
       valid_lft forever preferred_lft forever
    inet 10.200.0.5/24 brd 10.200.0.255 scope global dynamic noprefixroute ens33
       valid_lft 85554sec preferred_lft 85554sec
    inet 188.240.187.19/29 brd 188.240.187.23 scope global secondary noprefixroute ens33
       valid_lft forever preferred_lft forever
    inet 188.240.187.20/29 brd 188.240.187.23 scope global secondary noprefixroute ens33
       valid_lft forever preferred_lft forever
    inet 188.240.187.21/29 brd 188.240.187.23 scope global secondary noprefixroute ens33
       valid_lft forever preferred_lft forever
    inet 188.240.187.22/29 brd 188.240.187.23 scope global secondary noprefixroute ens33
       valid_lft forever preferred_lft forever
    inet6 2a00:b900:10a4::4/64 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 2a00:b900:10a4::2/64 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 2a00:b900:10a4:1:c3f3:74f9:3d11:7c36/64 scope global temporary dynamic
       valid_lft 603957sec preferred_lft 85014sec
    inet6 2a00:b900:10a4:1:20c:29ff:feaa:22e8/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 2591891sec preferred_lft 604691sec
    inet6 fe80::20c:29ff:feaa:22e8/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:cd:93:37 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000
    link/ether 52:54:00:cd:93:37 brd ff:ff:ff:ff:ff:ff

 

 

 

 

 

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 192.168.122.1:53        0.0.0.0:*               LISTEN      746/named
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      746/named
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      651/systemd-resolve
tcp        0      0 10.200.0.5:22           0.0.0.0:*               LISTEN      1536/sshd: /usr/sbi
tcp        0      0 127.0.0.1:953           0.0.0.0:*               LISTEN      746/named
tcp        0      0 0.0.0.0:5355            0.0.0.0:*               LISTEN      651/systemd-resolve
tcp6       0      0 :::80                   :::*                    LISTEN      819/httpd
tcp6       0      0 :::53                   :::*                    LISTEN      746/named
tcp6       0      0 :::443                  :::*                    LISTEN      819/httpd
tcp6       0      0 :::5355                 :::*                    LISTEN      651/systemd-resolve
udp        0      0 192.168.122.1:53        0.0.0.0:*                           1315/dnsmasq
udp        0      0 192.168.122.1:53        0.0.0.0:*                           746/named
udp        0      0 188.240.187.22:53       0.0.0.0:*                           746/named
udp        0      0 188.240.187.21:53       0.0.0.0:*                           746/named
udp        0      0 188.240.187.20:53       0.0.0.0:*                           746/named
udp        0      0 188.240.187.19:53       0.0.0.0:*                           746/named
udp        0      0 10.200.0.5:53           0.0.0.0:*                           746/named
udp        0      0 188.240.187.18:53       0.0.0.0:*                           746/named
udp        0      0 127.0.0.1:53            0.0.0.0:*                           746/named
udp        0      0 127.0.0.53:53           0.0.0.0:*                           651/systemd-resolve
udp        0      0 0.0.0.0:67              0.0.0.0:*                           1315/dnsmasq
udp        0      0 127.0.0.1:323           0.0.0.0:*                           691/chronyd
udp        0      0 0.0.0.0:5355            0.0.0.0:*                           651/systemd-resolve
udp6       0      0 :::53                   :::*                                746/named
udp6       0      0 ::1:323                 :::*                                691/chronyd
udp6       0      0 :::5355                 :::*                                651/systemd-resolve

 

 

 

...but IPv6 requests to the virtual guest are not working (neither the root servers for DNS, nor zonemaster.net, are able to connect to my machine via IPv6).

 

I am currently using a Bridged Connection to the host and know for a fact that IPv6 is fully working on the host; so bridging to the host should, I would have thought, have meant that my guest system, too, would have full IPv6 connectivity.

 

Also, there is only Config Server Firewall on the guest and I have eliminated that as the problem.

Reply
0 Kudos
dariusd
VMware Employee
VMware Employee
Jump to solution

Hi again @ziw9Z7AaTGq,

(Responding to a post which now seems to be deleted.)

If you are using Bridged mode, VMware Workstation really should be forwarding the network packets directly from the host device to the guest and vice-versa.  The only part of VMware Workstation which truly interacts with bridged IPv6 packets is the virtual E1000[e]/vmxnet3 NIC's IP checksum offload feature.

I would next try using Wireshark or tcpdump or similar inside the guest to examine the packets arriving at the guest's network interface and to examine any response issued by the VM.  Be mindful that Wireshark in the guest might indeed report IP checksum errors if the guest OS is configured to use IP checksum offload for its network device; This is normal and expected because Wireshark will only see outgoing packets prior to the IP checksum being computed by the virtual hardware.  Wireshark on the host should see all IPv6 packets with the correct computed checksum.

Reply
0 Kudos
ziw9Z7AaTGq
Contributor
Contributor
Jump to solution

Thanks for the further advice on this; unfortunately it is not possible to make wireshark work on Fedora command line.

 

It looks as though the only way to fix this issue is to find a programmer somewhere who can rewrite the VMWare binaries and create a working solution (as usual, paid support does not seem to be available from VMware unless you are a corporate customer).

 

Incidentally, it was not myself who deleted the previous post (more of the usual "solution" to dealing with user issues for things that the software company would rather not acknowledge?).

 

- ziw9Z7AaTGq

Reply
0 Kudos
dariusd
VMware Employee
VMware Employee
Jump to solution

From the command line, you will probably want tshark (which is the command-line interface to wireshark).  What problem are you encountering when you run it?  I am quite certain that it will be possible to get wireshark/tshark working on Fedora, we just have to figure out how... you might need to set up the appropriate permissions for it to work, for example.

P.S. I'm a VMware engineer and I've fixed networking issues in the past (although I'm not on the networking team).  Your easiest path to getting things fixed is to work with me and figure out what's going wrong. 🙂

Reply
0 Kudos
wila
Immortal
Immortal
Jump to solution

ziw9Z7AaTGq said:
"Incidentally, it was not myself who deleted the previous post (more of the usual "solution" to dealing with user issues for things that the software company would rather not acknowledge?)."

FYI, we do not delete posts here in this forum. The only posts that are removed are the ones that are clear spam or abuse.
In that case the posts are moved to a holding area and your post was not there (I checked).
Not saying that it cannot happen, but it is being severely frowned upon by everybody in the moderator team and certainly not policy.

--
Wil

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
Reply
0 Kudos
ziw9Z7AaTGq
Contributor
Contributor
Jump to solution

Thanks for persisting with this: tshark does work, but it seems to run like tail -f, so I broke the cycle and had a look at the available data, in which I could see that the IPv6 subnet is definitely being used, but not the addresses assigned for DNS NS or AAAA.

 

It seems that IPv6 connectivity works, but not for anything that involves outgoing and incoming requests, so it will work fine for a Windows guest and IPv6 browsing, but fails completely for anything involving a DNS or HTTPD server. This gives a better idea of the problem, but is not at all helpful because there are no options to further tweak bridged connections and it does not appear to be possible to address the problem via modifications to the adapter on the host operating system side, either.

 

I am currently seeing if I can make sense of the configuration options given in tshark --help and via the reference link you provided. I have just tried tshark -G ipv6, but that is not working despite ipv6 supposedly being a recognised protocol.

 

@wila: good to know, - thanks, - it would seem that it is not just my server that has Gremlins...

 

- ziw9Z7AaTGq

Reply
0 Kudos
ianbennett1
Contributor
Contributor
Jump to solution

It is now October 2021. When can we get VMWorkstation to have IPv6 as an option for our network setup. So we can we see that option and learn how to do this for when we are required to set it up in the workplace?

This has been around now for over 10 years. Many firms are now looking to migrate to IPv6 and many of us want to be proactive in being part of this.

Reply
0 Kudos