pfSense gets addresses, clients don't!?
-
@kiokoman “idk if it’s right” is probably not a phrase you want to be using when suggesting a Layer 8 issue :)
-
@motific yeah that was only my intention to say something funny not to offend or else :) "idk if it's right" because i don't remember why i selected that options when i have configured my interface, you have to pardon me because english is not my first language and sometimes i don't use/don't know the right word
now that i think about it, it's because i have android devices that only use SLAAC for IPv6 addresses, as you can see on the photo i have ath0 and athp0 in that machine.
-
@kiokoman - I took it in the spirit it was intended! It was funny and I'm totally not ruling out a Layer-8 issue!
Android devices aren't a concern for me, I don't allow them on this network. :)
-
I have basically copied @NogBadTheBad 's config, I have IPv6 to WAN directly from pfSense. LAN clients get nothing. You can see from the packet capture that pfSense is receiving Solicit requests, but does not answer and (so far as I can tell) it should.
WAN is on DHCP, pfSense can ping IPv6 addresses on the internet.
LAN is static
These are the results from that config...
-
Hmmm very odd, I'm a bit stuck as mine works fine and to be honest when I set it up I didn't know alot about IPv6, it just sort of worked.
-
maybe a stupid question but did you check the firewall to see if ICMPv6 is blocked?
-
@motific I’m pretty sure your WAN is still not correct. Zen hand out a /48 and this should be reflected in the WAN>DHCP6 Client Configuration>DHCP6 Prefix Delegation size.
Can you post the information that Zen sent you whenever you had IPv6 enabled (minus IP addresses)?
-
It will be something like mine:-
Thank you for your email. Your subscriber account (zenxxxx@zen) has now been enabled for IPv6. The new attributes will take effect next time the session is restarted. Your IPv6 address details are;
ND Prefix: 2a02:xxxx:xxxx:xx::/64
PD Prefix: 2a02:yyyy:yyyy::/48The two prefixes are described below, along with some further information on the Zen IPv6 service:
/64 Neighbour Discovery (ND) Prefix. This is used to automatically address the WAN interface of your Router, or if you are directly connected without a router, the WAN interface of that device.
/48 Delegation Prefix. This is usually provided over DHCPv6, and requires that your router acts as a requesting router for the purpose of IPv6 delegation RFC3633 - (https://tools.ietf.org/html/rfc3633). Subnets of this prefix are used by the CPE to address devices on the LAN. If prefix delegation is not supported on the router, a suggested interface ID and static route is available, which should allow routing to take place.
-
@bigsy - WAN is fine, it's in the ranges provided by Zen and it works just fine as I can ping IPv6 hosts from pfSense without an issue...
What I can't do is get any IPs to clients.
But if you're interested...
Good Afternoon,
Your subscriber account zenxxxxxx@zen, has been enabled for IPv6. The new attributes will take effect next time the session is restarted.
Your IPv6 Address details are;
ND Prefix 2a02:8011:XXXX:X::/64
Delegated Prefix 2a02:8010:XXXX::/48
Regards, -
@kiokoman - At this point anything is worth checking but as the packet capture was from my pfSense box I'd expect outbound blocked content not to show up (unless there's some 'gotcha' I don't know about).
I've just done a capture from a client, that is seeing ICMPv6 messages btw.
-
Wow pretty impressive email, and they delegate a /48 nice!!
You understand none of that actually means anything if your wanting to hand out dhcpv6 on your lan and that is not working.. Forget about the the delegation or any of that until figure out why when you set a static on your lan, and enable dhcpv6 your not sending back anything..
-
@johnpoz - I get that entirely. I was just about to point that out.
Interestingly, stateless addresses aren't working either... feel free to correct me if I'm wrong here - as I understand it if the RA messages are getting out then in that mode the clients should be giving themselves addresses via Stateless/SLAAC, right?
I'm going back to the packet captures and go through them in more detail. I'll let you know what I find.
-
So here is the thing if there was something wrong with 2.5 and clients being to get ipv6 behind it... The boards would be just on fire with posts about it...
We need to figure out what is unique to your setup that is the problem... Doesn't matter if you get a delegation from your isp or what is on our wan... If you setup an ipv6 on your lan, then that is what your clients should get be it auto, dhcpv6, whatever.. Your wan is out of the picture..
-
@johnpoz - That's a good point, there would be noise about it if it were purely a 2.5 issue. My IPv6 on LAN is set completely manually, so WAN is now completely irrelevant as you say.
It looks like the problem runs deeper than I originally thought, looking back at the packet capture I'm seeing as well as not responding to DHCPv6 Solicit requests there is no ICMPv6 NDP traffic leaving on the LAN interface at all, it's all inbound.
radvd appears to be running etc.
I think at this point I'm going to wipe this box, reconfigure and see what happens rather than spend any more time trying to figure out what has happened to it. I'll get back to you all either way on how that goes.
-
this is what i found, specific configuration for Zen uk and ipv6, i hope it can be useful for you.
WAN
IPv6 using DHCP, select DHCP6 in the IPv6 connection
DHCPv6 Prefix Delegation size /48
Use IPv4 connectivity as parent interfaceLAN
Select Interfaces ‣ [LAN] and set the IPv6 Configuration Type to ‘Track Interface’
set the Track IPv6 Interface to WAN,
set the IPv6 Prefix ID to 0.Reboot the system
DHCPv6 LAN server should be set automatically with subnet mask /64
range from *:0000:0001 to *:ffff:ffff:ffff -
Make sure this: https://docs.netgate.com/pfsense/en/latest/book/config/advanced-networking.html#allow-ipv6 is enabled.
-
@kiokoman - read what johnpoz wrote above.
-
@Grimson - very funny.
-
@motific it was only so that, if you wipe your machine and start over, you have a summary of the step needed
-
@kiokoman - thanks, looks like apart from doing the DHCP request via IP4 it was all preset and ready to go out of the box. :)
Having wiped the machine the problem seems to be sorted.
