# IPv6 with VBox Bridged to wireless/wlan adapter

## SunMar

Hi,

Having some IPv6 issues. I'm running Gentoo in a Virtualbox VM using Bridged networking. On my host computer IPv6 works fine (passes all check on http://test-ipv6.com/), but in Gentoo it times out. DNS seems to be working as IPv6 hosts resolve fine, but fetching data (ping, wget) all timeout. Pinging ::1 works, so that seems in order.

Something that seems strange to me (but maybe that's how it's supposed to be), is that I have a lot of ipv6 attached to my interface. Running ip -6 addr returns:

```

2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000

    inet6 8006:----:----:----:----:----:----:----/64 scope global deprecated dynamic 

       valid_lft 7032sec preferred_lft 0sec

    inet6 8006:----:----:----:----:----:----:----/64 scope global deprecated dynamic 

       valid_lft 7032sec preferred_lft 0sec

    inet6 8006:----:----:----:---:----:----:----/64 scope global deprecated dynamic 

       valid_lft 7032sec preferred_lft 0sec

    inet6 8006:----:----:----:----:----:----:----/64 scope global deprecated dynamic 

       valid_lft 7032sec preferred_lft 0sec

    inet6 8006:----:----:----:----:----:----:----/64 scope global deprecated dynamic 

       valid_lft 7032sec preferred_lft 0sec

    inet6 8006:----:----:----:----:----:----:----/64 scope global deprecated dynamic 

       valid_lft 7032sec preferred_lft 0sec

    inet6 8006:----:----:----:----:----:----:----/64 scope global deprecated dynamic 

       valid_lft 7032sec preferred_lft 0sec

    inet6 8006:----:----:----:----:----:----:----/64 scope global deprecated dynamic 

       valid_lft 7032sec preferred_lft 0sec

    inet6 8006:----:----:----:----:----:----:----/64 scope global deprecated dynamic 

       valid_lft 7023sec preferred_lft 0sec

    inet6 8006:----:----:----:----:----:----:----/64 scope global deprecated dynamic 

       valid_lft 7022sec preferred_lft 0sec

    inet6 8006:----:----:----:----:----:----:----/64 scope global deprecated dynamic 

       valid_lft 7030sec preferred_lft 0sec

    inet6 8006:----:----:----:----:----:----:----/64 scope global deprecated dynamic 

       valid_lft 7029sec preferred_lft 0sec

    inet6 2001:---:---:-:----:----:----:---/64 scope global dynamic 

       valid_lft 4273sec preferred_lft 3432sec

    inet6 8006:----:----:----:----:----:----:----/64 scope global deprecated dynamic 

       valid_lft 6067sec preferred_lft 0sec

    inet6 8006:----:----:----:---:----:----:----/64 scope global deprecated dynamic 

       valid_lft 6319sec preferred_lft 0sec

    inet6 fe80::---:----:----:----/64 scope link 

       valid_lft forever preferred_lft forever

    inet6 fe80::----:----:----:----/64 scope link 

       valid_lft forever preferred_lft forever

```

After some searching I find some things that suggested this was due to privacy networking being enabled, but use_tempaddr is not enabled on any interface:

```

# find /proc/sys/net/ipv6 -name use_tempaddr -exec echo -n "{}: " \; -exec cat {} \;

/proc/sys/net/ipv6/conf/all/use_tempaddr: 0

/proc/sys/net/ipv6/conf/default/use_tempaddr: 0

/proc/sys/net/ipv6/conf/enp0s3/use_tempaddr: 0

/proc/sys/net/ipv6/conf/lo/use_tempaddr: -1

# grep use_tempaddr /etc/sysctl.conf

...(no results)...

```

A ping6 on all addresses (execpt for the fe80:: ones) works.

Also I do not have any firewall rules setup that could be dropping the packets:

```

# iptables -L

Chain INPUT (policy ACCEPT)

target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)

target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination         

# ip6tables -L

Chain INPUT (policy ACCEPT)

target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)

target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination         

```

I'm stuck on diagnosing this issue. Does anyone have some ideas on where to look on why I have so many ipv6 addresses and/or where to look futher on why connections are timing out?Last edited by SunMar on Sun Nov 23, 2014 9:54 pm; edited 1 time in total

----------

## Ant P.

