IPv6 with framed IPv6-prefix
-
I also match the prefix and VLAN ID, so I doubt that's your problem.
"I have to also assign a network ID and no matter if I set it to 1 og 123 (so that it matches my VLAN ID), it drops IPv6 for both interfaces."
This makes me wonder if you're in fact getting more than one /64 prefix. What do you have in the DHCPv6 Prefix Delegation size box on the WAN page? It should be 48, if that's what your ISP provides.
-
@JKnott
The DHCPv6 prefix delegation size is set to 48
If I set it to 56 or 64, I get no ipv6 at all. -
Concentrate on your main LAN only. You should be able to change the prefix to anything within your /48. If that doesn't work, do a Packet Capture on your WAN, filtering on DHCPv6 and post the capture file here.
-
@JKnott I have now disabled ipv6 for all Lan interfaces except the main one on vtnet0
I have then changed the prefix ID to a different ones between 0 and ffff
Everytime it works again within a few minutes on vtnet0
As soon as I however reconfigure any of the other interfaces such as vtnet0.123 with ipv6 and a prefix ID different from what is used on vtnet0, it goes one of two ways- Drops ipv6 completely on all interfaces
- Keeps ipv6 on vtnet0, but reports Wan ipv6 gateway as down and devices on vtnet0 cannot get out on ipv6 even with a valid address. They can however still ping ipv6 of the pfsense vtnet0 interface
- Gets ipv6 on both interfaces, but like the above, the routing seems to be no longer working
I can do a packet capture with just vtnet0 and with both vtnet0 and vtnet0.123 and post it here if it can help
-
I can't think of anything else. Post the capture file here, so I can see if it reveals anything.
-
@JKnott got the packet capture done.
attached is pcap with wan on vtnet1.101 and lan on vtnet0.
also a screenshot of the packet capture configpacketcapture-vtnet1.101-20231207075856.pcap
-
I see you're requesting and receiving a /48 prefix. However, I also see you have some release XID packets. That's your system releasing the prefix you've been assigned. I have never seen that in my system. Also, did you restart the system, before you did the packet capture, as described in my instructions? The first line should be a solicit, as shown in mine.
Here mine starts with a solicit and only has 4 packets, ending with the reply. In this, IPv6 works just like the IPv4 DHCP sequence, with only 4 packets for normal operation.
-
This post is deleted! -
@JKnott I disconnected the WAN, rebooted the system. Started the packet capture and then reconnected the WAN.
Could it be my ISP that does something weird? I spoke to a co-worker of mine who runs a Unifi setup with a UDM non-Pro on the same ISP. He had IPv6 working for a few months and then suddenly it stopped working.
If packets are missing in the transmission, then perhaps that might explain why it drops out when connecting the secondary LAN to IPv6I am not sure if it matters anything, but my pfSense runs virtualized and has done for years with no issues
-
@Kenneth_H said in IPv6 with framed IPv6-prefix:
Could it be my ISP that does something weird?
Entirely possible. Around 5 years ago, I had a problem with my ISP. While devices on my LAN got IPv6 addresses, they couldn't reach anything via IPv6. In my own testing I determined the problem was not on my LAN, as I could see pings going out, but no response coming back. I then called tech support and talked to 2nd level (I rarely waste my time talking to 1st level). Working with 2nd level I was able to demonstrate the problem was not on my LAN. When they tried to escalate, the network guys wouldn't do anything, as I had my own router. This despite the fact my next door neighbour had the same problem and he was only using the supplied gateway. Eventually, a senior tech came out, with his own modem and computer, and experienced the same problem. By this point I had discovered an error and even identified the failing CMTS by host name. The tech then took his computer and modem to the head end and tried with 4 different CMTS. It only failed with the one I was connected to. The network guys finally accepted they had a problem and fixed it.
BTW, last spring I was doing some work in that head end and found my CMTS.
Incidentally, I have a strong background in telecom, computers and networks, going back over half a century (I first worked on a LAN in early 1978), so I generally know more about the situation than the 1st level support and have even found myself educating 2nd level. For example, when I was talking to both 2nd level support and the senior tech, I had to explain how DHCPv6-PD works.
-
@JKnott Will try in the coming week to use a mirror port on a switch to capture dhcpv6 output of the router supplied by my ISP.
If that is also missing the expected "solicit" package, then something is perhaps wrong on their implementation -
If I'd known you had a mirror port, I wouldn't have told you to use Packet Capture.
I have a 5 port switch configured as a data tap, which I used when working on that problem. I also have a Cisco switch on my LAN, which also does port mirroring.
-
@JKnott seems some issue is there with the port mirror on my end. Most likely an issue due to me using the same switch as for the LAN side, although I am not using VLAN 101 for anything.
Nothing got mirrored with pfSense or the ISP router and both got no connection. Will dig out an older 8-port managed switch and get it configured as a proper data tap device and try it again.For now I made another packet capture from pfSense and this time it seems as if I got a "solicit" package
packetcapture-vtnet1.101-20231213105317.pcap
Not sure if it all looks correct now, but seems more consistent. it does however seem strange that the lease time is around 5 minutes
-
The first 4 packets are normal, but then you get multiple solicits. The DHCPv6 sequence should be done after the first 4.
-
@Kenneth_H said in IPv6 with framed IPv6-prefix:
it does however seem strange that the lease time is around 5 minutes
My lease time is over 164 hours.
