Struggling to get basic IPv6 working...
-
I've recently upgraded my network connection, and suddenly the DNS servers are returning a bunch of IPv6 addresses. Because IPv6 isn't working on my network those connections fail and websites and things do not respond. Reloading until you get an IPv4 address works around it, but it's annoying.
In the long run, I'd like to set up a more complicated configuration, but I'm sure I need to learn more about IPv6 first. Today, I'd just like to get pfsense handing out IPv6 addresses and routes to my client machines so they can talk IPv6 on the Internet.
What I'm seeing right now is that clients can talk to each other over link-local, and they can talk to the IPv6 LAN interface on pfsense. If I log in to pfsense and use the ping there, the WAN interface can ping outside IPv6 addresses, but the LAN interface cannot.
I am assuming this is a firewall problem, but I'm stumped as to what it is. Any advice will be greatly appreciated.
Here's my configuration:
WAN Interface:
Using DHCP6 (presumably from my ISP router)
No options in the DHCP6 configuration section.LAN Interface:
Track Interface set to WAN
No special options. Using the default 0 for Prefix ID.The pfsense ping tool can ping Internet IPv6 addresses from the WAN interface, which makes me think the ISP router has set it up properly.
The pfsense ping tool can not ping Internet IPv6 addresses from the LAN interface, which suggests I've got something wrong in the setup, or a firewall rule is wrong. It can ping my local IPv6 addresses from the LAN interface.
The firewall rules look like this for the WAN:
The firewall rules look like this for the LAN:
I'm not trying to do anything fancy with delegations or static configuring right now - later, after I've got access in general, I can try and address that.
Any suggestions? I'm stuck.
-
Do you have IPv6 addresses, other than link local on the LAN? With most ISPs, you configure for DHCPv6-PD, where the PD stands for prefix delegation. On the LAN page, you have to select the Prefix ID, which is usually 0 for the main LAN. You also have to set the IPv6 Configuration type to track interface. The WAN IPv6 Configuration type should be DHCP6. Also, what prefix are you getting from your ISP? A /56 is common, though /48 and /16 are also used. A /56 will provide 256 /64s.
-
@JKnott said in Struggling to get basic IPv6 working...:
Do you have IPv6 addresses, other than link local on the LAN? With most ISPs, you configure for DHCPv6-PD, where the PD stands for prefix delegation. On the LAN page, you have to select the Prefix ID, which is usually 0 for the main LAN. You also have to set the IPv6 Configuration type to track interface.
The LAN is set to "Track Interface" on the WAN interface, using the default Prefix ID of 0.
ifconfig shows this for the LAN address:
mvneta1: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM> ether 00:08:a2:0c:ec:ae hwaddr 00:08:a2:0c:ec:ae inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 inet6 2603:3024:1f00:6220:208:a2ff:fe0c:ecae prefixlen 59 inet6 fe80::1:1%mvneta1 prefixlen 64 scopeid 0x2 media: Ethernet 2500Base-KX <full-duplex> status: active nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
The 2603:3024:1f00:6220:208:a2ff:fe0c:ecae address is in the space my ISP gives me.
@JKnott said in Struggling to get basic IPv6 working...:
The WAN IPv6 Configuration type should be DHCP6. Also, what prefix are you getting from your ISP? A /56 is common, though /48 and /16 are also used. A /56 will provide 256 /64s.
The ISP gives me a /56 prefix.
The WAN configuration is set to DHCP6. The WAN interface shows only a /64 prefix, though, so I don't know where the LAN gets a /59 from.
Here is ifconfig for the WAN interface.
mvneta2: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=800bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LINKSTATE> ether 00:08:a2:0c:ec:af hwaddr 00:08:a2:0c:ec:af inet6 fe80::208:a2ff:fe0c:ecaf%mvneta2 prefixlen 64 scopeid 0x8 inet6 2603:3024:1f00:6200:208:a2ff:fe0c:ecaf prefixlen 64 autoconf inet6 2603:3024:1f00:6200::e8bb prefixlen 128 inet 50.76.53.50 netmask 0xfffffff0 broadcast 50.76.53.63 media: Ethernet autoselect (1000baseT <full-duplex>) status: active nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
That 'autoconf' there... does that mean I'm getting this via SLAAC instead of dhcp6?
Is that /64 on the
inet6 fe80::208:a2ff:fe0c:ecaf%mvneta2 prefixlen 64 scopeid 0x8
line what's causing the issue, in that the /59 used by the LAN interface doesn't include all the address space?I see in the WAN DHCP6 configuration there is a "DHCPv6 Prefix Delegation size" option which has defaulted to /64. Should that match the ISP's /56? I can try that.
-
Hmm, changing "DHCPv6 Prefix Delegation size" on the WAN DHCP6 settings doesn't make things better. In fact, the LAN address no longer gets an ipv6 address other than link-local at all. Foo.
Clearly, I am not understanding something about the prefixes.
-
@Lou-Erickson said in Struggling to get basic IPv6 working...:
Clearly, I am not understanding something about the prefixes.
That's how big the address block is. LANs are normally /64, which is 18.4 billion, billion addresses. A /56 is 256 times that. You then would split a /56 into as many as 256 /64s. That /59 is unusual. It appears your ISP is using routeable addresses for a /64 block on the WAN interface, as well as they link local address. Often link local addresses are used. The /128 prefix indicates that address is only used to identify the interface and is not used for routing. Is your gateway a link local address?
-
@JKnott said in Struggling to get basic IPv6 working...:
@Lou-Erickson said in Struggling to get basic IPv6 working...:
Clearly, I am not understanding something about the prefixes.
That's how big the address block is. LANs are normally /64, which is 18.4 billion, billion addresses. A /56 is 256 times that. You then would split a /56 into as many as 256 /64s. That /59 is unusual.
Okay, that matches what I understood. I changed the "DHCPv6 Prefix Delegation size" in the DHCP6 config for the WAN interface to be a /56, just like the ISP tells me I have.
When I do that, the WAN gets three ipv6 addresses:
inet6 fe80::208:a2ff:fe0c:ecaf%mvneta2 prefixlen 64 scopeid 0x8 inet6 2603:3024:1f00:6200:208:a2ff:fe0c:ecaf prefixlen 64 autoconf inet6 2603:3024:1f00:6200::e8bb prefixlen 128
But the LAN gets only link local:
inet6 fe80::1:1%mvneta1 prefixlen 64 scopeid 0x2
If I leave the WAN prefix delegation size at /64, I get external IPv6 addresses on both interfaces; that's the configuration from the post above. I have no idea where the /59 comes from.
It seems to me that the /56 setting, which matches what the ISP says they give me, should be correct. But I don't understand the lack of a routable address on the LAN port. I also don't know if it's important, as I keep reading that the link-local address is used for routing.
If I use the pfsense ping test, I can ping an Internet host from both the WAN and the LAN interfaces using the /56 prefix request. That seems better. Neither one's link-local can ping it, but that makes sense to me because it isn't on the local link, it has to be routed.
Being able to ping from the LAN address seems like a step forward.
@JKnott said in Struggling to get basic IPv6 working...:
It appears your ISP is using routeable addresses for a /64 block on the WAN interface, as well as they link local address. Often link local addresses are used. The /128 prefix indicates that address is only used to identify the interface and is not used for routing. Is your gateway a link local address?
That's one thing that's confusing me, is I have no idea what my gateway is. If I understand correctly, that's coming from RA and I haven't found a place that will actually tell me what it is. Not knowing that, I have no idea how to tell where traffic is supposed to go. I'm used to that being very clear in ipv4, and am still missing it here.
Is there a way, short of tcpdump or wireshark, to see what RA is doing? On FreeBSD/pfsense and/or Linux? (Linux changing the networking commands has not been helpful.)
Thanks for all the help with this. I'm slowly starting to understand how this works.
-
That LAN there isn't link-local, it is, it's the loopback, isn't it?
I'm really stumped.
If I set up pfsense the way the ISP says (/56 prefix on the WAN) the WAN gets a good ipv6 address, and I can ping the outside world from both the WAN and the LAN. But the LAN only gets the fe80::1:1 address so nothing else on my lan can talk to it.
I did find how to see ipv6 routes - pfsense shows them on the routing page, and Linux ip -6 route will show it - and now I can see that no routes to pfsense are given.
What route could be given to talk to pfsense, and who should be sending it out?
-
@Lou-Erickson said in Struggling to get basic IPv6 working...:
That 'autoconf' there... does that mean I'm getting this via SLAAC instead of dhcp6?
I'd say it's the other way around. I don't see that on my system. I use DHCPv6 only for the /128 WAN address, not for a /64 network.
Is that /64 on the inet6 fe80::208:a2ff:fe0c:ecaf%mvneta2 prefixlen 64 scopeid 0x8 line what's causing the issue, in that the /59 used by the LAN interface doesn't include all the address space?
The /64 is normal for the link local address. However, that scope ID doesn't look right. Is your ISP providing their own scope?
That LAN there isn't link-local, it is, it's the loopback, isn't it?
Link local addresses start with fe80. The loopback is ::1.
The gateway address can be determined with netstat -r. Here's mine:
Internet6:
Destination Gateway Flags Netif Expire
default fe80::217:10ff:fe9 UG re0You'll note, that's a link local address and entirely normal with IPv6. However, it can also be a routeable address.
-
So, my pfsense host can route over its link-local address to the link-local address of the ISP router. That's fine, and makes reasonable sense to me. They can see each other there, so they can send traffic. That's good.
I've got the WAN address getting DHCP6 using the /56 prefix that the ISP gives me, and the LAN using "Track Interface" from the WAN address.
Here's what ifconfig says for the WAN:
mvneta2: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=800bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LINKSTATE> inet6 fe80::208:a2ff:fe0c:ecaf%mvneta2 prefixlen 64 scopeid 0x8 inet6 2603:3024:1f00:6200:208:a2ff:fe0c:ecaf prefixlen 64 autoconf inet 50.76.53.50 netmask 0xfffffff0 broadcast 50.76.53.63 nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
It has a link-local address (the fe80 one) and a routeable one (the 2603 one).
Here is the LAN:
mvneta1: flags=8a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM> inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 inet6 fe80::1:1%mvneta1 prefixlen 64 scopeid 0x2 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
All it seems to have is the loopback, which is a link-local address to this machine itself.
If I use the ping tool in pfsense, I can ping an Internet address (using my ISP's nameserver's ipv6 address) using either the LAN or WAN addresses.
I don't understand how the LAN works because it only has the fe80::1:1 address, though.
So, that leads to routing (which was a hassle to format for the forum):
Internet6: Destination Gateway Flags Use Mtu Netif default 2603:3024:1f00:6200:7654:7dff:fe7f:e130 UGS 343 1500 mvneta2 localhost link#10 UH 0 16384 lo0 2603:3024:1f00:6200::/64 link#8 U 2582 1500 mvneta2 2603:3024:1f00:6200::94d7 link#8 UHS 0 16384 lo0 2603:3024:1f00:6200:208:a2ff:fe0c:ecaf link#8 UHS 0 16384 lo0 fe80::7654:7dff:fe7f:e130 fe80::7654:7dff:fe7f:e130%mvneta2 UGHS 0 1500 mvneta2 fe80::%mvneta1/64 link#2 U 113 1500 mvneta1 fe80::1:1%mvneta1 link#2 UHS 0 16384 lo0 fe80::%mvneta2/64 link#8 U 2639 1500 mvneta2 fe80::208:a2ff:fe0c:ecaf%mvneta2 link#8 UHS 0 16384 lo0 fe80::%lo0/64 link#10 U 0 16384 lo0 fe80::1%lo0 link#10 UHS 0 16384 lo0 fe80::%ovpns1/64 link#13 U 0 1500 ovpns1 fe80::208:a2ff:fe0c:ecad%ovpns1 link#13 UHS 0 16384 lo0
That default route is the IPv6 routeable address of the ISP's device. I didn't set it, so the device must have provided it via RA. I think.
I'm not sure what all those others are and do, or where they came from. They seem to let me ping Internet IPv6 addresses. I can even run nslookup using 2001:558:feed::1 as a server and it responds right away.
So, that seems to have pfsense on the Internet with ipv6 properly.
The question is now, how do I get it to my client computers properly?
-
@Lou-Erickson said in Struggling to get basic IPv6 working...:
All it seems to have is the loopback, which is a link-local address to this machine itself.
The loopback is ::1. Where do you see that? I see a link local address of fe80::1:1, which is entirely normal. I have that here too.
I don't understand how the LAN works because it only has the fe80::1:1 address, though.
It's the same as the WAN side. You have a link local address, which is all you need. Here's what I have:
On this computer:
default via fe80::1:1 dev eth0 proto ra metric 1024 expires 52sec hoplimit 64 pref mediumAnd on pfSense:
inet6 fe80::1:1%bge0 prefixlen 64 scopeid 0x1So, as you can see, I'm using a link local address both on my LAN and also on the WAN side. This is absolutely normal.
As an experiment, ping the WAN address from a computer on your LAN, to see if it works.
-
My test client machine is on Windows, which means the commands and output are different, but that shouldn't be an issue.
You say to ping the WAN address from the local client.
I see two WAN addresses; the one from the ISP, and the link-local fe80 one.
I can't ping either of them from the Windows client.
That Windows client shows it has three ipv6 addresses:
IPv6 Address. . . . . . . . . . . : 2603:3024:1f00:6201:cf6:d1bf:c8b7:1610(Deprecated) Temporary IPv6 Address. . . . . . : 2603:3024:1f00:6201:a54c:a536:48fd:985b(Deprecated) Link-local IPv6 Address . . . . . : fe80::cf6:d1bf:c8b7:1610%14(Preferred)
I don't know why those are getting addresses from 2603:3024:1f00:6201 instead of 2603:3024:1f00:6200, or why it gets two of them, but the link-local seems to make sense.
There's also a bunch of routes, but I presume this is the important one:
Active Routes: If Metric Network Destination Gateway 14 281 ::/0 fe80::1:1
That sets the default gateway to be fe80::1:1, which is the link-local address on the LAN port of pfSense. I did not set this, so am assuming it got it through RA. I stopped the DHCP6/RA service on pfsense, so I do not know who is sending this.
In any event, when I ping, I can ping fe80::1:1 just fine.
I can not ping the WAN's link-local fe80::208:a2ff:fe0c:ecaf address. It says "Destination host unreachable".
I can not ping the WAN's ISP address 2603:3024:1f00:6200:208:a2ff:fe0c:ecaf. Those simply time out.
I also can not ping the Internet facing IPv6 address I'm testing with, 2001:558:feed::1 which also time out.
I tried doing an nslookup using 2001:558:feed::1 as a server (it is my ISP's DNS server's address) in case it's ICMP silliness, and that also times out.
And this is why I posted firewall rules in my first post, because I thought that must be where the problem was; pfsense not passing this traffic. But I don't know.
-
The WAN side has to be in a different subnet than the LAN side, so routing can happen. So in effect with IPv6 and two routers (ISP and pfSense) the WAN subnet gets 18 quintillion addresses (a /64), and the LAN side another 18 quintillion. Also the WAN side is usually granted a /56 or something as indicated so several more dozen quintillion are typically unused. This is so it can assign /64s to multiple routers if necessary....the ISP router has to be able to talk to all of those /64s.
The temporary IPv6 is because "they" decided tracking was too easy with one IP per device so software like a browser can request a unique/temporary IP. So perhaps if each software program gets an IP its good we have a few quintillion spares in our /64.
As far as not pinging the pfSense WAN IP from the LAN, have you enabled the option to log packets from the default block rule in the log settings? That will at least tell you if the default block rule is blocking the attempt. Also check the firewall on the Windows PC.
-
No, I haven't got logging for the default block rules. I just looked for that and couldn't find where to turn it on. Do you know? If I can see packets blocked on IPv6 from my client, that definitely helps know it is some firewall fun.
-
Status/System Logs/Settings, check "Log packets matched from the default block rules in the ruleset". I usually just turn it on temporarily otherwise it will log a lot of stuff.
-
I missed it in there. And look what I found when I turned it on:
Apparently pfsense thinks my range is a bogon network.
Quesion: Is it, or is pfsense's list out of date?
That I know how to answer: whois tells me that 2603:3024::/32 is allocated to my ISP. So it's not a bogon, and my local pfsense's list must be outdated.
Where is that kept, and how do I update it?
I can disable it for now and see if it fixes things!
-
Well, there's an option to control how often the bogon list is updated, but I've had this allocation a while (and whois says it's been registered since 17 Jan 2019) so it isn't a frequency problem. Do not know why my ip range is triggering that, and can't see it so it's hard to say.
I disabled it to see if that let things work.
Suddenly, in the general system log, I see:
I don't know why it can't route that.
-
That may be a red herring. I found more errors under the "gateways" tab on system logging, where it was failing to see one of the defined gateways. It was testing one I had set up while struggling earlier, but am not using. I erased it and the errors have stopped.
I can still ping anything on both the WAN and LAN interfaces, but nothing from my clients.
-
@Lou-Erickson said in Struggling to get basic IPv6 working...:
You say to ping the WAN address from the local client.
I see two WAN addresses; the one from the ISP, and the link-local fe80 one.Ping the one with the /128 prefix. This will show you are able to at least reach another interface on your pfSense box. If that works, you can try something else, such as ipv6.google.com.
You can also try a test site, such as [test-ipv6.com](link url).
I don't know why those are getting addresses from 2603:3024:1f00:6201 instead of 2603:3024:1f00:6200, or why it gets two of them, but the link-local seems to make sense.
If you're using SLAAC on your LAN, you will have one consistent address and up to seven privacy addresses. You get a new one every day and they last about a week. You use the privacy address when you have outgoing connections and the consistent one is used for incoming, such as for servers, etc..
That gateway address is correct and is provided by the RA. One difference, compared to IPv4, is DHCP does not provide the gateway address, etc.. So, RAs are always used to provide the prefix and gateway address.
I can not ping the WAN's link-local fe80::208:a2ff:fe0c:ecaf address. It says "Destination host unreachable".
You should not be able to ping that from devices on your LAN, as link local addresses are not routeable.
As for firewall rules, if you didn't add any, it should work out of the box.
You might also mention who your ISP is. Someone else might have experience with them.
-
First, let me say thank you for continuing to answer my questions and look at all these things I've posted. I know I've thrown a bunch of data out, but I don't know fully what you'll need to see to make sense of what's happening. I really appreciate your taking your time to reply!
Everyone on this forum has been very responsive and helpful, and I really appreciate it. So often forums are not very helpful and I often hesitate to go there. This one has been great. Thank you all for making it that way!
@JKnott said in Struggling to get basic IPv6 working...:
@Lou-Erickson said in Struggling to get basic IPv6 working...:
You say to ping the WAN address from the local client.
I see two WAN addresses; the one from the ISP, and the link-local fe80 one.Ping the one with the /128 prefix. This will show you are able to at least reach another interface on your pfSense box. If that works, you can try something else, such as ipv6.google.com.
I don't see an address on the WAN interface with a /128. Both are a /64.
inet6 fe80::208:a2ff:fe0c:ecaf%mvneta2 prefixlen 64 scopeid 0x8 inet6 2603:3024:1f00:6200:208:a2ff:fe0c:ecaf prefixlen 64 autoconf
The LAN interface lists the fe80::1:1 address.
From my client machine, I can ping fe80::1:1
Pinging fe80::208:a2ff:fe0c:ecaf returns "Destination host unreachable."
Pinging 2603:3024:1f00:6200:208:a2ff:fe0c:ecaf returns "Request timed out."Pinging ipv6.google.com returns "Request timed out." but that isn't a surprise as we can't seem to ping through to the WAN side of pfsense.
That gateway address is correct and is provided by the RA. One difference, compared to IPv4, is DHCP does not provide the gateway address, etc.. So, RAs are always used to provide the prefix and gateway address.
Okay, but who's the RA here? This seems to be sending a sensible address, so is pfsense the RA?
As for firewall rules, if you didn't add any, it should work out of the box.
Following another guide, I added pass-all rules for IPv6 addresses, as only IPv4 was passed. They're in the first post; are they correct?
You might also mention who your ISP is. Someone else might have experience with them.
I'm using Comcast Business, with static IPs. Old habit not to shill for them, although the business people have been okay. From what I understand their IPv6 configuration is tolerable by now.
-
@Lou-Erickson said in Struggling to get basic IPv6 working...:
I don't see an address on the WAN interface with a /128. Both are a /64.
You had one 12 hours ago.
Okay, but who's the RA here? This seems to be sending a sensible address, so is pfsense the RA?
RA = Router Advertisement. It comes from pfSense on the LAN side or your ISP on the WAN.
It seems to me someone else here was on Comsast business, though I don't know who.
Also, it might be best if you were to start from scratch again, as you've made so many changes that it's hard to know where the problem is.