core: [6rd][stf] default route not setup automatically

Our policy is clear and simple (and won’t change), without an owner, issues time-out. It is absolutely useless to keep issues open if nobody bothers to work on them, even with a PR involved it won’t guarantee the (core) team will spend time on an item, the software is free to use for everyone, peoples (limited) time obviously isn’t.

For long standing discussions, best use our forum, which is available on https://forum.opnsense.org/

I agree. Just because the devs haven’t been involved doesn’t mean the community isn’t here documenting the issue. Some of us would even be happy to put in a PR, but haven’t because the devs haven’t recognized the issue and made the necessary direction clear.

Let’s be real. The one with a 6RD setup who can maintain it by adding real fixes to the code base will likely be the designated maintainer. I don’t know anyone who has or will step up to this in the years we had brought 6RD back instead of letting it die completely. Assuming anyone is blocking free will in voluntary contributors mischaracterises the open source situation we are in here rather bluntly.

If it’s your setup you fix it, you don’t play the blame game against others and in the same sweep demotivate someone else from stepping in. Complaining never improved the situation, but to some it seems so because all they do is complain and someone fixes it for other reasons. This is called confirmation bias and it is bad for community interactions.

This ticket remains open until the next timeout period comes along in a couple of months. I expect a maintainer and a patch or at least less attitude towards a potential maintainer for “having not fixed this when someone else clearly asked for it”.

Cheers, Franco

Can we please NOT auto-close issues like this? That just pushes it out-of-sight, out-of-mind. This is a serious issue effecting a vast number of IPv6 users on OPNsense. Also, there has been considerable activity on this particular topic, the comments are full of people diving into the issue, finding temporary workarounds, and providing data input.

If someone analyses the issue and comes up with a PR I’m certainly willing to take a look and see if/how we can progress this into a workable solution for everyone. We don’t have active plans removing 6rd (at the short term), but we don’t have any plans debugging this either.

@AdSchellevis - I’ll play with this, sounds similar the default route issue experienced I played with earlier. Do you want me to re-open with a new issue? I’d rather keep this one as it has some debugging information in it which I’ve already used to narrow down the possible problem.

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository, please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue, just let us know, so we can reopen the issue and assign an owner to it.

Just wanted to say that I’m having the same issue. Running route add -inet6 default -interface wan_stf fixes it.

“If it’s your setup you fix it” <<< That’s EXACTLY what we’ve been trying to do, with a growing number of eyes trying to help diagnose it. But by closing the ticket, you’re preventing more eyes from joining, and disenfranchising the eyes already working on it.

“don’t play the blame game against others and in the same sweep demotivate someone else from stepping in” <<< isn’t this EXACTLY what you’re doing by not only closing this ticket out, but after re-opening it, giving us, the community, a deadline to solve it ourselves without even any sort of basic guidance?

I’ll put up my offer here as well that I put up on Twitter. I can stand up an instance of OPNsense that I’m willing to give access to the core OPNsense dev team. I have a block of IPv4 addresses, some currently unused, that all have 6RD access. I’ve confirmed above that adding the static route is a temporary work-around, but this leaves inconsistencies with the Web UI, and doesn’t persist reboots without adding a script to handle it.

If you check the entire thread here, we’ve nailed down the approximate time in the codebase that the change was made. We have a fairly clear idea on what core FreeBSD networking calls are missing. For someone that has deeper knowledge into the OPNsense stack, this shouldn’t be that complicated of an issue to solve, there just needs to be proper registration of the IPv6 default gateway, that was lost sometime between 19.1 and 20.1 (so prior to the move to HardenedBSD 12)

I agree. Just because the devs haven’t been involved doesn’t mean the community isn’t here documenting the issue. Some of us would even be happy to put in a PR, but haven’t because the devs haven’t recognized the issue and made the necessary direction clear.

Just wanted to say that I’m having the same issue. Running route add -inet6 default -interface wan_stf fixes it.

Same here. Centurylink Fiber Seattle, Wa. Trying for hours and finally this one line fixed everything. 20.1.6 – fresh install.

If anyone finds this and is lost, this tutorial solved most of the riddles: https://bidetly.io/2020/03/20/centurylink-fiber-on-pfsense/

After that and the router command in a shell, devices are getting an ipv6. System:Gateways:Single still doesn’t show any address for ipv6.

I’m having the same issue, here’s a little more detail from my end:

Describe the bug Tested in 20.1 and 20.1.1 - 6RD on WAN interface doesn’t work when configured through web UI. It appears that the interface wan_stf is created by checking the shell, but the default IPv6 route is not installed by default and the WAN IPv6 address/interface is not visible in the WebUI.

To Reproduce Steps to reproduce the behavior:

1. Configure WAN interface for 6RD 1.1 WAN Interface set to 6RD 1.2 6RD settings for CenturyLink
2. Apply settings
3. Log into CLI via SSH
4. Enter Shell
5. Enter ifconfig to check interface presence for wan_stf

pppoe0: flags=89d1<UP,POINTOPOINT,RUNNING,NOARP,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1492
        inet6 fe80::210:18ff:fe78:1534%pppoe0 prefixlen 64 scopeid 0xd
        inet 97.118.72.211 --> 207.225.112.1 netmask 0xffffffff
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
wan_stf: flags=4041<UP,RUNNING,LINK2> metric 0 mtu 1280
        inet6 2602:61:7648:d300:: prefixlen 56
        nd6 options=1<PERFORMNUD>
        v4net 97.118.72.211/0 -> tv4br 205.171.2.64
        groups: stf

1. Try to ping an external host from the firewall

[david@router ~]$ ping6 google.com
ping6: UDP connect: No route to host

1. Check routing table using netstat -rn and Internet6: section lacks default entry

Internet6:
Destination                       Gateway                       Flags     Netif Expire
::1                               link#5                        UH          lo0
2602:61:7648:d300::               link#14                       UHS         lo0
2602:61:7648:d300::/56            link#14                       U       wan_stf
fe80::%bce1/64                    link#2                        U          bce1
fe80::210:18ff:fe78:1536%bce1     link#2                        UHS         lo0
...

1. Add default ipv6 interface

root@router:/home/david # route add -inet6 default -interface wan_stf
add net default: gateway wan_stf

1. Use netstat -rn to confim presence of default Internet6 route

Internet6:
Destination                       Gateway                       Flags     Netif Expire
default                           wan_stf                       US      wan_stf
::1                               link#5                        UH          lo0
2602:61:7648:d300::               link#14                       UHS         lo0
2602:61:7648:d300::/56            link#14                       U       wan_stf
fe80::%bce1/64                    link#2                        U          bce1
...

1. Ping google again

root@router:/home/david # ping6 google.com
PING6(56=40+8+8 bytes) 2602:61:7648:d300:: --> 2607:f8b0:400f:800::200e
16 bytes from 2607:f8b0:400f:800::200e, icmp_seq=0 hlim=57 time=2.208 ms
16 bytes from 2607:f8b0:400f:800::200e, icmp_seq=1 hlim=57 time=3.124 ms
^C
--- google.com ping6 statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 2.208/2.666/3.124/0.458 ms

1. Go back to Web UI 14.1 wan_stf is not an interface in UI 14.2 WAN 6RD address is not listed until WAN interface 14.3 6RD gateway does not accurately show up in dashboard widget

Expected behavior Configure 6RD via WAN interface, and have the interface created, linked, default route installed, and appears on web UI automatically without terminal intervention.

Environment

OPNsense 20.1.1-amd64FreeBSD 11.2-RELEASE-p16-HBSD OpenSSL 1.1.1d 10 Sep 2019 Dell R210 ii