IPv6/DHCP6 Permission Denied
-
Hi!
I've been trying to troubleshoot an IPv6 problem for a while now. One of the other ISPs in my area cut my connection to the Internet, and since restoring connectivity I don't get IPv6 anymore. I can get IPv4 just fine. I'm sure I'm missing something obvious but I can't figure out what it is. Given the nature of the error I also suspect it may have been working for the wrong reason when it was working.
ISP: Spectrum in the Ohio area
WAN IPv6 Address type: DHCP6
WAN DHCP6 settings: Send prefix delegation hint checked, delegation size /56 (tried with /60 as well). Tried with and without "Do not wait for RA". Debug mode is checked (but outputs nothing useful that I can see).
LAN IPv6: Track Interface
LAN Prefix: 1
PFSense Version:2.6.0-RELEASE (amd64) built on Mon Jan 31 19:57:53 UTC 2022 FreeBSD 12.3-STABLEWhen dhcp6c starts up it reaches "sending solicit" and then I get "Permission Denied" (making me think it was working but for the wrong reason...). It only starts when I check "Do not wait for RA". If I wait for RA nothing ever happens with it, and no matter what I do the WAN interface doesn't seem to ever get an IPv6 gateway or address.
Commonly Requested Screenprints:
Appreciate any insights... Thanks!
-
Do a packet capture of the full DHCPv6 sequence and post the capture file here.
-
The file was too big to upload to the forum... https://c50e8af9-ebaa-0da9-ad27-6627e4c3b9d7.s3.us-east-2.amazonaws.com/packetcapture.cap.
-
Did you capture only DHCPv6? That's a fairly small file.
-
@jknott That’s all the traffic from a few minutes. I put deny rules on the LAN interface to try to isolate just firewall traffic, then unplugged WAN, restarted, started capture and plugged in the cable.
What’s weird is I didn’t see any DHCP6 traffic at all…
-
When you run Packet Capture, you select what you want, which has nothing to do with the firewall rules. For DHCPv6, you can use port 546 or 547. This goes in the "Port" box. This is all you need to filter on, as DHCPv6 is the only thing that uses those port numbers. If you were filtering on some other protocol which can use IPv4 or IPv6, such as DNS, then you'd also select on one of those, if needed.
After running Packet Capture for a couple of minutes after boot up, you should have all the DHCPv6 you're going to see for a while. You then download the capture file, to be uploaded here.
Take a look around Packet Capture to see what it can do. You can filter on protocol, IPv4/IPv6, IP address and MAC address. By using these, you can greatly reduce the number of unwanted packets you capture.
-
@jknott I thought about that, and decided to keep it unfiltered since I wanted to make sure I got the router advertisements, etc. so that I could see if I was even getting the right IPv6 traffic to start the process.
-
-
@jknott https://c50e8af9-ebaa-0da9-ad27-6627e4c3b9d7.s3.us-east-2.amazonaws.com/do+not+wait+for+ra.pcapng https://c50e8af9-ebaa-0da9-ad27-6627e4c3b9d7.s3.us-east-2.amazonaws.com/wait+for+ra.pcapng, both done via a data tap. As before, no filters were applied -- so this should include every packet.
For "Do not wait for RA" I waited to confirm I could see it attempt to get a DHCP6 lease in the logs.
-
Your original post talked about dhcpv6 problems. The way to understand that is to see what's actually happening during the full DHCPv6 sequence. There's more to it than just verifying the attempt in the logs. For example, a few years ago, I had a problem where my network could not access the Internet on IPv6, even though I was getting a prefix assigned and addresses assigned on my LAN. Through my testing with Wireshark, I determined I wasn't getting responses to my pings and pings from outside of my network never reached it. Through further testing, I was able to determine the problem was at my ISP's office and I even identified the failing system by host name. I couldn't have done that without capturing the full DHCPv6 sequence. After I determined that, a senior tech came to my home with his own modem and computer and saw it still failed. He then went to the office and tried with 4 different CMTS, including the one I'm connected to. Only mine failed. After that, the problem was resolved, but that only happened because I made the effort to examine the full DHCPv6 sequence. With IPv6, DHCP does a lot more than with IPv4, so you have to examine it properly.
Here's what I found with my packet captures:
Status code
Option: Status code (13)
Length: 56
Value: 00064e6f2070726566697820617661696c61626c65206f6e...
Status Code: NoPrefixAvail (6)
Status Message: No prefix available on Link 'CMTS89.WLFDLE-BNDL1-GRP3'That status message about no prefix showed where the problem was and includes the host name of the failing CMTS.
When you start doing packet captures, it's a good idea to take and save captures of when things are working properly, so you can compare when they're not, as I did.
-
So I did some more digging... it turns out that somehow dhcp6c was running as an unprivileged user -- hence why the solicit messages were failing with "Permission denied" and not showing up in the packet captures. Now I can see the solicit messages, but Spectrum isn't sending any responses. Somewhere along the line that package must have gotten screwed up somehow...
Now to figure out why my solicit messages are getting ignored...
-
Once again, you need packet captures, to see what's happening.