Those 8006: addresses look very odd, I've never seen those before. Maybe Virtualbox is adding them? Public IPs usually begin with 2 and private ones always begin with f.

You might want to check your routing tables are correct - the VM needs a 2000::/3 route to get to the internet, and any routers on your LAN also need to know how to reach the VM.

----------

## skaloo

All those addresses are different ? As you masked the whole numbers it's kinda hard to see details (you could hide only the network prefix aka higher bytes, that might help diagnosing - see my example below).

As you didn't say how your interfaces get their IP, and seeing the result (all those addresses), I'd suspect a simple configuration problem on that part.

Do you use IP6 autoconf with delegation ? do you use a local DHCP6 ?

A simple autoconf with delegation on a gentoo box looks like this:

```
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536

    inet6 ::1/128 scope host

       valid_lft forever preferred_lft forever

7: br0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500

    inet6 2a02:----:----:----:82ee:73ff:fe63:ee70/64 scope global dynamic

       valid_lft 604434sec preferred_lft 604434sec

    inet6 fe80::82ee:73ff:fe63:ee70/64 scope link

       valid_lft forever preferred_lft forever
```

AKA one link-local address (FE80:xxxx) and one global address.

As about the routing table, autoconf wouldn't give a direct route to the world, it gives a default route to the link-local address of the router. AKA something like:

```
2a02:----:----:----::/64 dev br0  proto kernel  metric 256  expires 604685sec

fe80::/64 dev br0  proto kernel  metric 256

ff00::/8 dev br0  metric 256

default via fe80::327e:cbff:fe67:60b0 dev br0  proto ra  metric 1024  expires 1685sec
```

Note that IP6 autoconf uses ICMPv6 to work. You shown that your firewall is not blocking on the gentoo system itself, but what about firewall on other parts of the network ? w/o more details on your network, we can't be sure.

----------

## SunMar

Thanks for the reply!

Sorry for forgetting to include the configuration setup. My router is a FRITZ!Box that runs a DHCPv6 in "Only assign DNS server" mode, I've tried enabling assign IPv6 prefix (IA_PD) and IPv6 address (IA_NA) but that didn't help. My host system seems to also have those weird addresses so it seems like the many addresses is unrelated to IPv6 not working.

My current ip -6 addr now looks like:

```

# ip -6 addr

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 

    inet6 ::1/128 scope host 

       valid_lft forever preferred_lft forever

2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000

    inet6 8006:----:----:----:ca7d:2864:a365:5c75/64 scope global deprecated dynamic 

       valid_lft 7082sec preferred_lft 0sec

    inet6 8006:----:----:----:8f4f:2637:8d63:523/64 scope global deprecated dynamic 

       valid_lft 7082sec preferred_lft 0sec

    inet6 8006:----:----:----:b6a9:b89a:46f8:a65b/64 scope global deprecated dynamic 

       valid_lft 7180sec preferred_lft 0sec

    inet6 8006:----:----:----:7c43:193d:90c3:264f/64 scope global deprecated dynamic 

       valid_lft 7180sec preferred_lft 0sec

    inet6 8011:----:----:----:1006:7733:c620:cf54/64 scope global deprecated dynamic 

       valid_lft 7171sec preferred_lft 0sec

    inet6 8006:----:----:----:af0e:62ee:b54c:cd1/64 scope global deprecated dynamic 

       valid_lft 7171sec preferred_lft 0sec

    inet6 8006:----:----:----:f61f:ec17:2a1c:3f5e/64 scope global deprecated dynamic 

       valid_lft 7179sec preferred_lft 0sec

    inet6 8006:----:----:----:2009:2745:b76f:a79a/64 scope global deprecated dynamic 

       valid_lft 7178sec preferred_lft 0sec

    inet6 4006:----:----:----:5226:bc1b:317f:2862/64 scope global deprecated dynamic 

       valid_lft 7150sec preferred_lft 0sec

    inet6 4006:----:----:----:532c:9e53:edfe:5657/64 scope global deprecated dynamic 

       valid_lft 7105sec preferred_lft 0sec

    inet6 2001:----:----:----:9842:30a3:e68f:85f/64 scope global dynamic 

       valid_lft 7180sec preferred_lft 3580sec

    inet6 fe80::a00:27ff:fe2a:a4f2/64 scope link 

       valid_lft forever preferred_lft forever

```

And my routes:

