Messages

That's perfectly normal.


Under the original pfSense, and this is where Opnsense was forked from so it suffered from the same problem, with certain ISPs you needed to send a dhcp6 solicit before router advertisements or should I says you had to send both independently. Now, the problem was that pfSense would wait for a advertisement response before it launched dhcp6c, thus no advertisement response, no dhcp6c. Now, my original fix on pfSense was to to give the option to launch dhcpc6 regardless of the state of the advertisements, but the option was also added to turn that on and off.


Franco and co did some research and found that it causes no issues with ISPs that don't require it and works fine with those that do - so now the option to disable it has been removed and you could say it's permanently on, in fact they both run pretty much simultaneously.

Understood. OPNsense is receiving RA messages, so I'm not clear why the gateway status on the dashboard reports the address as ~ rather than the actual address.

I used wireshark to capture DHCPv6 and ICMPv6 messages.

When OPNsense starts, the following sequence of messages are exchanged:

send ICMPv6 router solicitation
send DHCPv6 solicit
receive DHCPv6 advertise
receive ICMPv6 router advertisement
send DHCPv6 request
receive DHCPv6 reply

After that, the link is up and the gateway periodically sends router advertisement messages, at random intervals usually not longer than 30 minutes. The router advertisements come from the gateway always using the same link-local address which is used in the default route.

Later on,

Send DHCPv6 renew
Receive DHCPv6 reply

The router advertisements continued after the renew / reply.

A few comments / questions.

In Lobby / Dashboard / Gateways, WAN_DHCP6 shows statistics and status, but the address is ~, rather than the (link-local) address of the gateway.

In Interfaces / Overview / WAN, it shows the link-local address of the IPv6 gateway.

You'll find the dhcp6c debug and no-release options are now in interfaces->settings.

Would it be helpful for me to enable debug logging and post the log?

Do this, from the shell.


# cd /usr
# git clone https://github.com/opnsense/dhcp6c.git
# cd dhcp6c
# ./configure
# make
# killall -TERM dhcp6c
# make install


Now reboot.

Done and it's working.

Directly send solicit does not exist anymore, and hasn't since 20.1.1 or even earlier.

I didn't notice that. I guess that's the result of upgrading in place and not paying attention until something doesn't work.

You might need the new dhcp6c, in fact I'm pretty sure you will, so do a ps -auxw | grep dhcp6c and see if it's running.

dhcp6c isn't running, as you suspected.

Can you grab your dhcpd6.conf and post the contents, obfuscate any GUAs, same goes for dhcp6c.conf, post the contents.

Thank you for your reply.

dhcpd6.conf

Code Select Expand

# Server configuration file example for DHCPv6
# From the file used for TAHI tests - addresses chosen
# to match TAHI rather than example block.

# IPv6 address valid lifetime
#  (at the end the address is no longer usable by the client)
#  (set to 30 days, the usual IPv6 default)
default-lease-time 2592000;

# IPv6 address preferred lifetime
#  (at the end the address is deprecated, i.e., the client should use
#   other addresses for new connections)
#  (set to 7 days, the usual IPv6 default)
preferred-lifetime 604800;

# T1, the delay before Renew
#  (default is 1/2 preferred lifetime)
#  (set to 1 hour)
option dhcp-renewal-time 3600;

# T2, the delay before Rebind (if Renews failed)
#  (default is 3/4 preferred lifetime)
#  (set to 2 hours)
option dhcp-rebinding-time 7200;

# Enable RFC 5007 support (same than for DHCPv4)
allow leasequery;

# Global definitions for name server address(es) and domain search list
option dhcp6.name-servers 3ffe:501:ffff:100:200:ff:fe00:3f3e;
option dhcp6.domain-search "test.example.com","example.com";

# Set preference to 255 (maximum) in order to avoid waiting for
# additional servers when there is only one
##option dhcp6.preference 255;

# Server side command to enable rapid-commit (2 packet exchange)
##option dhcp6.rapid-commit;

# The delay before information-request refresh
#  (minimum is 10 minutes, maximum one day, default is to not refresh)
#  (set to 6 hours)
option dhcp6.info-refresh-time 21600;

# The path of the lease file
dhcpv6-lease-file-name "/var/db/dhcpd6.leases";

