IPv6 No Gateway after 2.5 upgrade

g.shaffer

Given how this issue cascades throughout the system - it breaks the gateway, routing, firewall rules, etc. I amazed that netgate doesn't appear to be looking at this. IPv6 was rock solid in 2.4.5-p1, seems to have been broken in 2.5.0!

pete

@chicaneau

Try this:

1 - remove all of the IP6 related stuff on your WAN / LAN links.
2 - TFTP to the /tmp directory and remove all related IP6 entries.
3 - reboot PFSense and your modem
4 - re-enable IP6 on WAN / LAN interfaces.

See if that works.

chicaneau

@pete tried this. No difference. I’m on the cusp of giving up on this. Might need someone much smarter than me to resolve the underlying routing issues

lohphat

I'm seeing similar behavior on SG-3100 21.02_1. Speculum (NYC)

I have to manually specify a monitoring IPv6 address (or disable monitoring and assume it's up).

MikeV7896

@mloiterman If you're routing with rules, that's another effect of this gateway issue. If the gateway doesn't populate, there's no gateway to be selected in the rules. Some have found a way around by manually creating files or manually editing scripts, but there's been no progress on a formal fix for this bug that I'm aware of.

chicaneau

@virgiliomi its so strange, everything seems fine for me, all the right values are in the right fields in the UI. in the routing table i have a route to my isp gateway FE80 address and i can ping out to anything from the router itself. it just seems something is blocking my devices from seeing anything. Either firewall or routing... but i dont really know how to be sure which.

I've tried adding firewall rules for allow all on lan ipv6 etc to see if i can get some traffic moving, but nothing happens.

I've just noticed my LAN adapter has no link local address..... perhaps this is part of the non-communication issue?

chicaneau

@chicaneau OMG! i fixed it!!!

So... let me start with a confession. I do have 2 of my LAN ports in a bridge. Which has never ever been a problem before and I figured it was just acting as a regular interface! BUT!!! i found that under the bridge config, there is a tickbox (not sure if its new) called "Enable IPv6 auto linklocal" once i enabled this and "saved, apply changes" on my WAN interface boom. its all working.

To summarise. all i've done is

the 2 line change to /etc/var/interfaces.inc
ticked this ipv6 auto linklocal setting.

I have not added an ipv6 monitoring address at all, it is automatically using the gateway i hardcoded in the interfaces.inc file

To clarify existing config, i am running DHCP6 server = off and RA = unmanaged,
wan type = dhcp6 and ra hint =off and do not wait for ra = off

Thanks everyone on this forum for their input and support. I hope my find can help another lost soul. Cheers

mloiterman

So I spent a huge amount of time on this yesterday and was finally able to get it to route, but it's not entirely clear what fixed it and I still believe that it's broken.

Anyway, I was able to get it to route IPV6 by resaving the gateway I use for IPV6. That kicked it over and it started working.

BUT

I was also able to get it started by resaving the various WAN and LAN interfaces as well as resaving the DHCP6 Server page, as well as changing the Router Advertisements from Stateless to Unmanged and then back to my original setting of Assisted.

A few caveats:

A reboot will cause it to not pull the route again. So then I have to go into all of those settings pages and resave and cross my fingers that something causes it to kick over.
Even when it starts routing correctly, the monitor issue still persists. But, I have worked around that by manually entering the link-local address. But, the gateway in the widget is still listed as "~" even though it says that it's online.

I also tried recreating my ipv6 gateways and gateway groups, but nothing would cause that widget to work automatically. Another point, in my situation, I have made NO changes to the /etc/var/interfaces.inc files which probably explains why this still doesn't work.

For me, as @virgiliomi says, I'm routing with rules, so I don't know if this is really applicable to everyone else.

so thanks to this thread I was able to successfully edit the /etc/inc/interfaces.inc file as described and everything works, but I made a slight change so that it grabs the default gateway from the routing table automatically rather than having to hardcode it into the interfaces.inc file. I did the following:

$my_gw = shell_exec("/usr/bin/netstat -rn6 | grep ^default | awk '{print $2}' | sed 's/%.*//g' | tr -d '\n'");

//$rtsoldscript .= "echo $2 > {$g['tmp_path']}/{$wanif}_defaultgwv6\n";
$rtsoldscript .= "echo $my_gw > {$g['tmp_path']}/{$wanif}_routerv6\n";

//$rtsoldscript .= "echo $2 > {$g['tmp_path']}/{$wanif}_defaultgwv6\n";
$rtsoldscript .= "echo $my_gw > {$g['tmp_path']}/{$wanif}_defaultgwv6\n";

This is working for me and I'm happier with this in case I have to replace my cable modem or something and my ipv6 info changes. Just my 2 cents, hopefully someone finds this useful.

Oops, and just to update my own post here - my default gateway as reported by netstat was fe80::X:X:X:X%igb0. I was intentionally stripping off the interface specification from the default gateway, but this caused the route not to be detected as the default gateway on the system routing page or by dpinger (globe icon was missing). Leaving the interface appended to the ipv6 address seems to work better. So I now have this instead:

$my_gw = shell_exec("/usr/bin/netstat -rn6 | grep ^default | awk '{print $2}' | tr -d '\n'");

//$rtsoldscript .= "echo $2 > {$g['tmp_path']}/{$wanif}_defaultgwv6\n";
$rtsoldscript .= "echo $my_gw > {$g['tmp_path']}/{$wanif}_routerv6\n";

//$rtsoldscript .= "echo $2 > {$g['tmp_path']}/{$wanif}_defaultgwv6\n";
$rtsoldscript .= "echo $my_gw > {$g['tmp_path']}/{$wanif}_defaultgwv6\n";

Everything now seems fully functional

@mintypickle said in IPv6 No Gateway after 2.5 upgrade:

so thanks to this thread I was able to successfully edit the /etc/inc/interfaces.inc file as described and everything works, but I made a slight change so that it grabs the default gateway from the routing table automatically rather than having to hardcode it into the interfaces.inc file. I did the following:
$my_gw = shell_exec("/usr/bin/netstat -rn6 | grep ^default | awk '{print $2}' | sed 's/%.*//g' | tr -d '\n'");

//$rtsoldscript .= "echo $2 > {$g['tmp_path']}/{$wanif}_defaultgwv6\n";
$rtsoldscript .= "echo $my_gw > {$g['tmp_path']}/{$wanif}_routerv6\n";

//$rtsoldscript .= "echo $2 > {$g['tmp_path']}/{$wanif}_defaultgwv6\n";
$rtsoldscript .= "echo $my_gw > {$g['tmp_path']}/{$wanif}_defaultgwv6\n";
This is working for me and I'm happier with this in case I have to replace my cable modem or something and my ipv6 info changes. Just my 2 cents, hopefully someone finds this useful.

g.shaffer

@mintypickle The issue looks like its been fixed in the 2.5.1-RCs.

pLu

Yes, upgrade to the 2.5.1 RC instead.

Spacey

@mintypickle Nice find I'm about to try this, where exactly in the /etc/inc/interfaces.inc file did you add that too? Just anywhere?

g.shaffer

@spacey it was around line 5142, search for "rtsoldscript" to find the right spot. Or you could upgrade to the latest 2.5.1-RC.

@spacey

here's a patch file if you want to apply it, but as g.shaffer said it's around line 5142

interfaces.inc.patch

Spacey

@mintypickle I would upgrade to the 2.5.1 RC instead but I'm a bit weary, on the reddit sub there are quite a few posts about how buggy it is outside of this fix. What are your thoughts on it?

Spacey

~~@mintypickle and how would I apply this patch file? sorry total newb questions~~
Actually figured that out, found the system patches package

@spacey

Should you upgrade to the RC release...I think that's probably one of those questions where if you asked 5 people you'd get 5 different answers. Since the only discernable issue I was having was the ipv6 gateway, and since thanks to this thread I was able to get it to work to my own satisfaction just by editing the interfaces.inc file, I decided against possibly opening other, ickier cans of worms with the release candidate. I know others have updated to 2.5.1-RC with no issues, I just decided not to. I don't have any keener insight than that, sorry!

Spacey

@mintypickle quick question! What do I put for for the Patch Strip Count and Base Directory? I put "/etc/inc/interfaces.inc" there but got an error when saving - "Base Directory must exist and be a directory" any advice?

@spacey

I've never used the patch plugin, I just use the "patch" command from the CLI, either over the console or via SSH, where I would just do the following (assuming you've saved the patch file to /tmp/interfaces.inc.patch. replace with the actual file location as necessary)

cd /etc/inc
cp interfaces.inc interfaces.inc_ORIGINAL
patch -i /tmp/interfaces.inc.patch

then you will hopefully see output like:

[admin@pfsense.home.arpa]/etc/inc: patch -i interfaces.inc.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- interfaces.inc     2021-03-28 09:42:42.575021000 -0500
|+++ interfaces.inc_MOD 2021-03-28 21:47:11.648202000 -0500
--------------------------
Patching file interfaces.inc using Plan A...
Hunk #1 succeeded at 5140.
done

If for some reason you can't use the CLI (or don't want to) and you need to use the GUI plugin - as I mentioned before I've never used it, but I assume that you want to use "/etc/inc" as the base directory. Since I created my patch from within /etc/inc and there are no paths included, I would guess that the path strip count doesn't matter.

Good luck!