```

# ip -6 route

2001:----:----:----::/64 dev enp0s3  proto kernel  metric 2  mtu 1492

4006:----:----:----::/64 dev enp0s3  proto kernel  metric 2  mtu 1492

4006:----:----:----::/64 dev enp0s3  proto kernel  metric 2  mtu 1492

8006:----:----:----::/64 dev enp0s3  proto kernel  metric 2  mtu 1492

8006:----:----:----::/64 dev enp0s3  proto kernel  metric 2  mtu 1492

8006:----:----:----::/64 dev enp0s3  proto kernel  metric 2  mtu 1492

8006:----:----:----::/64 dev enp0s3  proto kernel  metric 2  mtu 1492

8006:----:----:----::/64 dev enp0s3  proto kernel  metric 2  mtu 1492

8006:----:----:----::/64 dev enp0s3  proto kernel  metric 2  mtu 1492

8006:----:----:----::/64 dev enp0s3  proto kernel  metric 2  mtu 1492

8011:----:----:----::/64 dev enp0s3  proto kernel  metric 2  mtu 1492

fe80::/64 dev enp0s3  proto kernel  metric 256 

ff00::/8 dev enp0s3  metric 256 

default via fe80::2665:11ff:fe96:840c dev enp0s3  metric 2  mtu 1492

```

This is also what is shown when the network interface is brought up (usually it immediately adds some extra addresses, but this time they showed up later):

```

 * Bringing up interface enp0s3

 *   config_enp0s3 not specified; defaulting to DHCP

 *   dhcp

 *     Running dhcpcd ...

dhcpcd[2507]: version 6.4.7 starting

dhcpcd[2507]: DUID 00:01:00:01:1a:a3:a1:1d:08:00:27:2a:a4:f2

dhcpcd[2507]: enp0s3: IAID 27:2a:a4:f2

dhcpcd[2507]: enp0s3: rebinding lease of 192.168.178.39

dhcpcd[2507]: enp0s3: soliciting an IPv6 router

dhcpcd[2507]: enp0s3: Router Advertisement from fe80::2665:11ff:fe96:840c

dhcpcd[2507]: enp0s3: adding address 2001:----:----:----:9842:30a3:e68f:85f/64

dhcpcd[2507]: enp0s3: adding route to 2001:----:----:----::/64

dhcpcd[2507]: enp0s3: adding default route via fe80::2665:11ff:fe96:840c

dhcpcd[2507]: enp0s3: requesting DHCPv6 information

dhcpcd[2507]: forked to background, child pid 2555  [ ok ]

 *     received address  [ ok ]

```

I can find all the extra addresses that weren't added at boot in /var/log/messages, for example:

```

Nov 23 12:49:16 ---- dhcpcd[2555]: enp0s3: Router Advertisement from fe80::2665:11ff:fe96:840c

Nov 23 12:49:16 ---- dhcpcd[2555]: enp0s3: adding address 8006:----:----:----:ca7d:2864:a365:5c75/64

Nov 23 12:49:16 ---- dhcpcd[2555]: enp0s3: adding route to 8006:----:----:----::/64

```

For comparison, an ipconfig from the Windows host system:

```

Windows IP Configuration

Wireless LAN adapter Wireless Network Connection:

   Connection-specific DNS Suffix  . : fritz.box

   IPv6 Address. . . . . . . . . . . : 2001:----:----:----:d4fd:4e15:3841:65b9

   Temporary IPv6 Address. . . . . . : 2001:----:----:----:15bb:f624:b2d7:9b74

   Temporary IPv6 Address. . . . . . : 2001:----:----:----:6904:ce6c:281b:b7d8

   IPv6 Address. . . . . . . . . . . : 8006:d4b:----:----:d4fd:4e15:3841:65b9

   IPv6 Address. . . . . . . . . . . : 8006:8fd1:----:----:d4fd:4e15:3841:65b9

   Link-local IPv6 Address . . . . . : fe80::d4fd:4e15:3841:65b9%15

   IPv4 Address. . . . . . . . . . . : 192.168.178.23

   Subnet Mask . . . . . . . . . . . : 255.255.255.0

   Default Gateway . . . . . . . . . : fe80::2665:11ff:fe96:840c%15

                                       192.168.178.1

```

The host system gets addresses that are in the same prefix, but the suffixes differ so there seems to be no conflict there.

