Toob (UK) IPV6 prefix settings
-
Hi Mikey,
Is there a guid on how you got everything set-up to get IPv6 working nicely with Toob.
I've just been trying, but have issue with ping times to the IPv6 gateway, and getting additional internalt interfaces (VLANs) working nicely with with IPv6 assignments.
-
@mikey_s said in Toob (UK) IPV6 prefix settings:
but their response is "our kit is configured correctly" type response.
When you hear that, fire up packet capture and see what they're actually doing. I did that to resolve a problem with my ISP 5 years ago.
-
Hi Gonzo - I've got Toob working with IPv6 and tracked ipv6 setup on a couple of my LAN interfaces.
My WAN Interface setup is as follows:
DHCP6
Request Only an IPV6 Prefix - Ticked
Prefix Delegation size - 56
Send IPv6 Prefix Hint - TickedEverything else left alone on the WAN side.
I don't set a custom monitor IP for the Toob IPv6 gateway - I jut leave it alone.
On my LAN interfaces, I only have a couple set for IPv6 - but the following is what I've done.
IPV6 - Track Interface
Track IPV6 Interface - WAN (whatever Toob presents on)
IP Prefix ID - keep it simple and just put in 0 or 1 for the first LAN you setup.That should be all you need to do - worked for me almost immeditley with those settings. No need to reboot ONT's etc. Bear in mind that I uplink straight to the ONT, my Toob router isn't in the chain - that may complicate things if you still have the Toob router in the chain.
-
@crucialguy I've managed to get it working at a basic level now. Still seeing random IPv6 ping spikes, which coincide with IPv6 failing and I've intentionally got montering actions turned off for the IPv6 gateway on the FW.
I've raised a ticket with too ask them what's going out n, but they've been useless recently with all the switch issues they've had as well which I noted was starting before they even admitted there was a fault!
-
@gonzo86 I have also experienced what you describe, not too often - but I have seen it, whereby the IPv6 gateway just goes offline (my tracked interfaces stay though).
I use Mullvad VPN for my IPv6 traffic anyway, the only reason I grab a prefix from Toob is so I can assign tracks to my LAN interfaces. I used to do it via HE.net, but it makes more sense to do it natively if your ISP offers it I guess.
Good luck getting any in-depth support from Toob - I love the price of their service, cannot fault that, but their support is pretty basic!
-
@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.
-
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.
-
@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.
-
@gonzo86 I have the following config on my WAN Port
LAN Port
IPv6 Configuration Type = Track Interface
LAN DHCP6
Router Advertisement
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.
-
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.
-
@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 ?
-
@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.
-
@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.1I 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=1msBut 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. -
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.
-
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 1500I 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.
-
@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.
-
Out of interest, what MTU are you running? Toob have mentioned 1280.
-
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 expiredTaking 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:36Taking 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:08On 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 PermanentJust 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.
-
@smaxwell2 I would suggest you start a new post as this is now off topic and not your post to begin with.
