Messages

I've got a blackhole route manually added anyway - it's been there a few years.

WAN on the main router is DHCPv6 (PPPoE)

A bit more info - I just spent a couple of hours trying to reproduce this on a VM with two interfaces, and failed. I then started looking at the clean config on the VM, and my fairly crufty config on the primary router, saving configs as I went along.

I had a stale reservation in Kea for a GUA on the secondary router. Although the secondary router is not now using DHCPv6 for configuration, when I removed the reservation the routing problem went away.

Difference in the configs is:

Code Select Expand

@@ -1561,9 +1561,9 @@
    <column_count>2</column_count>
  </widgets>
  <revision>
-    <username>opnadmin@{prefix48}:49:323e:ff94:6713:d8b5</username>
-    <description>/api/routes/routes/toggleroute/232ecc2c-722f-4390-84ec-285d8bb15f5d made changes</description>
-    <time>1768837329.21</time>
+    <username>opnadmin@{prefix48}:49:27b7:e3d6:48bb:a479</username>
+    <description>/api/kea/dhcpv6/set made changes</description>
+    <time>1769099743.71</time>
  </revision>
  <OPNsense>
    <Firewall>
@@ -2774,7 +2774,7 @@
        </reservations>
        <ha_peers/>
      </dhcp4>
-      <dhcp6 version="1.0.0" persisted_at="1768836386.51" description="Kea DHCPv6 configuration">
+      <dhcp6 version="1.0.0" persisted_at="1769099743.71" description="Kea DHCPv6 configuration">
        <general>
          <enabled>1</enabled>
          <manual_config>0</manual_config>
@@ -2876,14 +2876,6 @@
          </subnet6>
        </subnets>
        <reservations>
-          <reservation uuid="2d620bbf-fe2f-4e43-b186-1a5e3f6f0048">
-            <subnet>7c128662-0440-464c-a14d-844667d1cfa4</subnet>
-            <ip_address>{prefix48}:4f::1fff</ip_address>
-            <duid>00:01:00:01:26:dd:37:1c:52:54:00:68:30:cf</duid>
-            <hostname>router2</hostname>
-            <domain_search/>
-            <description/>
-          </reservation>
          <reservation uuid="39055ba4-31b6-4409-a38b-df0a91fceecb">
            <subnet>d0d43b13-dc16-4c61-9eaf-31417bcbfbe7</subnet>
            <ip_address>{prefix48}:49::a</ip_address>

However, I'm unable now to get the old config to fail. If I reload it, everything seems to be working OK. Either I've made a mistake in my notes, or there's something else going on.

I've tried adding a reservation to my test VM, but that doesn't fail either.

This probably isn't a very useful data point, I'm afraid, as I'm unable to get back to a non-working configuration now.

Thanks both.

I was using PD with ISC dhcpd for this, and it was working (mostly) fine. For what I'm doing there's no advantage in using PD really, so I'd like to get the static routes working.

I'm not keen on messing around with my primary router for this, so I'll try setting up a VM with just my static routes on it and see what happens. There are only 3. If I can reproduce it on that, it should make a fault report easier.

Hi,

I've got a couple of OpnSense routers running 25.7.11_2 linked together.

My primary router receives a static /48 from my ISP, and then delegates a /60 to the secondary router. This is all done with static routing rather than PD, as Kea can't currently add the route for a delegated prefix automatically - see https://forum.opnsense.org/index.php?topic=48680

The interface vtnet3 on the main router has an address of FE80::1/64 and the interface em0 on the secondary router has an address of FE80::2/64.

On the main router, I've got a gateway and a static route configured to reach the secondary router as follows (links to postimg.cc):



The secondary router just has FE80::1 on the main router set as a default gateway.

There's also an IPv4 config set up in  similar way.

This all works fine until I reboot the main router. When it comes up, the route for <prefix48>fff0::/60 to FE80::2%vtnet3 is missing from the routing table until I click the 'Apply' button on the routing config screen on the main router.

IPv4 works perfectly, although this is not using link-local addresses.

Any idea what I'm doing wrong here?

Thanks for the swift reply, and apologies for not checking the Github issues.

I've got two OPNSense routers. One receives a /48 from my ISP, and delegates a /60 to the other.

This has been working on ISC DHCP for a few years. It's a very similar setup in some ways to the one in this topic:-

https://forum.opnsense.org/index.php?topic=48651.0


