Toob (UK) IPV6 prefix settings

gonzo86

@crucialguy I think the issue is NAT reflection. It seems that with IPv6 and NAT reflection enabled, the packets are going onto link local and putting the remote router into a hissy fit! Disabled it now, and everything for me is now butter smooth.

smaxwell2

I have just had Toob Installed and have exactly the same problem. I have set the same settings as above. IPv6 works, when I initially connect a Client to the network (WiFi or Ethernet), however after around 1-2 minutes IPv6 just drops out.

I have no Gateway Monitoring Actions.

Any ideas what we can here here to troubleshoot without reaching out to Toob support ? As I fear I won't get anywhere with support.

gonzo86

@smaxwell2 First of all, I would say that toobs support team are actually pretty good, and will try and help and even ask their engineers for information and additional help when needed.

I was able to get this working. How are you currently receiving/setting your IPv6 address space on the firewall?

How is the IPv6 gateway configured on the routing page?

I forget how I figured out mine in the end, but as I have a working config here, we can use that as reference point to try and get you up and running.

smaxwell2

@gonzo86 I have the following config on my WAN Port

WAN Port.png

LAN Port

IPv6 Configuration Type = Track Interface

LAN Port.png

LAN DHCP6

LAN DHCP6.png

Router Advertisement

Router Advertisement.png

If you could let me know what you have configured and working, that would be great.

As I say, IPv6 is ALWAYS working directly from the Router (can always PING google.co.uk from Firewall).

However any client on my LAN, is working for around 30 seconds up to 2 minutes. And then IPv6 Connectivity drops out.

gonzo86

Ok. For a start my IPv6 config on my WAN port looks very different:

If you're on a static address for Toob, let toob's DHCP manage that for you, at least then if they break the static assignment, you'll still be online without any fiddling about (always use DHCP if it's available too you, speaking as an experienced sysadmin).

Also allow IPv6 to be negotiated over IPv4, again adds redundancy, which is useful when you're provider is basically a start-up, and that IPv6 in general can sometimes have issues as it's adoption is early in the home space especially.

For my Track, I set the ID to be the same as my VLAN ID. Also avoid 0, as I think toob are using it internally and might cause issue (might not be correct, but I had issues using 0):

Your address pools look fine, as dose your router advertisement. Are you running DNS local to the firewall, as you should be setting it on the Router Advertisement but have cut it off:

What does your gateway configuration look like? Here is mine:

Hope this helps.

smaxwell2

@gonzo86 That is really helpful. I have not got a Static IP for Toob.

I have enabled the exact same settings as you. And still have the same issue. Clients have IPv6 for around 40 seconds, and then it drops out.

Any ideas ?

gonzo86

@smaxwell2 Ok, when you say they have IPv6 for around 40 seconds and then drops out, what do you mean?

Do they lose their IPv6 config, the gateway information, or are just unable to resolve IPv6 addresses?

Its possible the issue is on the client side, but if you're PfSense config is now the same as mine, we're going to need to debug the exact issue with regards to being unable to use IPv6.

smaxwell2

@gonzo86 When a windows client is connected either by Ethernet or WiFi if I ping google.co.uk

Reply from 2a00:1450:4009:822::2003: time=5ms
Reply from 2a00:1450:4009:822::2003: time=11ms
Reply from 2a00:1450:4009:822::2003: time=6ms
Reply from 2a00:1450:4009:822::2003: time=5ms
Reply from 2a00:1450:4009:822::2003: time=5ms
Reply from 2a00:1450:4009:822::2003: time=5ms
Reply from 2a00:1450:4009:822::2003: time=6ms
Reply from 2a00:1450:4009:822::2003: time=6ms
Reply from 2a00:1450:4009:822::2003: time=5ms
Reply from 2a00:1450:4009:822::2003: time=6ms
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.

When IPv6 has "broken" if I run a ipconfig

Default Gateway . . . . . . . . . : fe80::208:a2ff:fe0e:b436%16
192.168.1.1

I can still PING the default gateway of fe80::208:a2ff:fe0e:b436%16

Pinging fe80::208:a2ff:fe0e:b436%16 with 32 bytes of data:
Reply from fe80::208:a2ff:fe0e:b436%16: time=1ms
Reply from fe80::208:a2ff:fe0e:b436%16: time=1ms
Reply from fe80::208:a2ff:fe0e:b436%16: time=1ms
Reply from fe80::208:a2ff:fe0e:b436%16: time=1ms

