IPv6 setup issues
-
Hi everybody,
after switching to another ISP (providing a DS Lite connection) I had to consider setting up an IPv6 infrastructure to keep my web- and vpn-server reachable.
Tons of forums and a bunch of issues later I now have a quite well working setup.Though there are still some points I'm either not understanding or I consider to be bugs.
1. DHCPv6 / RA being blocked by the "Block Bogon Networks" rule.
I know the fe80:: link-local IPv6 addresses can be seen as the equivalent to the good old APIPAs (169.254.0.0/16) which are and should be blocked by the BBN rule. Because this behavior is just right - it does what it should do - I can't see this as a bug, but I somehow feel it's not the intended behavior to block DHCP traffic.
Is there a workaround to keep the BBN rule active and still have a SLAAC / DHCP setup?
2. Prefix Delegation
This really turned out to be a pain in the ***.
First of all my setup:I request a /60 prefix delegation from my ISP on the WAN interface. Let's say this prefix was
2000
ef01:3210::/60My outdated knowledge about subnetting tells me that I can do what I want with the adress space from
2000
ef01:3210::/60 to
2000ef01:321f:ffff:ffff:ffff:ffff/60At this point I just like to split it to some /64 subnets. For some reasons i pick
2000ef01:3211::/64 for LAN
2000ef01:321d::/64 for DMZ and
2000ef01:321f::/64 for WLANSo far so good. I now select the LAN interface, choose "Track Interface –> WAN" and give it the prefix ID "1".
Then the LAN Interface gets the IP
2000ef01:3211:[EUI-64 stuff]
Same Thing for DMZ and WLAN they get
2000ef01:321d:[EUI-64 stuff] and
2000ef01:321f:[EUI-64 stuff]The problem with this is the assigned prefix length. For all 3 Interfaces it is /60 and not /64 as intended.
Basically they are all on the same 2000ef01:3210::/60 net now.Since I did not find any way to tell a tracking interface to pick a specific prefix length it obviously just grabs as much as it can and that is the whole delegated /60 net.
The workaround for this is to simply assign these IPs as static IPs with /64, but only after disabling the interface tracking on the other interfaces because it would bring up IP address conflicts the other way.Though I could not find any way to assign the desired prefix lenght via interface tracking it does'nt mean there is no way.
Am I just too blind to see it? Is there a way to do "real" subnetting through interface tracking?My guess is that the interfaces should pick their (new) prefix length by choosing the prefix ID in the interface tracking option.
But how would this work if I would like to subnet to /61 /62 or /63?I'm really curious about this as I'd prefer to do it by interface tracking. The PD seems to be at least quasi-static, but I just don't want my network to become unreachable when my ISP decides to change ist PD Options…
-
Depending on your ISP, it shouldn't be difficult to get ipv6 working. Start with default settings wherever possible.
In the WAN, use ipv6 dhcp. I have bogons blocked in my wan settings. Depending on your ISP, you may or may not be able to request a WAN address and some ISP require do not wait for RA. Don't set it unless you know you need to. If you want your prefix to be as static as possible, set do not allow pd release.
In the LAN, use tracking for ipv6. I don't have bogons blocked in my lan settings. Set the LAN to track the wan and start with ipv6 prefix id 0 for the first /64 subnet and increment it by 1 for each subsequent subnet. This field pads the delegated prefix by up to 8 bits to make it a /64.
In the dhcpv6 server settings, set the minimum / maximum range to be ::1000 / ::2000, or whatever. Set the RA to be assisted.
That's all that should be required. Give it a try and if you're having problems, post screen captures of wan, lan and dhcpv6 settings.
-
At first, thank you for your reply, though it seems like you didn't read my post through at all…
Depending on your ISP, it shouldn't be difficult to get ipv6 working. Start with default settings wherever possible.
As I said my IPv6 setup already is working. So there is no need to start from scratch again.
[…] and some ISP require do not wait for RA. Don't set it unless you know you need to. […]
That's one of the problems I had before updating pfsense to 2.3.3 p1. No problem anymore since I now have a working config with dhcpv6 an WAN.
[…] This field pads the delegated prefix by up to 8 bits to make it a /64.
No, it simply doesn't. At least not in my case. It pads the prefix, but that doesn't make it /64.
This is what happens:
I request a /60 from my ISP and I get a /60. I track the WAN in the LAN Settings and give it an ID from 0 to f, doesn't matter which, they all behave the same.
Result:
LAN interface configures itself with a /60 address. And that exactly is my problem. The padding happens, but the prefix length doesn't change.Long story short:
1. Setup is working, but only with static IPs on the pfsense box.
2. DHCPv6 isn't my problem. It's blocked through BBN rule and I just think this shouldn't be like this.
3. Tracking WAN interface doesn't do subnetting. Padding happens, but prefix length stays the same.
-
I read your post. I think you need to re-read mine. If you want help, post your wan, lan, dhcp6 configurations.
-
My guess is that the interfaces should pick their (new) prefix length by choosing the prefix ID in the interface tracking option.
But how would this work if I would like to subnet to /61 /62 or /63?Interfaces get a /64.
To put anything else on an interface is nonsense.
If you want to delegate prefixes to downstream routers you should be starting with at least a /48 and delegating /56 or /60.
You will need to post your config as has already been requested. Everyone else using track interface is getting /64s on the tracking interfaces as they should.
-
[…]If you want help, post your wan, lan, dhcp6 configurations.
As I said before my setup on LAN is now static. So posting my settings wouldn't be very helpfull to the described tracking problem.
Of course I can switch back to tracking WAN on the LAN interface and post the screenshots just to show there's a /60 address on the LAN interface, but this would only screw the whole setup.
It all Comes down to one simple question:
If you have a delegated /60 prefix and track it on other interfaces plus assigning an prefix ID, should the tracking interface configure itself with a /64 address, i.e. should it do the subnetting on it's own?
-
The screens requested…
WAN config, LAN config and the resulting interface status
-
Hmm.
What size PD are you actually getting? Turn on that debug on the WAN DHCP6 settings (Start DHCP6 client in debug mode) and search the DHCP logs for something like this:
**dhcp6c[40011]: update a prefix 2600:dead:beef:a300::/56 pltime=140733193474432, vltime=34359824768** **dhcp6c[40011]: IA_PD prefix: 2600:dead:beef:a300::/56 pltime=86400 vltime=86400** dhcp6c[40011]: IA_NA address: 2600:dead:beef:b00:c11a:aaeb:decd:ff37 pltime=86400 vltime=86400 dhcp6c[40011]: update an address 2600:dead:beef:b00:c11a:aaeb:decd:ff37 pltime=86400, vltime=140733193474432 dhcp6c[40011]: add an address 2600:dead:beef:b00:c11a:aaeb:decd:ff37/128 on igb1You should be able to just filter the DHCP logs on process dhcp6c. Curious if you are actually getting a /56 and not a /60.
-
I'm not clear why you are referring to your configuration being static. Are you intending to operate with a static lan and not use dhcpv6? What if your prefix changes? If you don't have dhcpv6 enabled, you should do so, using assisted mode. You can set up static mappings later.
Something is causing the mask on your lan to be 60 instead of 64, so I suggest you reset to defaults and start over. At the very least, delete both the lan and wan interfaces and recreate them. I strongly recommend the former. As Derelict said and others will confirm, this works or we wouldn't be using it. It's possible to set up a fully operational dual stack system from scratch in a few minutes. It's been suggested before and I'll say it again, start with defaults wherever possible unless there is a very good reason to change them. When you get things working, then have your way with it. If you change a bunch of things before it's working, you won't know what is causing the problem.
FYI, I'm using a /56 and the prefix id is 8 bits. Since your prefix id is 4 bits, you seem to be getting a /60, but something caused the mask to get messed up so like I said, go back to first principles.
In your case, start with ipv4 and one lan. When that's working, add ipv6 and dhcpv6 using something like ::1000 to ::2000.
-
[…]
You should be able to just filter the DHCP logs on process dhcp6c. Curious if you are actually getting a /56 and not a /60.That was causing my trouble!
I just tried to request everything from /48 down to /64, but everytime I only get /56 PDs. Looks like my ISP doesn't delegate anything else…Setting the requested PD to /56 solves the problem with the tracking interfaces.
-
Yeah I think there is a logic problem there in track interface. It uses 64 - what you request and adds that to the prefix you receive to determine the prefix length of the tracked interface.
So you were seeing 64 - 60 = 4 then 56 + 4 = 60. But 64 - 56 = 8 and, of course, 56 + 8 = 64.
Not sure why.
So if what you request doesn't match what you receive, it breaks.
-
Yeah I think there is a logic problem there in track interface. It uses 64 - what you request and adds that to the prefix you receive to determine the prefix length of the tracked interface.
So you were seeing 64 - 60 = 4 then 56 + 4 = 60. But 64 - 56 = 8 and, of course, 56 + 8 = 64.
Not sure why.
So if what you request doesn't match what you receive, it breaks.
Looks like a bug.
This is slightly OT, but I've been wondering what pfsense does in cases where the prefix is numerically smaller (e.g., /48). I can only get /56 so I have no way to experiment with prefix size. I understand the prefix id is only up to 8 bits. Does pfsense pad the difference with 0s? I think the prefix id should be up to whatever length is required to pad the delegated prefix to 64 bits. Only allowing up to 8 bits seems arbitrary. Or am I missing something?
-
[…]
You should be able to just filter the DHCP logs on process dhcp6c. Curious if you are actually getting a /56 and not a /60.That was causing my trouble!
I just tried to request everything from /48 down to /64, but everytime I only get /56 PDs. Looks like my ISP doesn't delegate anything else…Setting the requested PD to /56 solves the problem with the tracking interfaces.
Were you deleting the DUID each time? Pretty sure you have to do that in most cases or you might/should get the same PD you had before.
-
Were you deleting the DUID each time? Pretty sure you have to do that in most cases or you might/should get the same PD you had before.
I even did a complete reboot plus disabling/enbling the WAN interface each time.
I got different PDs with requesting /48, /52, /56, /60 and /64, but they all were /56 according to the logs.Now my only choice is to request what I would get anyway. It's no problem to live with this issue if you know how it works…
I'd vote for an option to show the leased PD in the Status --> Interfaces tab, just to avoid such things in the future.
-
A reboot does not delete the DUID. It is designed to be persistent. You generally want the same prefix delegation each time.
-
You might try unselecting "do not send release". It could be that the edge router will not give a lease when there is an active lease. That's the case with my ISP edge router, which is nokia/alcatel 7750. It goes even further. If there is an active lease associated with a MAC, it will not give another lease for the same MAC until the active lease expires, even if the DUID is changed. The supposed reason for this according to my ISP is that the dhcp relay only looks at the MAC, but the dhcp server only looks at the DUID. It could also be that your ISP only gives /56 prefix, regardless of what you request.
-
It could also be that your ISP only gives /56 prefix, regardless of what you request.
It obviously does.
As I said I got DIFFERENT PDs each try, but they all were /56. At least now I know what caused the issue.
