[SOLVED] Can`t get provided /56 prefix
I am a little bit lost with the pfsense config. I am trying to get the /56 prefix from my ISP but I have no luck. I`ve tried (I think) all configurations on the DHCP6 WAN Interface but I always get this:
Sep 27 10:37:08 dhcp6c 80062 create a prefix 2a02:8106:26:c200::/64 pltime=1105, vltime=1105 Sep 27 10:37:08 dhcp6c 80062 invalid prefix length 64 + 8 + 64
The pfsense is behind a FritzBox 6430 in Bridge Mode. If I only use the FritzBox (without the pfsense and not in bridge mode) it works correct. I get the IP with an /56 prefix.
Does anyone has a clue?
You wouldn't actually get a /56, the /56 would delegated to you.. You wouldn't ever set a /56 prefix directly on an interface.
is this really true? Sorry for my question I just want to I understand this whole thing correctly. For example in my FritzBox I have to choose the /56 to get /56, otherwise it will only get a /64. In this video this guy also configures the pfsense this way and he can then dalegate a chosen prefix to his lan interfaces (this is what I want to do). So he configures the WAN DHCP6 with a /48 prefix and then chooses AAAA for the LAN. So he now has this xxxx:xxxx:xxxx:AAAA::/64 on the LAN.
Again the /56 would not be set anywhere.. it would be delegated to you..
Then you would set your lan interfaces to track this. And use the specific prefix you want out of that delegation.
That worked. Now I have an IPv6 address on my LAN with my self chosen prefix. THANK YOU!
But now the IPv6 test on this website failed. My ntp demon can`t get any connection and i can't ping 184.108.40.206 from pfsense also.
P.S.: I have alsready set this rule in the FW.
IPv4+IPv6 TCP/UDP | LAN net | * | * | * | * | none | "internet rule"
i can't ping 220.127.116.11 from pfsense also.
Not sure what that would have to do with ipv6 ;)
Why are you only allowing tcp/udp? For ndp to work your would need to allow for icmpv6
I don't know it either. ;) But after switching to IPv6 I lost my connection like I said.
Thank you for the hint, but I pinged google directly from the pfsense so this rule doesn't matter or am I wrong?
Now I have connection from my LAN and the ping is ok. Only after I unchecked the "Block bogon networks" option on WAN. Why is this?
The ntp daemon on the pfsense still get' s no connection.
Bogon shouldn't be a problem, unless your wan address was listed under the bogon networks.. Could be red herring where you removing that reloaded the rules? Look in the table for what is listed in the bogon table, and what networks your using to see if there is a conflict - where you seeing blocked entries in your firewall for bogon?
Now I have connection but only after I unchecked the "Block bogon networks" option on WAN. Why is this?
Bogon networks are a collections of networks destinations that are not defined.
18.104.22.168 hasn't been placed on that list - if this was the case, you would hear people scream all over the world right now.
Reload the firewall, or do a clean reboot to settle everything in place.
You didn't have bogon on your "lan" side did you - this is common mistake ;)
Kalle13 last edited by
@Gertjan I rechecked it and now I am rebooting.
@johnpoz No, luckily I didn' t have bogon checked on my LAN. ;)
I was a little bit dumb. I pinged google with IPv4. This went wright. After pinging with IPv6 I have a packet loss of 100% :(
this is common mistake
I just enabled this. Is this 'dangerous' ?? (Ok, pretty useless for sure).
I post this through my LAN using bogons on LAN .... not the impression I broke something.
Btw : I still can ping 22.214.171.124 - and discovered that they actually reply also.
I don' t know why but know I have connection through IPv6 from LAN. I also can ping "google.com" from pfsense and my ntp daemon also has connection. THANK YOU guys for your help!
look what is in the bogon table ;)
Plus multicast - which depending on what your wanting to do exactly could cause you problems... Also look in the bogonV6 table..
There would never be a reason put bogon on your local networks that I can think of.. They lucky they pull out the rfc1918 space, which is actually included in bogon..
Plus multicast ....
Ok, so I'm saved by the fact that DHCP traffic is passed upfront, before the bogon rule list (example).
Thanks for the explanation.