Hi
I have the following issues with the IPv6 implementation in Opnsense (15.7.23-amd64):
DHCPv6After a reboot it doesn't ask the providers DHCPv6 server for a prefix delegation, therefore my provider (Init7) doesn't route my static IPv6 /48 range to my box. Manually invoking
/var/etc/rtsold_[...].sh fixes this until next reboot.
The issue https://github.com/opnsense/core/issues/47 (https://github.com/opnsense/core/issues/47) and post https://forum.opnsense.org/index.php?topic=1533.0 (https://forum.opnsense.org/index.php?topic=1533.0) seem related.
Null-RouteBecause I have a /48 range and don't use every possible /64 subnet from it, there is a routing loop between my box and the ISP.
I can create a null route for my IPv6 /48 subnet, but it doesn't get applied.
How to reproduce:
- System/Routes/All: Create a route for 2001:1111:1111::/48 to Null6 - ::1
- Check System/Routes/Status - no route for 2001:1111:1111::/48 is visible there
Also a traceroute to this destination shows that the default route will be used. In the routing log only this message is visible:
Quoteradvd[73122]: sendmsg: Permission denied
In my opinion opnsense should automatically create a null-route for a received PD with a subnet with less than 64 bits, or at least provide an option for this.
Hi Marcel,
Thank you for your detailed reports, I have added them to the bug tracker, so one of the devs can pick it up from there. I will try to look into these as well, but it'll probably take us to 16.1.x before we get those fixed.
https://github.com/opnsense/core/issues/637
https://github.com/opnsense/core/issues/638
Will report back soon. Any new findings here are welcome.
Cheers,
Franco
Hi Franco
Thank you for creating the bug requests, I wasn't sure if I should open them directly or ask the forum first.
Regarding the null route issue, I found out that after applying the route it won't get applied to the system at all.
1. route -n monitor
2. reconfigure IPv6 null routes, apply.
Only IPv4 route changes are visible.
Manually setting the route with route add -inet6 -net 2001:1111:1111::/48 -iface lo0 -blackhole works, it will also show in netstat -nr
It now seems that opnsense now has a loop in itself. Why do I see the second reply, it should have been already dropped.
C:\>tracert -d 2001:1111:1111::1
Tracing route to 2001:1111:1111::1 over a maximum of 30 hops
1 2 ms 1 ms 3 ms xxx::1
2 1 ms 3 ms 1 ms xxx::1
3 2 ms 8 ms 3 ms xxx::1
[...]
Hi Franco
Quote from: franco on January 10, 2016, 07:51:15 PM
[...]https://github.com/opnsense/core/issues/637[...]
I saw that the issue about DHCPv6-PD is now closed on Github. Does this mean it won't be fixed?
Thanks,
Marcel
Hi Marcel,
I've reopened it. I checked this thread prior to closing, saw it was related to 15.7.x and hoped that this was fixed.
Apparently not, sorry. :(
Is there anything new you can share with us about the issue?
Cheers,
Franco
Hi Franco
Unfortunately no. I still have to enter /var/etc/rtsold_interface_vlan_script.sh after every reboot. Currently I'm on 16.1.12.
The null route still doesn't get applied.
Maybe the thread should be moved to the 16.1 subforum.
Agreed, moving the topic.
As a workaround you can trigger an automatic script after reboot by creating a file e.g. /usr/local/etc/rc.syshook.d/rtsoldfix.start and adding:
#!/bin/sh
/var/etc/rtsold_interface_vlan_script.sh
Then set it executabe:
# chmod 700 /usr/local/etc/rc.syshook.d/rtsoldfix.start
The system will execute it automatically after network was set up. Firmware updates will not remove this.
Hi Franco
Thank you for the syshook fix. I also used the fix for the null-route issue.
Now null traffic loops on the system itself, but at least not to the ISP. It looks like this old FreeBSD bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=139145 (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=139145)
Also I tried to understand how static routes are added, it seems that they are created with
system_staticroutes_configure (which is called after pressing the apply button in system_routes.php, which calls system_routes_configure which calls system_staticroutes_configure).
I added logging code to mwexec to see if route add actually gets executed, it doesn't. Only the deletion works.
QuoteMay 1 18:30:09 xxx opnsense: /system_routes.php: The command '/sbin/route delete -inet6 '2001:1111:1111::/64'' returned exit code '1', the output was 'route: writing to routing socket: No such process delete net 2001:1111:1111::/64 fib 0: not in table'
This command gets executed before pressing the apply button, this seems like a bug too.
Do you know how to debug the php-function properly? I saw xdebug, but maybe there is a better way.
Regards,
Marcel
Hi Marcel,
Null routes will be fixed in 16.1.14-devel and 16.1.15 release respectively. We can surely talk about adding them automatically as soon as we find the other glitch... looking into rtsold now, although this is pretty weird to say what's wrong without having the setup available. Sorry for the delay.
Cheers,
Franco
Hi Franco
Thank you for fixing the route issue, I will test it as soon the new release gets released.
If you more details about my configuration / set-up I can send it to you. I could also try to replicate the issue with VMs (one as DHCPv6 and one as OpnSense).
Thank you again
Marcel
Hi Marcel,
I still have the suspicion that rtsold is not correctly triggered on boot because the system sees it's booting up and isn't allowed to run the script.
Maybe we should try to defer the startup of rtsold to see if that makes things better... let me look at the code and suggest a small patch to try out.
Cheers,
Franco
Er, could this be your issue?
https://redmine.pfsense.org/issues/5993
TL;DR: RA never sent, thus dhcp6c not executed
At least now I get RAs every 3 minutes. I could remove the helper script and to check on next boot if it sends RAs before the dhcpv6 request.
Hi Franco
Quote from: franco on May 15, 2016, 11:48:02 PM
Null routes will be fixed in 16.1.14-devel and 16.1.15 release respectively.
I tested it today with 16.1.15, but it doesn't add the null route.
Regards,
Marcel
Hi Marcel,
Merge target moved up as we had another improvement in that code area that needed further testing. The change is not in 16.1.15 therefore. Sorry about this.
Cheers,
Franco
Hi
With 16.1.17 the null route fix works. In the meantime I also tried to use the track-interface IPv6 configuration. This works but rtsold still has to be called manually.
Regards
Marcel
Hi Marcel,
There's a DHCP debug mode option in the WAN interface dhcp advanced config since one or two version. If you could switch that on and apply the following patch it would help to bring the rtsold log messages to light:
# opnsense-patch 2e5ab31
The messages will be in the tab System: Routes: Log File after reboot.
On the other hand, we could just add another advanced override that skips rtsold, but not before knowing why it's not going anywhere.
Cheers,
Franco
Hi Marcel,
Code went into what will be 16.7 to enable skipping rtsold completely. The fix may require further tweaking, but I think this is the only way to go forward.
https://github.com/opnsense/core/commit/e2998ac4cf2179ad78bf536c086c73da6efb9323
Cheers,
Franco