But when I run a tracert to 2a00:1450:4009:822::2003 I get the following:

Tracing route to lhr48s29-in-x03.1e100.net [2a00:1450:4009:822::2003]
over a maximum of 30 hops:

1 * * * Request timed out.
2 * * * Request timed out.
3 * * * Request timed out.

smaxwell2

Interestingly - iOS Devices don't appear to have an issue. IPv6 Routing is working and I have yet to see it break since this change.

gonzo86

That really does sound like a possible windows issue. Could be an issue with the firewall or possibly with its DNS resolution (it doesn't say what IP address the request is timing out for, and I can't remember if ping cache's the DNS resolution on windows like it does in linux/unix OSes).

When I run similar from my main PC I'm not sing any issues:

❯ ping google.com
PING google.com (2a00:1450:4009:819::200e) 56 data bytes
64 bytes from lhr48s09-in-x0e.1e100.net (2a00:1450:4009:819::200e): icmp_seq=1 ttl=117 time=2.48 ms
64 bytes from lhr48s09-in-x0e.1e100.net (2a00:1450:4009:819::200e): icmp_seq=2 ttl=117 time=3.07 ms
64 bytes from lhr48s09-in-x0e.1e100.net (2a00:1450:4009:819::200e): icmp_seq=3 ttl=117 time=2.66 ms
64 bytes from lhr48s09-in-x0e.1e100.net (2a00:1450:4009:819::200e): icmp_seq=4 ttl=117 time=2.62 ms
64 bytes from lhr48s09-in-x0e.1e100.net (2a00:1450:4009:819::200e): icmp_seq=5 ttl=117 time=2.60 ms
64 bytes from lhr48s09-in-x0e.1e100.net (2a00:1450:4009:819::200e): icmp_seq=6 ttl=117 time=2.58 ms
64 bytes from lhr48s09-in-x0e.1e100.net (2a00:1450:4009:819::200e): icmp_seq=7 ttl=117 time=2.84 ms
64 bytes from lhr48s09-in-x0e.1e100.net (2a00:1450:4009:819::200e): icmp_seq=8 ttl=117 time=3.35 ms
^C
--- google.com ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7011ms
rtt min/avg/max/mdev = 2.476/2.773/3.353/0.278 ms
❯ tracepath google.com
 1?: [LOCALHOST]                        0.005ms pmtu 1500
 1:  firewall.g0nz0.me.uk                                  0.164ms
 1:  firewall.g0nz0.me.uk                                  0.135ms
 2:  2a0e:cb00:700b:1::11                                  2.109ms
 3:  no reply
 4:  no reply
 5:  2001:4860:1:1::22da                                   2.005ms !A
     Resume: pmtu 1500

I am running Linux here, but I don't remember having similar issue with Windows as to what you're describing. Which version of windows are you using as I've only ever tested with Win 11.

smaxwell2

@gonzo86 Think my issue here is with NDP. After hours and hours of troubleshooting, I have noticed that my Windows IPv6 Address is present within the pfSense NDP table, with an expiry of around 30 or so seconds, then it changes to (incomplete) and then my PING drops out. Then after around 30 seconds, it re-establishes (again 30 seconds) and the whole process repeats.

I have taken packet captures from the pfSense LAN interface and my Windows Client LAN interface, however un-sure what I am looking for.

Any pointers here ? I am sure my problem related to NDP now.

mikey_s

Out of interest, what MTU are you running? Toob have mentioned 1280.

smaxwell2

I have performed some more troubleshooting with this. It appears I only have an issue with the Windows 11 client; Apple devices seem to be working perfectly.

If I navigate to pfSense > Diagnostics > NDP Table, I see the following for the Windows 11 client PC (sometimes this renews and has 30s left until expiry or so - I get IPv6 connectivity at this stage on the client, then expires, rinse and repeat):

2a0e:XXXX:f3:110:XXXX:c3e4:5d78:32c4	3c:7c:3f:53:2c:08		LAN_SFP	expired

Taking a Packet Capture from the LAN_SFP Interface on pfSense, I see the following (00:08:a2:0e:b4:36 being the MAC address of pfSense and 3c:7c:3f:53:2c:08 being the MAC address of the Client PC):

Neighbor Solicitation for 2a0e:XXXX:f3:110:XXXX:c3e4:5d78:32c4 from 00:08:a2:0e:b4:36
Neighbor Solicitation for 2a0e:XXXX:f3:110:XXXX:c3e4:5d78:32c4 from 00:08:a2:0e:b4:36
Neighbor Solicitation for 2a0e:XXXX:f3:110:XXXX:c3e4:5d78:32c4 from 00:08:a2:0e:b4:36
Neighbor Solicitation for 2a0e:XXXX:f3:110:XXXX:a2ff:fe0e:b436 from 3c:7c:3f:53:2c:08
Neighbor Advertisement 2a0e:XXXX:f3:110:XXXX:a2ff:fe0e:b436 (rtr, sol, ovr) is at 00:08:a2:0e:b4:36
Neighbor Solicitation for fe80::3a8b:59ff:fe0b:ee62 from 00:08:a2:0e:b4:36
Neighbor Advertisement fe80::3a8b:59ff:fe0b:ee62 (sol)
Neighbor Solicitation for 2a0e:XXXX:f3:110:XXXX:a2ff:fe0e:b436 from 3c:7c:3f:53:2c:08
Neighbor Advertisement 2a0e:XXXX:f3:110:XXXX:a2ff:fe0e:b436 (rtr, sol, ovr) is at 00:08:a2:0e:b4:36
Neighbor Solicitation for 2a0e:XXXX:f3:110:XXXX:a2ff:fe0e:b436 from 3c:7c:3f:53:2c:08
Neighbor Advertisement 2a0e:XXXX:f3:110:XXXX:a2ff:fe0e:b436 (rtr, sol, ovr) is at 00:08:a2:0e:b4:36

Taking a Packet Capture from the Client PC, I see the following:

Neighbor Solicitation for 2a0e:XXXX:f3:110:XXXX:c3e4:5d78:32c4 from 00:08:a2:0e:b4:36
Neighbor Solicitation for 2a0e:XXXX:f3:110:XXXX:c3e4:5d78:32c4 from 00:08:a2:0e:b4:36
Neighbor Solicitation for 2a0e:XXXX:f3:110:XXXX:c3e4:5d78:32c4 from 00:08:a2:0e:b4:36
Neighbor Solicitation for 2a0e:XXXX:f3:110:XXXX:a2ff:fe0e:b436 from 3c:7c:3f:53:2c:08
Neighbor Advertisement 2a0e:XXXX:f3:110:XXXX:a2ff:fe0e:b436 (rtr, sol, ovr) is at 00:08:a2:0e:b4:36
Neighbor Solicitation for 2a0e:XXXX:f3:110:XXXX:a2ff:fe0e:b436 from 3c:7c:3f:53:2c:08
Neighbor Advertisement 2a0e:XXXX:f3:110:XXXX:a2ff:fe0e:b436 (rtr, sol, ovr) is at 00:08:a2:0e:b4:36
Neighbor Solicitation for 2a0e:XXXX:f3:110:XXXX:a2ff:fe0e:b436 from 3c:7c:3f:53:2c:08

On the client PC, firing up a CMD and running "netsh interface ipv6 show neighbors"

Interface 18: Ethernet

Internet Address                              Physical Address   Type
--------------------------------------------  -----------------  -----------
2a0e:XXXX:f3:110:XXXX:a2ff:fe0e:b436           Unreachable        Unreachable
fe80::208:a2ff:fe0e:b436                      00-08-a2-0e-b4-36  Probe (Router)
fe80::32e1:71ff:feb7:9974                     30-e1-71-b7-99-74  Permanent

Just to reiterate - the following is the problem. I get IPv6 connectivity for around 30 seconds, then when the NDP listing in pfSense Expires, it drops out:

Pinging google.co.uk [2a00:1450:4009:821::2003] with 32 bytes of data:
Reply from 2a00:1450:4009:821::2003: time=3ms
Reply from 2a00:1450:4009:821::2003: time=4ms
Reply from 2a00:1450:4009:821::2003: time=3ms
Reply from 2a00:1450:4009:821::2003: time=3ms
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Network is physically configured as follows:

Netgate (7100) > UniFi 8 Port POE 150w Switch > Netgear GS110TP

All network switches have IGMP Snooping disabled, have basically default settings and are on the latest firmware.

If anyone has any ideas - they would be much appreciated. I have been trying to get IPv6 working on this client PC for over a month, seem to be getting nowhere.

gonzo86

@smaxwell2 I would suggest you start a new post as this is now off topic and not your post to begin with.