I've migrated the first router to Kea now, and I've had to add a static route to the second router for the delegated prefix in order for everything to work correctly. There doesn't seem to be an automated addition of the route for the delegated prefix.

I've added a static lease for the second router, and this is outside of the delegated prefix range.

In the topic linked above, you point slowhawkeclipse at the file https://github.com/opnsense/core/blob/master/src/opnsense/scripts/dhcp/prefixes.php. I can't find an equivalent of this for for Kea.

Am I missing something, or is this facility not yet implemented?

Thanks for any info.

Since you've quoted me dfw3xam1n3r, I'll reply as best I can.

On the face of it I can't see a reason for this to be related, but I'm just a random software developer off the internet. This is my first PR for opnsense. I'm best described as an enthusiastic user of opnsense, so my product knowledge level is at best patchy. For example, I don't know how the dataflows for the 'track interface' feature are implemented.

That's the disclaimer. However, you can investigate this yourself as follows, if you're on 24.1.9:-
1) Restart the WAN connection
2) Get up a terminal and investigate the WAN connection with ifconfig -L pppoe0 (assuming you're on PPPoE).

You should see your IPv6 GUA there. After the text vltime there will be a value. This is the number of seconds remaining before your GUA disappears. Your ISP will still believe your GUA is active, as it will be getting regular RENEW requests from you.

When your GUA does disappear, a range of things can happen from 'hardly anything' to 'no IPv6'. This is ISP-dependent to a large extent. However, you have a precise time when this happens, and so with a bit of detective work you should be able to figure out if there is a dependency between events on your network and the GUA disappearing.

BTW, I believe a release which addresses this issue is imminent so this may be moot.

I've tracked down what is happening on my simple setup (address only, no prefix) and created a PR for discussion:-

https://github.com/opnsense/dhcp6c/pull/36

Attached is my packet capture from 24.1.9

As I write this, system uptime is 2:56, and it's 17:56 BST here. So the capture started at around 15:00 BST. This isn't an exact time. I note 'who -b' doesn't seem to work on my system.

I ran a IPv6 ping test of my WAN address in parallel at a rate of one a minute. The ping test dropped out at 17:03 BST approx.

The initial lease from 15:00 BST (approx.) has a valid lifetime of 7200 secs (packet 6). A renew request is made at 16:00 BST and answered (packets 10 and 11), and another one is made at 17:00 BST (packets 12 and 13). Round about this point the IP address is dropped.

So it looks to me as though the DHCP REPLY packets are not being acted on, or when they are received the valid lifetime is not being updated.

I really hope this is of use. I'm happy to reproduce this if required to get more information, (e.g. logging), or to try something else, but I'll wait to be guided by someone who knows more about this than I do! I'm going to roll back to 24.1.8 here for now.

Packet capture from DHCPv6 over 4 hours on 24.1.8 following SIGHUP to dhcp6c

There are a few RELEASE messages (packets 1, 5, 7, 8, 9) with an XID of 0x3f4706 which I think are related to the initial HUP I sent dhcp6c. Other than that, it's pretty much as expected.

I've installed 24.1.9 and rebooted. /var/etc/dhcp6c.conf is identical. I've restarted the capture. Currently I have a pingable WAN address.

I'm having the same problem with my UK ISP, Andrews and Arnold (A&A).

Because A&A provide static routing I'm not requesting a prefix at all - just a non-temporary address, and options 23 and 24.

I've got a virtualized router, so I've rolled back to 24.1.8 for now.

/var/etc/dhcp6c.conf looks like this:-

Code Select Expand

interface pppoe0 {
  send ia-na 0; # request stateful address
  request domain-name-servers;
  request domain-name;
  script "/var/etc/dhcp6c_wan_script.sh"; # we'd like some nameservers please
};
id-assoc na 0 { };


I'm running this command on the console to capture the DHCP negotiations:-

tcpdump -w dhcp.pcap -i pppoe0 udp portrange 546-547

I've also sent a HUP to dhcp6c to release and re-request the address.

Tomorrow I'll repeat the exercise on 24.1.9 and look for obvious changes.

I'm not looking at logging yet, but I thought a report of what's going on on-the-wire might be useful.

I'm using Zen. Unlike your config I've got the WAN set up for DHCP (rather than going fully static). I've upgraded this system a couple of times, so when I set it up I was using the old instructions.

In my case, the gateway appears under System/Gateways/Single. Are you able to set up your static gateway under there?