pfSense gets addresses, clients don't!?
-
I've been having IPv6 issues for a while but never really got around to nailing them down. I feel like I'm 99% of the way there and I'm slightly out of my comfort zone and I may have something set wrong. If someone could sanity-check what I'm doing it would be great, thanks!
Clients are FreeBSD 11.2, Windows 10, and iOS 12.2 with pfSense build
2.5.0.a.20190513.0647. The BSD box reports an IPv6 of ::1/128 which is obviously wrong. pfSense interfaces are showing the correct info:-The IPv6 addresses here are in the correct ranges as per my ISP who give me a /64 ND prefix and a delegated /48. When I previously looked at it, there was a suggestion my ISP was sending out the /128 but that doesn't seem to be the case.
The routing system log is showing this:-
But the WAN config shows a /64 for the ND prefix...
And the DHCPv6 Options also appear to be picking up /64
There's nothing much in the LAN configuration...
...and the Router Advertisements look like this.
Thanks in advance!
-
moved to 2.5 section..
Can tell you right now that /48 on you lan is wrong..
When you track you should get the first /64 out of what was delegated to you.. Not a /48..
-
That's interesting, because I'm not telling it what to use (so far as I can see) and the /48 it is in is the one my ISP assigned me. So where the heck is it getting that from!?
If I was to try and do a packet capture to try to see what's being sent, are what settings would you recommend?
-
@johnpoz - if I was to decide to use my delegated /48 instead, do I set the WAN IP as fixed and then “track” it on the LAN or set fixed IPs in the delegated range for both?
I really feel like I should know this kind of thing as I covered IP6 and a lot of low level networking stuff at uni but it was 20 years ago!
-
you would never put a /48 on an interface - would be /64
-
Looks like you're on Zen. I have this working with IPv6 on 2.4.4.
In your WAN>DHCP6 Client Configuration:
- uncheck 'Only request an IPv6 prefix, do not request an IPv6 address'.
- Change DHCPv6 Prefix Delegation size to 48
There are some great posts by David_W which you might find useful:
https://forums.thinkbroadband.com/zen/t/4542153-ipv6-problems.html -
@bigsy - thanks I am with Zen, I changed those options and the only thing that has changed is that the LAN interface is now showing as a /64 subnet but I can't work out what change caused that to happen, when I roll the config back to before any changes it doesn't revert to the /48.
The /64 I get on the LAN adapter is still out of the /48 range I'm given by the ISP. I've fired up a packet capture to see what was going on and I can see the client I'm testing from making DHCPv6 Solicit requests - but pfSense is not responding to them.
Unless someone has any better ideas I'm going to set my WAN IPv6 to None, give LAN a static address and start work from there... I figure if pfSense isn't responding to solicit requests in that situation then I've done pretty much all I can.
-
@motific Can you try things in pfsense 2.4.4? IPv6 with Zen is definitely fine with me on 2.4.4p3. I have not tried it with 2.5.0 so perhaps something has broken there?
Do you have one of the original beta-tester IPv6 Zen setups or the framed IPv6 route which I think they now give out? I now have the latter. I have the two virtual IP entries (/128 IP Alias and /48 Other) referred to in the linked discussion and have set static addresses on my internal interfaces.
-
@bigsy - I have now taken Zen completely out of the equation and disabled IP6 on the WAN and statically assigned the LAN.
As of now the problem is purely pfSense not handing out addresses. I’ll post more info later.
-
@motific said in pfSense gets addresses, clients don't!?:
And the DHCPv6 Options also appear to be picking up /64
That range doesn't looks 'ok' to me.
I'm not using Track-IPv6 myself, but I assigned the first /64 chunk out of the /48 to my LAN, the DHCP6 pool will be correct then ....
(next /64 chunk of the /48 on second LAN, etc.) -
@johnpoz said in pfSense gets addresses, clients don't!?:
moved to 2.5 section..
Can tell you right now that /48 on you lan is wrong..
When you track you should get the first /64 out of what was delegated to you.. Not a /48..IPv6 works fine with Zen, mine is configured as follows:-
The VLANS are configured statically, split your /48.
They are your addresses and will only ever be allocated to you, there's no need to track.
-
-
@NogBadTheBad - I basically have changed it to how you have it now but with the WAN IPV6 set to none.
I have done a packet capture from pfSense and can see DHCPv6 Solicit requests going unanswered.
-
@motific said in pfSense gets addresses, clients don't!?:
e been having IPv6 issues for a while but never really got around to nailing them down. I feel like I'm 99% of the way there and I'm slightly out of my comfort zone and I may have something set wrong. If someone could sanity-check what I'm doing it would be great, thanks!
Clients are FreeBSD 11.2, Windows 10, and iOS 12.2 with pfSense build
2.5.0.a.20190513.0647. The BSD box reports an IPv6 of ::1/128 which is obviously wrong. pfSense interfaces are showing the correct info:-Maybe its an issue with the development release, I don't know as I run 2.4.4-RELEASE-p3 rather than a development release.
BTW all my clients report a /128, it's correct DHCPv6 servers give out addresses but don't tell the client anything about the subnet as thats handled by the RAs
-
If your wanting to use dhcpv6 vs just ra, you need to use the managed with onlink I do believe. Not 100% on that since don't ever run dhcpv6.. Don't see a point to it in my setup.
You really should post up your dhvp6 settings and your RA settings.
with out the onlink flag your prob only going to get /128's but that is going to be troublesome.. Is been some time where did anything with that.
My current play with ipv6, I just set static on boxes I want to use ipv6 on..
But as I think about it more your going down the dhcpv6 path you prob want assisted mode with onlink and auto..
-
@johnpoz - I’ve changed the config a lot since I posted originally so I’ll post a fresh set of screenshots when I’m back in a couple of hours. I don’t really mind if what IPv6 assignment I use if it works because nothing is working. Though if there is an issue with DHCPv6 in 2.5.0 then it probably needs hunting down.
I traced some of the original issues in the thread you quoted back to pfBlocker (I’m on BBCan177’s private beta list) there was something pointing to the virtual IP when it shouldn’t have been so for now I have that disabled until I sort this out.
-
@NogBadTheBad - my clients only show a link-local address.
-
I could fire up a 2.5 snap... But I just fired up dhvp6 on 2.4.4p3 and working fine... My client pulled global IPv6 out of the ranged I called for, etc.
And using onlink, so I get valid route for the local /64
And clearly can talk outbound IPv6
$ ping ipv6.google.com Pinging ipv6.l.google.com [2607:f8b0:4009:800::200e] with 32 bytes of data: Reply from 2607:f8b0:4009:800::200e: time=44ms Reply from 2607:f8b0:4009:800::200e: time=32ms Reply from 2607:f8b0:4009:800::200e: time=43ms Reply from 2607:f8b0:4009:800::200e: time=32ms Ping statistics for 2607:f8b0:4009:800::200e: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 32ms, Maximum = 44ms, Average = 37ms
-
i think we have a "Layer 8" problem here, idk about zen but i have 2 different tunnel with Hurricane electric (HE) with pfsense 2.5.0 in 2 different home, i have WAN configured as none and in the lan interface i assigned a static ip from the first /64 chunk out of the /48 from HE after that i enabled dhcpv6 with mode Assisted -ra flags (idk if it's right but it work for me)
So if i assign something like 2001:xxx:xx:xxx:: 1 to the lan interface, the available range for dhcpv6 should be
2001:xxx:xxx:xxx:: 2 to 2001:xxx:xx:xxx:ffff:ffff:ffff:ffff just to be safe. i have no problem at all with dhcpv6 and my pc have working ipv6 address and dns from pfsense 2.5.0
-
@kiokoman “idk if it’s right” is probably not a phrase you want to be using when suggesting a Layer 8 issue :)