# Static definition (must be global)
host myclient {
# The entry is looked up by this
host-identifier option
dhcp6.client-id 00:01:00:01:00:04:93:e0:00:00:00:00:a2:a2;

# A fixed address
fixed-address6 3ffe:501:ffff:100::1234;

# A fixed prefix
fixed-prefix6 3ffe:501:ffff:101::/64;

# Override of the global definitions,
# works only when a resource (address or prefix) is assigned
option dhcp6.name-servers 3ffe:501:ffff:100:200:ff:fe00:4f4e;

# For debug (to see when the entry statements are executed)
#  (log "sol" when a matching Solicitation is received)
##if packet(0,1) = 1 { log(debug,"sol"); }
}

host otherclient {
        # This host entry is hopefully matched if the client supplies a DUID-LL
        # or DUID-LLT containing this MAC address.
        hardware ethernet 01:00:80:a2:55:67;

        fixed-address6 3ffe:501:ffff:100::4321;
}

# The subnet where the server is attached
#  (i.e., the server has an address in this subnet)
subnet6 3ffe:501:ffff:100::/64 {
# Two addresses available to clients
#  (the third client should get NoAddrsAvail)
range6 3ffe:501:ffff:100::10 3ffe:501:ffff:100::11;

# Use the whole /64 prefix for temporary addresses
#  (i.e., direct application of RFC 4941)
range6 3ffe:501:ffff:100:: temporary;

# Some /64 prefixes available for Prefix Delegation (RFC 3633)
prefix6 3ffe:501:ffff:100:: 3ffe:501:ffff:111:: /64;
}

# A second subnet behind a relay agent
subnet6 3ffe:501:ffff:101::/64 {
range6 3ffe:501:ffff:101::10 3ffe:501:ffff:101::11;

# Override of the global definitions,
# works only when a resource (address or prefix) is assigned
option dhcp6.name-servers 3ffe:501:ffff:101:200:ff:fe00:3f3e;

}

# A third subnet behind a relay agent chain
subnet6 3ffe:501:ffff:102::/64 {
range6 3ffe:501:ffff:102::10 3ffe:501:ffff:102::11;
}


dhcp6c.conf

Code Select Expand

interface hn0 {
  send ia-pd 0; # request prefix delegation
  request domain-name-servers;
  request domain-name;
  script "/var/etc/dhcp6c_wan_script.sh"; # we'd like some nameservers please
};
id-assoc pd 0 {
  prefix-interface hn1 {
    sla-id 0;
    sla-len 8;
  };
};


I started up another VM running the latest development version:

OPNsense 20.7.b_97-amd64
FreeBSD 11.2-RELEASE-p19-HBSD
OpenSSL 1.1.1g 21 Apr 2020

It's working properly, but it also doesn't have the Directly send SOLICIT setting.

I started up another VM running the latest release version:

OPNsense 20.1.6-amd64
FreeBSD 11.2-RELEASE-p19-HBSD
OpenSSL 1.1.1g 21 Apr 2020

It's also working properly, but it also doesn't have the Directly send SOLICIT setting.

This is strange. Perhaps the setting disappeared from the GUI, but it's still in the configuration?

I updated my test system and after it restarted, dhcpd6 was not running and would not start. It was a while since I last updated it, so I bootstrapped to a previous version which does not have the problem, then updated to see if the problem returned.

After bootstrapping, here is the version:

OPNsense 20.1.6-amd64
FreeBSD 11.2-RELEASE-p19-HBSD
OpenSSL 1.1.1g 21 Apr 2020

This version works properly.

After updating from the GUI, here is the version:

OPNsense 20.7.b_97-amd64
FreeBSD 11.2-RELEASE-p19-HBSD
OpenSSL 1.1.1g 21 Apr 2020

This version works properly.

After updating from the command line (opnsense-update, opnsense-code core, make upgrade), here is the version:

OPNsense 20.7.b_156-amd64
FreeBSD 11.2-RELEASE-p19-HBSD
OpenSSL 1.1.1g 21 Apr 2020

With this version, dhcpd6 will not start and the Windows 10 client cannot get an IPv6 address.

The only related message in the log is this:

Code Select Expand

opnsense-devel: /usr/local/etc/rc.bootup: Warning! dhcpd_dhcp6_configure() found no suitable IPv6 address on lan

My ISP requires the use of the "Directly send SOLICIT" setting, which appears to be missing.

Thanks for the replies. I tried bootstrapping and it did the trick. After resetting to 20.1, I updated using the development release type and the version is OPNsense 20.1.r_12-amd64. I really appreciate the suggestion.

I have an OPNsense installation running with release type development. The version is OPNsense 20.1.r_6-amd64.