On the host system (Windows) IPv6 works fine, the host system is connected to the network via a wireless AP that is in turn connect by wire to the FRITZ!Box router. The wireless AP does not have a firewall setup or a dhcp server, but I would assume that if the wireless AP is the issue the VM's host system also wouldn't be able to use IPv6. The host system only has the default Windows Firewall running.

Is there any more information that I could provide, or checks to do? Unfortunately I don't know much (or rather anything at all) about IPv6 so I don't even know what I should be looking at to see where the possible problem could be  :Sad: .

Sincerely,

SunMar.

----------

## skaloo

Having the host info helps a lot, and also clearing up my eyes :p I hadn't noticed the 2001:: line in your first post...

Anyway seeing that 2001:: line + the default route of the linux pointing out to the same default gateway as the windows host (fe80::2665:11ff:fe96:840c -> link-local address of your router) kinda prooves the configuration itself should be good, despite all the many 'odd' 8006:: lines (those could be something specific to your provider).

So as far as I can tell, you get a proper configuration on the gentoo box, according to what you get on the windows host.

You should be able to ping between them both and the router using either the link-local or the global addresses.

on gentoo: 

```
ping6 -I enp0s3 fe80::2665:11ff:fe96:840c
```

 should ping your router (note it's required to indicate the interface to use when pinging using link-local addresses)

```
ping6 2001:----:----:----:d4fd:4e15:3841:65b9
```

 should ping your windows host; you could also use the windows link-local address of course, both should be strictly identical for the purpose of this test.

I'm not sure how VirtualBox virtual interfaces work, but it's possible that your windows host firewall is the origin of the problem. If the pings do not pass, or if they pass but TCP (http or other stuff) doesn't, I suspect your windows host's firewall to be blocking them. If VirtualBox is any similar to VMWare when it comes to virtual interfaces on the (windows) host, you could simply exclude the whole virtual interface from the windows firewall config, and setup some firewall on the linux itself if you need it (keep in mind that 'global' IP6 addresses are *really* global, aka the world can see you as soon as you can see it).

----------

## szatox

Is your real, physical network interface included in that bridge for virtualbox?

It should, if you want your VMs to be bridged to the internet (connections will be indeppendent of your VM host) - make sure it's a bridge that has it's IP address assigned

It should not, if you want your VMs to be routed to the internet (separate VLAN, similar to hiding them behind hardware router/firewall)

----------

## SunMar

I can ping6 both the Windows host and the router. Also when I go to the router's admin panel via its ipv6 address (http://[fd00::2665:11ff:fe96:840c]) it connects and loads correctly with nothing seeming to be blocking things along the way. I can also ping6 www.google.com and it correctly looks up the ipv6 address so DNS from the router also works, it just doesn't receive any replies. I can even ping6 the Windows host by using its internal hostname instead of its ip.

The bridge mode of VirtualBox works via a net filter driver (https://www.virtualbox.org/manual/ch06.html#network_bridged), it links to a specific network adapter on the host system and intercepts and injects data from/into it. This from my understanding bypasses things like Windows Firewall and also causes the VM to be seen on the network as a separate computer with its own MAC-address, so that other computers on the network can connect to it as if it were just another client on the network. A VirtualBox bug (or missing feature, however you want to see it) related to Bridged mode in combination with IPv6 and a wireless adapater on the host system (https://www.virtualbox.org/ticket/5503) appears to cause the same issues I described here, but that bug was closed a couple versions ago. Maybe not all issues were fixed, it at least looks like a good candidate to be causing the issues since from your replies I gather there don't appear to be configuration or routing problems in Gentoo.

Thanks for all the help and information!  :Smile:  I'll go check with the VirtualBox bug tracker now to see if I can find a solution there (or confirm that this hasn't been fixed yet). If I find a solution (or confirmation) I'll update here.

Extra thanks for the warning about the global address, I hadn't realised that but thankfully my router makes internal hosts unreachable from the internet by default, so that's covered. Once I get this all working I'll do some more advanced firewall configuration.

----------

## skaloo

 *SunMar wrote:*   

> I can ping6 both the Windows host and the router. Also when I go to the router's admin panel via its ipv6 address (http://[fd00::2665:11ff:fe96:840c]) it connects and loads correctly with nothing seeming to be blocking things along the way. I can also ping6 www.google.com and it correctly looks up the ipv6 address so DNS from the router also works, it just doesn't receive any replies. I can even ping6 the Windows host by using its internal hostname instead of its ip.

  All that is pretty much enough to be sure IPv6 works properly on your internal network. The only other test that could be done is pinging your router on its global address (most likely to be 2001:----:----:----::1, you will probably find it somewhere in the router configuration interface). Note that it may be blocked by the router purposedly though, depending on its config, so this specific ping working or not won't give too much info (well 'working' will prooves it's ok while 'not working' would not be so precise as we can conclude anything from it).

