Loosing IPV6 connectivity after 1 hour with HG8245Q2 (OI Firmware)
-
Hi, as the topic say's I can’t seem to get IPV6 to work for longer than 1 hour, the firewall looses it’s WAN IP and all clients on LAN side loose IPV6 connectivity.
Only way to get it back is to reboot the firewall, but it’s just another hour of connectivity.
From what I can see, may ISP (OI) provides a /56 prefix to the HG8245Q2 which in turn is providing a /64 prefix to PFSense.Tried setting IPv6 on interface to none and back to DHCP minutes later to see if it would work again without success, only a reboot makes it work, but again for only 1 hour.
Some information.
WAN side of HG8245Q2
DHCP on HG8245Q2
Current DHCP Client on PFSENSE
Please HELP!!!!
-
@Katan said in Loosing IPV6 connectivity after 1 hour with HG8245Q2 (OI Firmware):
the firewall looses it’s WAN IP and all clients on LAN side loose IPV6 connectivity
What happens if you use a computer in place of pfSense? If it also loses it's IPv6 address, then the problem is with the ISP or the HG8245Q2.
They only give you a single /64 out of a /56? Wow, they're generous! </sarcasm>.
-
Hi,
Connected a windows Laptop directly to the HG8245Q2, and IPv6 is working fine for over 2 hours.
Will leave it ON overnight and check again in the morning.
Checking my Syslog server I found this 1 hour after a Pfsense restart yesterday.
I believe if I add another router behind the HG8245Q2 it would provide another /64 prefix for it. But for my usage one is enough.
Did another test, here is the DHCP log from when the connectivity dies.
Laptop connected to HG8245Q2 still works.
Edit:
In the morning the laptop still have working IPv6.Looks like it´s something on Pfsense side.
-
Looks like I found the problem.
When the interface comes up it sends the solicit using a link-local address, and the HG8245Q2 answers.
From Wireshark.
And after that, it uses the global address, and doesn´t get an answer from the HG8245Q2.
Is there a way to make dhcpv6c use the link-local address aways?
-
Can you post the entire capture or at least the part where it changes? I'd like to see what happens when it changes from one to the other. I have a saved capture which shows only link local addresses, as I expected. I have no idea why a global address is used as link local should be good enough to reach the DHCP server or relay.
Do you have anything in the Advanced DHCP6 Client Configuration?
-
This is what a have on hand.
I´m not so sure now.
did a release and renew and after some time it´s using the link-local address, but no answer...Starting to loose my sanity here.
Edit:
Nothing in Advanced DHCP6 Client Configuration .Edit.
@JKnott
As requested. Source IP Change.7z -
Those files don't appear to contain DHCPv6. To capture it, filter on protocol 546. That will capture only DHCPv6 packets. You apparently captured it properly in the captures above.
Also, there's no need to zip those files, unless you're still using a dial up modem.
-
Strange, just opened the file.
Edit:
A capture from the windows laptop, that just works.
Laptop Dhcpv6.pcapnghave the full capture if needed.
-
@Katan said in Loosing IPV6 connectivity after 1 hour with HG8245Q2 (OI Firmware):
Strange, just opened the file.
Did you check the one you posted on the site? I don't see any DHCPv6 in it. Here's what I see with your Source IP Change file.
-
@JKnott
Yes, the same one.
anyway, here is the file with just DHCPV6.
Source IP Change Dhcpv6.pcapng -
A couple of things. The address changes when it goes from using request to renew. Also, that happens after only a minute or so, which seems fast. I haven't ever seen DHCP, on either IPv4 or IPv6 do something that fast. I tried to monitor my connection over night, but Packet Capture timed out. I'll have to try again with my managed switch.
PfSense running on Qotom mini PC
i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
UniFi AC-Lite access pointI haven't lost my mind. It's around here...somewhere...
-
Are you sure it´s just a minute, looking on the column time it shows 30 minutes to me (it took about 30 minutes to issue the RENEW during capture, as I was waiting for it to stop capturing).
It´s a 3600s lease.
-
I have been running Wireshark between my firewall and cable modem and have noticed some differences. For example on yours, you go through several solicit/advertise frames, when the normal process is solicit/advertise/request/reply. Then you get one request/reply and then a bunch of renews. On my system, I just get a single solicit/advertise/request/reply sequence and there has been nothing else for 20 minutes so far. Also, both your preferred and valid lifetimes are 3600 seconds, whereas mine are 148853 and 580853. So, I would expect a renewal attempt at just over 43 hours, not 1 as you have. I'll leave my test config up for the rest of the day, but I doubt I'll see anything, given that 43 hour wait for the next request.
Incidentally, the way I'm monitoring this is through a "data tap" or "network tap" I made with a 5 port managed switch. I placed it between my pfSense firewall and cable modem and use a notebook computer, running Wireshark to capture the traffic.
Here's the instructions I posted for making one:
Creating a "data tap" -
@Katan said in Loosing IPV6 connectivity after 1 hour with HG8245Q2 (OI Firmware):
It´s a 3600s lease.
Take a look at the times in Wireshark. Everything there happened in a half hour.
-
@JKnott
Unfortunatly, I only have a 24 port procurve switch that is on the lan side. -
Still, Packet Capture showed what was happening on the WAN side and it doesn't look right to me. I just glanced at the computer where I'm running Wireshark and still haven't seen anything happening in over an hour.
Also, those 5 port managed switches are cheap. I keep mine in my computer bag, so that it will be handy when I need it. It's just part of my toolkit, along with my Ethernet cable tester and punch tools.
-
One other thing I've noticed. You're requesting and receiving a /64 prefix. Is that all your ISP provides? It shouldn't cause a problem though.
-
@JKnott said in Loosing IPV6 connectivity after 1 hour with HG8245Q2 (OI Firmware):
One other thing I've noticed. You're requesting and receiving a /64 prefix. Is that all your ISP provides? It shouldn't cause a problem though.
They provide a /56, but for their router, and it delegates in turn /64 prefixes.
Unfortunetly it does not have the option to run as bridge (at least with the user provided with the router).For IPv4 I have to live with a double NAT.
-
????
How are you getting a prefix for your LAN? That's normally done with DHCPv6-PD, but that's generally not provided by gateways.
However, that might explain the strange things in your packet capture. Your prefix is 2804:d57:4b04:6200::. Is your WAN address within that range?
-