If I check for updates, two choices are offered. The first choice consists of 32 updates, including downgrading the base from 20.1 to 19.7, upgrading some packages, reinstalling some packages and removing some packages, including opnsense-devel. The other choice is to unlock 20.1.r1.

If I select the first choice, this message appears in the log

Code Select Expand

***GOT REQUEST TO UPGRADE: all***
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Checking for upgrades (29 candidates): .......... done
Processing candidates (29 candidates): .......... done
Checking integrity... done (1 conflicting)
  - openssl102-1.0.2u conflicts with openssl-1.1.1d,1 on /usr/local/bin/c_rehash
Cannot solve problem using SAT solver, trying another plan
Checking integrity... done (0 conflicting)
The following 30 package(s) will be affected (of 0 checked):

Installed packages to be REMOVED:
opnsense-update-20.1
opnsense-devel-20.1.r_6
openssl-1.1.1d,1

New packages to be INSTALLED:
openssl102: 1.0.2u

Installed packages to be UPGRADED:
py37-urllib3: 1.25.6,1 -> 1.25.7,1
py37-setuptools: 41.4.0_1 -> 44.0.0
liblz4: 1.9.2,1 -> 1.9.2_1,1
isc-dhcp44-server: 4.4.1_4 -> 4.4.2
isc-dhcp44-relay: 4.4.1 -> 4.4.2

Installed packages to be REINSTALLED:
wpa_supplicant-2.9 (options changed)
unbound-1.9.6 (direct dependency changed: openssl102)
syslog-ng325-3.25.1 (direct dependency changed: openssl102)
strongswan-5.8.2_1 (direct dependency changed: openssl102)
squid-4.9 (direct dependency changed: krb5)
python37-3.7.6 (direct dependency changed: openssl102)
py37-cryptography-2.6.1 (direct dependency changed: openssl102)
php72-openssl-7.2.26 (direct dependency changed: openssl102)
openvpn-2.4.8 (direct dependency changed: openssl102)
openssh-portable-8.1.p1,1 (direct dependency changed: openssl102)
openldap-sasl-client-2.4.48 (direct dependency changed: cyrus-sasl)
ntp-4.2.8p13_6 (direct dependency changed: openssl102)
mpd5-5.8_10 (direct dependency changed: openssl102)
monit-5.26.0 (direct dependency changed: openssl102)
lighttpd-1.4.54 (direct dependency changed: openssl102)
libevent-2.1.11 (direct dependency changed: openssl102)
ldns-1.7.1_1 (direct dependency changed: openssl102)
krb5-1.17.1 (direct dependency changed: openssl102)
hostapd-2.9 (direct dependency changed: openssl102)
cyrus-sasl-2.1.27_1 (direct dependency changed: openssl102)
curl-7.68.0 (direct dependency changed: ca_root_nss)

Number of packages to be removed: 3
Number of packages to be installed: 1
Number of packages to be upgraded: 5
Number of packages to be reinstalled: 21

The operation will free 22 MiB.
pkg-static: Cannot delete vital package: opnsense-devel!
pkg-static: If you are sure you want to remove opnsense-devel,
pkg-static: unset the 'vital' flag with: pkg set -v 0 opnsense-devel
Starting web GUI...done.
Generating RRD graphs...done.
***DONE***

Note the end where it says the following:

pkg-static: Cannot delete vital package: opnsense-devel!
pkg-static: If you are sure you want to remove opnsense-devel,
pkg-static: unset the 'vital' flag with: pkg set -v 0 opnsense-devel

Is this expected behaviour or does my system have a problem?

IMO, prefix delegation is not for the WAN, but for the LAN. If you want an address for the WAN, it's part of the request for the prefix (i.e., address and prefix). Unless the ISP allocates an address for the WAN, there is no need for one. Even if the ISP allocates an address for the WAN, I'm not clear why it would be required for a subscriber-supplied device. If anyone can explain what a WAN address would be used for on OPNsense, I'd like to hear it.

Why do think that you need a WAN IP address? My ISP gives a /56. My routers (I have three) are set to track their respective prefix. None of them have a WAN IP address.

Just so this doesn't get left behind, I reinstalled OPNsense from scratch on my windows server 2019 hyper-v and I experienced the same freezing as in the previous version. The first time was at the point of selecting guided setup. At this point, I interrupted using CTRL-C and logged in again as installer. It happened once or twice again further on. I'm using a generation 2 vm with secure boot disabled. The settings are default.

If you would like me to test anything, let me know.