About your last sentence: that's normal, unless tweaked through registry, Win7 tries to use IP6 above IP4 when it has it.

My whole paragraph about windows firewall & VirtualBox interfaces was only relevent if the pings didn't work, but they do. More specifically, the ping to the router is the one that allows me to say: your gentoo talk to the router and the router replies. So there is no breakage up to that point, specialy as you can also use the router web interface. I don't think the bug you talked about is responsible for the problem either, for the same reason.

I think the router itself is blocking your comms, specialy as you said:

 *Quote:*   

> my router makes internal hosts unreachable from the internet by default

 

I didn't think about that first, because in france, we mostly get (half-crappy) routers from the providers (often with no possibility to use anything else) that offer minimal functionalities and that generaly don't do that, but it's possible your router has some advanced IP6 firewalling built-in, that is responsible for the problem one way or another.

As a warning, I would say that even if routers will easily isolate your LAN (using NAT) from the world in IPv4, it doesn't work that way in the IPv6 world, and being isolated on IPv4 doesn't mean you are on IPv6, technicaly unless your router actualy does some proper firewalling, activating IPv6 basicaly opens all your hosts to the world and each of them then requires its own proper-configured firewall; that is if your network is auto-configured using the IPv6 internal protocols (search the web for 'IPv6 prefix delegation' for details). So I suggest you ensure you're really safe  :Smile:  (feel free to ask if you're unsure how to check, better safe than sorry)

----------

## UberLord

 *SunMar wrote:*   

> 
> 
> I can find all the extra addresses that weren't added at boot in /var/log/messages, for example:
> 
> ```
> ...

 

That 8006 is really bizarre. The fact that both dhcpcd and Windows pickup on it is interesting.

My question is this - does dhcpcd assign the SAME range of IPv6 addresses on a Router Advertisement, or do they change each time?

If they change each time and you have the stock dhcpcd.conf, you'll have SLAAC privacy enabled. Try commenting out the SLAAC line and they should become stable (should be anyway with private, but we can debug that later)

You may wish to reboot between config changes to clear the old addresses out. Ensure you get a few RA's before starting to debug. From a technical level, I'd be interested in seeing a full tcpdump or wireshark trace, showing the RA's as well.

Email privately to roy@marples.name if you want to keep that off here.

----------

## skaloo

Oh, that post from UberLord above reminded me I wanted to comment on the dhcp part: dhcp is actualy not required for IPv6. IPv6 autoconf system will use router advertisement and/or other internal IPv6 stuff directly and assigns a global address using the found prefix (if any was found), and a link-local address in addition to that (always); you already have that part covered as we saw earlier. All this is built in the kernel and provided you don't disable IPv6 on the interfaces using sysctl tweaks, it will be done as soon as IPv6 is enabled in the kernel, no matter what, no daemon or other external tool is required. To check wether all this is properly setup you can go view details in /proc/sys/net/ipv6/conf where you'll find various entries for each of your interface (the ones important here are 'disable_ipv6', 'autoconf', 'accept-ra', ...). I assume dhcp won't really interfere (as shown in your starting log, mostly probably because it doesn't find a true dhcp6 server and falls back to autoconf I'd say), but it's not necessary.

 *Quote:*   

> That 8006 is really bizarre. The fact that both dhcpcd and Windows pickup on it is interesting.

 

Yeah, the fact windows also got them is what made me say they're probably something specific to the ISP (and/or router), and are probably not the source of the issue.

----------

## UberLord

 *skaloo wrote:*   

> Oh, that post from UberLord above reminded me I wanted to comment on the dhcp part: dhcp is actualy not required for IPv6.

 

Well, yes and no sadly.

Recent RFC's allow DNS options to be broadcast in the RA.

However, Windows and I think OSX do not support this so DHCP is still required for an IPv6 only environment which those OS's present.

----------

## skaloo

Well, yes, taht's true, I should have precised my mind: not required for an address assignment and the default routes.

----------

## SunMar

@skaloo:

I can ping the global address of the router, and even reach its configuration page via http using the global 2001 ip, so there's no blocking there.

I found it hard to phrase that sentence about being unreachable, the router only shields the internal network from the internet, but (as far as I know) it does nothing more than that. It is possible to enable port forwarding and even fully expose specific ipv6 hosts to the internet, but that's not enabled (for obvious reasons). Though it is one of the reasons why I'd like to get IPv6 to work. I have been able to enable telnet access to my router to see if I can do some additional debugging there, but it doesn't seem to have iptables so I'm not how to check the firewall on it. Though if the router is the issue, wouldn't you expect the Windows host to have issues too? If you have some tips on how to check to be safe those are always welcome  :Wink: .

An interesting thing I noticed though is that when I look up the host on the routers admin panel, for my Windows host its IPv6 addresses are listed but also the IPv6 addresses of my VM. My VM is seperately listed (also as "connected via <the windows host>"), but there it only shows the IPv4 address. So the router thinks the ipv6 address of my VM belongs to my host, even though it does recognize the VM as a separate machine. In the vbox bug I did read that it apparently does some MAC-address replacing (which wasn't done properly before), so that could explain why the ipv6 addresses are not listed at my VM. Don't know if this is an issue or not, the packets do have to get routed to my Windows host after all.

Here's a full dump of my /proc/sys/net/ipv6/conf:

```

