If internet goes down, IPV6 won't work until reboot
-
@gertjan said in If internet goes down, IPV6 won't work until reboot:
Try this : when you go to System > Routing > Gateways, hit
and then
does IPv6 comes back ?
Didn't work.
One thing I should clarify is I ran some tests after I made this thread, where I power cycled the modem and also unplugged and plugged in the ethernet cable. IPV6 still works when doing that.
What doesn't work is if I change my spoofed MAC address, and then reboot my modem. This forces an IP address change from the ISP. That's when I need to reboot my router.
This issue will also happen if the internet goes down for some time, which probably causes the same effect as my public IP address being reset.
@bob-dig said in If internet goes down, IPV6 won't work until reboot:
@jackthesmack It is normal behavior of pfSense. Probably because the leases haven't expired and there is no solution for changing prefixes in this time frame, is my guess.
That makes sense. I have had this issue for years.
-
@JacktheSmack
You still have this issue? I'm experiencing the same. As soon as the wan connectivity goes down and comes back up, IPv4 gets restored, but not the IPv6. After a reboot of the pfsense IPv6 is available immeditately. I then also lose the link local address on my wan interface and if I do a tcpdump on the pfsense I don't see any IPv6 packets anymore. It seems that the pfsense has completely disabled IPv6 in this case. -
@em_gerber Yep - same here on 22.05. This is pretty garbage behaviour from pfSense. It's a basic function of the product to renew ip6 upon WAN loss of connectivity, yet it's unable to.
If it's not a 'bug' - the comment above suggesting this is default behaviour seems totally bizarre to me - then it's a 'product improvement' request to get this fixed !
I created a bug for this; it needs addressing and fixing urgently.
https://redmine.pfsense.org/issues/13555 -
@ahxcjay said in If internet goes down, IPV6 won't work until reboot:
https://redmine.pfsense.org/issues/13555
Could you add in https://redmine.pfsense.org/issues/13555 :
What is your IPv4 WAN setup ?
ADS/Fibre/Coax/Satellite/Other ?
Multi WAN or not ?
What is your IPv6 setup ?You said : "Replicable? Yes. Every single time." and I believe you.
The thing is : when I rip out my WAN cable, the one going to my ISP upstream router, my WAN comes back. I'm using the DHCP client on WAN.
My IPv6 isn't realted to my ISP, as they don't know what "IPv6" is.
I use the tunnel.he.net from hurricane using a GIF interface to create a IPv6 gateway.Just to illustrate that 'what is your setup' is important.
What you want is : a coder looks at your bug report, and he should use the same WAN set up as you. So he can test the current situation also, and he will be able to his code the corrections locally before pushing a fix. -
@gertjan Very fair point! No worries at all. I’ll add in the information later this morning.
-
@ahxcjay It really need some work here, regarding when a prefix changes.
-
@gertjan ..done.
IPv4 WAN setup ?
Ethernet to [Nokia] Fibre ONT [Verizon US]
Multi WAN or not ?
Single WAN.
What is your IPv6 setup ?
Configuration Type: DHCP6
Prefix: /56
Send IPv6 prefix hint: enabled
Do not wait for RA: Enabled.
Do not allow PD/Address release: Enabled -
@jackthesmack Not sure if this will help but I've had issues which led me to the ppp-linkdown script file. If this is being called to bring your connection down, it doesn't remove the signpost files for IPv6, this can make it look like IPv6 is still up even if it isn't.
I've attached a modified ppp_linkdown script, see if it helps.
You can update this script using Diagnostics - Edit File then browse to /usr/local/sbin/ppp-linkdown (take a copy of all the existing script so you can easily go back) and paste over the script from below and click Save. This file is modified to remove the IPv6 pointer files from the tmp folder.
#!/bin/sh # # ppp-linkdown # # part of pfSense (https://www.pfsense.org) # Copyright (c) 2004-2013 BSD Perimeter # Copyright (c) 2013-2016 Electric Sheep Fencing # Copyright (c) 2014-2022 Rubicon Communications, LLC (Netgate) # All rights reserved. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. IF="${1}" PROTOCOL="${2}" LOCAL_IP="${3}" if [ -f /tmp/${IF}up ] && [ -f /conf/${IF}.log ]; then seconds=$((`date -j +%s` - `/usr/bin/stat -f %m /tmp/${IF}up`)) /usr/local/sbin/ppp-log-uptime.sh $seconds ${IF} & fi if echo "${IF}" | /usr/bin/egrep -qv "ppp[0-9]+"; then /etc/rc.kill_states ${IF} ${LOCAL_IP} fi if [ "${PROTOCOL}" == "inet" && -s "/tmp/${IF}_defaultgw" ]; then GW=`head -n 1 /tmp/${IF}_defaultgw` DGW=`/sbin/route -n get -inet default | /usr/bin/awk '/gateway:/ {print $2}'` # Only remove the default gateway if it matches the gateway for this interface. See redmine #1837 if [ "${GW}" = "${DGW}" ]; then /sbin/route -q delete default ${GW} fi fi if [ "${PROTOCOL}" == "inet6" ]; then /usr/local/sbin/ppp-ipv6 ${IF} down fi # delete the node just in case mpd cannot do that /usr/sbin/ngctl shutdown ${IF}: if [ -f "/var/etc/nameserver_${IF}" ]; then # Remove old entries for nameserver in `cat /var/etc/nameserver_${IF}`; do /sbin/route -q delete ${nameserver} >/dev/null 2>&1 done /bin/rm -f /var/etc/nameserver_${IF} fi # Do not remove gateway used during filter reload. # Remove tmp signpost files if [ "${PROTOCOL}" == "inet" ]; then if [ -f "/tmp/${IF}_router" ]; then /bin/mv /tmp/${IF}_router /tmp/${IF}_router.last fi /bin/rm -f /tmp/${IF}up /bin/rm -f /tmp/${IF}_ip fi if [ "${PROTOCOL}" == "inet6" ]; then if [ -f "/tmp/${IF}_routerv6" ]; then /bin/mv /tmp/${IF}_routerv6 /tmp/${IF}_routerv6.last fi /bin/rm -f /tmp/${IF}upv6 /bin/rm -f /tmp/${IF}_ipv6 fi /usr/local/sbin/pfSctl -c 'service reload dns' -
Is there any way to re-initiate a dhcp6c request for an address without rebooting?
-
This post is deleted! -
@stephenw10 Hi - any way to get this moving internally? The redmine - https://redmine.pfsense.org/issues/13555 - has plenty of others able to replicate the issue. The issue does need fixing, please.
-
I ran into this yesterday - I unplugged my fiber ONT (Nokia/Alcatel I-211M-L on Verizon Fios) in order to put in a new battery backup. When I plugged it back in again, my pfSense box did not have any IPv6 connectivity at all until I rebooted. I plan to do some tests of the new battery to make sure it is wired properly and to see how long it will last in an outage, but I don't want to have to reboot pfSense multiple times to restore IPv6 access each time.
-
@kohenkatz said in If internet goes down, IPV6 won't work until reboot:
but I don't want to have to reboot pfSense multiple times to restore IPv6 access each time.
..but you will. It's a bug, and one that is not being prioritised or picked up by Netgate engineers (unfortunately), despite others experiencing the exact same issue.
-
I have the same issue. As soon as the bridge goes down pfSense completely removes IPv6. I was able to implement a "workaround". I added a switch between the bridge and pfSense. Now, if the bridge goes down IPv6 remains. For me it seems somehow L2 related, pfSense removes IPv6 completely if the port goes down...
But I agree, this bug should defenitely prioritised and fixed.
-
@em_gerber good grief - just tried it. Adding a switch between ONT & FW resolves ip6 not recovering.
-
@ahxcjay said in If internet goes down, IPV6 won't work until reboot:
good grief - just tried it. Adding a switch between ONT & FW resolves ip6 not recovering.
If you put a managed switch there, you can use it to monitor the traffic, using Wireshark. PfSense has Packet Capture, but I find it much better to use Wireshark. Five port managed switches are cheap and you can configure one to act as a data tap.
-
If you put a managed switch there, you can use it to monitor the traffic, using Wireshark. PfSense has Packet Capture, but I find it much better to use Wireshark. Five port managed switches are cheap and you can configure one to act as a data tap.
Really? You can actually tap off a managed switch? Blimey. I had no idea.
Any other basic tips to pass on in a forum full of mostly networking experts..?
-
@ahxcjay said in If internet goes down, IPV6 won't work until reboot:
Really? You can actually tap off a managed switch? Blimey. I had no idea.
The only caution is with connection speeds approaching 1 Gb and in both directions if on fibre, you could run into overflow problems, where there's more data than the switch can pass to the monitor computer, unless you get a faster switch and NIC on the computer. My own connection is 1 Gb down (actually 1.5 Gb but limited by hardware) and 50 up, so I'm OK for now.
BTW, I first came across that monitor function over 15 years ago, when I was working with Adtran switches.
-
OK now I am having a new problem related to this. IPV6 addresses are all set and everything, but I have 100% packet loss. If I reboot the router, it's still stuck.
But if I turn off the router and modem, wait 10 seconds, then turn the both back on, then IPV6 works, with one caveat: The gateway display shows 100% packet loss for IPV4, even though it works perfectly fine.
If I reboot the router, I once again get 100% packet loss with IPV6 and it doesn't work for the router or any devices on the network.
One interesting quirk is initially, for the first second or two, there is no packet loss, but then there is full packet loss after that. Which is why in my screenshot it's not 100%, because of the initial packets that get through. But eventually it works its way up to 100%.
Also I just tried turning off just the router (not the modem), waiting 10 seconds, then turning it back on. Now both work, but there was 10-15% packet loss for the first few minutes. But now it's settled down to 5-10%, which is still bad.
Speed test seems fine though.
Same with videogames
-
7 hours later packet loss is now at 0%. Issue still remains: Rebooting the router breaks IPV6