# find /proc/sys/net/ipv6/conf -type f -exec echo -n "{}: " \; -exec cat {} \; 

/proc/sys/net/ipv6/conf/all/accept_dad: 1

/proc/sys/net/ipv6/conf/all/accept_ra: 1

/proc/sys/net/ipv6/conf/all/accept_ra_defrtr: 1

/proc/sys/net/ipv6/conf/all/accept_ra_pinfo: 1

/proc/sys/net/ipv6/conf/all/accept_ra_rtr_pref: 1

/proc/sys/net/ipv6/conf/all/accept_redirects: 1

/proc/sys/net/ipv6/conf/all/accept_source_route: 0

/proc/sys/net/ipv6/conf/all/autoconf: 1

/proc/sys/net/ipv6/conf/all/dad_transmits: 1

/proc/sys/net/ipv6/conf/all/disable_ipv6: 0

/proc/sys/net/ipv6/conf/all/force_mld_version: 0

/proc/sys/net/ipv6/conf/all/force_tllao: 0

/proc/sys/net/ipv6/conf/all/forwarding: 0

/proc/sys/net/ipv6/conf/all/hop_limit: 64

/proc/sys/net/ipv6/conf/all/max_addresses: 16

/proc/sys/net/ipv6/conf/all/max_desync_factor: 600

/proc/sys/net/ipv6/conf/all/mldv1_unsolicited_report_interval: 10000

/proc/sys/net/ipv6/conf/all/mldv2_unsolicited_report_interval: 1000

/proc/sys/net/ipv6/conf/all/mtu: 1280

/proc/sys/net/ipv6/conf/all/ndisc_notify: 0

/proc/sys/net/ipv6/conf/all/proxy_ndp: 0

/proc/sys/net/ipv6/conf/all/regen_max_retry: 3

/proc/sys/net/ipv6/conf/all/router_probe_interval: 60

/proc/sys/net/ipv6/conf/all/router_solicitation_delay: 1

/proc/sys/net/ipv6/conf/all/router_solicitation_interval: 4

/proc/sys/net/ipv6/conf/all/router_solicitations: 3

/proc/sys/net/ipv6/conf/all/suppress_frag_ndisc: 1

/proc/sys/net/ipv6/conf/all/temp_prefered_lft: 86400

/proc/sys/net/ipv6/conf/all/temp_valid_lft: 604800

/proc/sys/net/ipv6/conf/all/use_tempaddr: 0

/proc/sys/net/ipv6/conf/default/accept_dad: 1

/proc/sys/net/ipv6/conf/default/accept_ra: 1

/proc/sys/net/ipv6/conf/default/accept_ra_defrtr: 1

/proc/sys/net/ipv6/conf/default/accept_ra_pinfo: 1

/proc/sys/net/ipv6/conf/default/accept_ra_rtr_pref: 1

/proc/sys/net/ipv6/conf/default/accept_redirects: 1

/proc/sys/net/ipv6/conf/default/accept_source_route: 0

/proc/sys/net/ipv6/conf/default/autoconf: 1

/proc/sys/net/ipv6/conf/default/dad_transmits: 1

/proc/sys/net/ipv6/conf/default/disable_ipv6: 0

/proc/sys/net/ipv6/conf/default/force_mld_version: 0

/proc/sys/net/ipv6/conf/default/force_tllao: 0

/proc/sys/net/ipv6/conf/default/forwarding: 0

/proc/sys/net/ipv6/conf/default/hop_limit: 64

/proc/sys/net/ipv6/conf/default/max_addresses: 16

/proc/sys/net/ipv6/conf/default/max_desync_factor: 600

/proc/sys/net/ipv6/conf/default/mldv1_unsolicited_report_interval: 10000

/proc/sys/net/ipv6/conf/default/mldv2_unsolicited_report_interval: 1000

/proc/sys/net/ipv6/conf/default/mtu: 1280

/proc/sys/net/ipv6/conf/default/ndisc_notify: 0

/proc/sys/net/ipv6/conf/default/proxy_ndp: 0

/proc/sys/net/ipv6/conf/default/regen_max_retry: 3

/proc/sys/net/ipv6/conf/default/router_probe_interval: 60

/proc/sys/net/ipv6/conf/default/router_solicitation_delay: 1

/proc/sys/net/ipv6/conf/default/router_solicitation_interval: 4

/proc/sys/net/ipv6/conf/default/router_solicitations: 3

/proc/sys/net/ipv6/conf/default/suppress_frag_ndisc: 1

/proc/sys/net/ipv6/conf/default/temp_prefered_lft: 86400

/proc/sys/net/ipv6/conf/default/temp_valid_lft: 604800

/proc/sys/net/ipv6/conf/default/use_tempaddr: 0

/proc/sys/net/ipv6/conf/enp0s3/accept_dad: 1

/proc/sys/net/ipv6/conf/enp0s3/accept_ra: 1

/proc/sys/net/ipv6/conf/enp0s3/accept_ra_defrtr: 1

/proc/sys/net/ipv6/conf/enp0s3/accept_ra_pinfo: 1

/proc/sys/net/ipv6/conf/enp0s3/accept_ra_rtr_pref: 1

/proc/sys/net/ipv6/conf/enp0s3/accept_redirects: 1

/proc/sys/net/ipv6/conf/enp0s3/accept_source_route: 0

/proc/sys/net/ipv6/conf/enp0s3/autoconf: 1

/proc/sys/net/ipv6/conf/enp0s3/dad_transmits: 1

/proc/sys/net/ipv6/conf/enp0s3/disable_ipv6: 0

/proc/sys/net/ipv6/conf/enp0s3/force_mld_version: 0

/proc/sys/net/ipv6/conf/enp0s3/force_tllao: 0

/proc/sys/net/ipv6/conf/enp0s3/forwarding: 0

/proc/sys/net/ipv6/conf/enp0s3/hop_limit: 255

/proc/sys/net/ipv6/conf/enp0s3/max_addresses: 16

/proc/sys/net/ipv6/conf/enp0s3/max_desync_factor: 600

/proc/sys/net/ipv6/conf/enp0s3/mldv1_unsolicited_report_interval: 10000

/proc/sys/net/ipv6/conf/enp0s3/mldv2_unsolicited_report_interval: 1000

/proc/sys/net/ipv6/conf/enp0s3/mtu: 1492

/proc/sys/net/ipv6/conf/enp0s3/ndisc_notify: 0

/proc/sys/net/ipv6/conf/enp0s3/proxy_ndp: 0

/proc/sys/net/ipv6/conf/enp0s3/regen_max_retry: 3

/proc/sys/net/ipv6/conf/enp0s3/router_probe_interval: 60

/proc/sys/net/ipv6/conf/enp0s3/router_solicitation_delay: 1

/proc/sys/net/ipv6/conf/enp0s3/router_solicitation_interval: 4

/proc/sys/net/ipv6/conf/enp0s3/router_solicitations: 3

/proc/sys/net/ipv6/conf/enp0s3/suppress_frag_ndisc: 1

/proc/sys/net/ipv6/conf/enp0s3/temp_prefered_lft: 86400

/proc/sys/net/ipv6/conf/enp0s3/temp_valid_lft: 604800

/proc/sys/net/ipv6/conf/enp0s3/use_tempaddr: 0

/proc/sys/net/ipv6/conf/lo/accept_dad: -1

/proc/sys/net/ipv6/conf/lo/accept_ra: 1

/proc/sys/net/ipv6/conf/lo/accept_ra_defrtr: 1

/proc/sys/net/ipv6/conf/lo/accept_ra_pinfo: 1

/proc/sys/net/ipv6/conf/lo/accept_ra_rtr_pref: 1

/proc/sys/net/ipv6/conf/lo/accept_redirects: 1

/proc/sys/net/ipv6/conf/lo/accept_source_route: 0

/proc/sys/net/ipv6/conf/lo/autoconf: 1

/proc/sys/net/ipv6/conf/lo/dad_transmits: 1

/proc/sys/net/ipv6/conf/lo/disable_ipv6: 0

/proc/sys/net/ipv6/conf/lo/force_mld_version: 0

/proc/sys/net/ipv6/conf/lo/force_tllao: 0

/proc/sys/net/ipv6/conf/lo/forwarding: 0

/proc/sys/net/ipv6/conf/lo/hop_limit: 64

/proc/sys/net/ipv6/conf/lo/max_addresses: 16

/proc/sys/net/ipv6/conf/lo/max_desync_factor: 600

/proc/sys/net/ipv6/conf/lo/mldv1_unsolicited_report_interval: 10000

/proc/sys/net/ipv6/conf/lo/mldv2_unsolicited_report_interval: 1000

/proc/sys/net/ipv6/conf/lo/mtu: 65536

/proc/sys/net/ipv6/conf/lo/ndisc_notify: 0

/proc/sys/net/ipv6/conf/lo/proxy_ndp: 0

/proc/sys/net/ipv6/conf/lo/regen_max_retry: 3

/proc/sys/net/ipv6/conf/lo/router_probe_interval: 60

/proc/sys/net/ipv6/conf/lo/router_solicitation_delay: 1

/proc/sys/net/ipv6/conf/lo/router_solicitation_interval: 4

/proc/sys/net/ipv6/conf/lo/router_solicitations: 3

/proc/sys/net/ipv6/conf/lo/suppress_frag_ndisc: 1

/proc/sys/net/ipv6/conf/lo/temp_prefered_lft: 86400

/proc/sys/net/ipv6/conf/lo/temp_valid_lft: 604800

/proc/sys/net/ipv6/conf/lo/use_tempaddr: -1

```

@UberLord:

The prefix is the same but I get a different addresses each time (both for the 8006/8011/4006 ones and the 2001). In dhcpcd.conf "slaac private" was enabled, I've disabled that now and sent a tcpdump. Thank you!  :Smile: 

----------

## skaloo

To check if the problem is VirtualBox, you could try using a VMWare Workstation trial version and see if you have the same behaviour. I think there are ways to copy/migrate or even use their virtual disks in each other.

Also if you have some additional laptop or something similar you could try booting on a gentoo installation ISO and check how it goes, I think they have IPv6 activated, that would get rid of the virtualization layer.

----------

## UberLord

 *SunMar wrote:*   

> @UberLord:
> 
> The prefix is the same but I get a different addresses each time (both for the 8006/8011/4006 ones and the 2001). In dhcpcd.conf "slaac private" was enabled, I've disabled that now and sent a tcpdump. Thank you! 

 

Interesting.

Does /etc/dhcpcd.secret get punted or is not writeable for each reboot attempt?

Or does the MAC address keep changing?

----------

## SunMar

The MAC-address stays the same (though it can be reinitialized in VBox). The fe80 address does stay the same between reboots.

```

# ll /etc/dhcpcd.secret 

4.0K -r-------- 1 root root 192 Jul 31 18:10 /etc/dhcpcd.secret

```

What exactly do you mean with whether it gets punted? It's not chmod 700, how would I check for write issues? I can't find any errors regarding that in /var/log/messages. /etc is not on a separate mount, I only have /boot separate, the root / is for the rest one big partition.

I also followed skaloo's tip to try VMWare. I downloaded the free VMWare Player and an Win7 IE image, in both Win7 and the Gentoo LiveDVD IPv6 worked properly under VMWare, so that does indicate the connectivity issue is related to VirtualBox.

----------

