Messages

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.

I missed this thread when I started my own. I was having exact same problem as OP originally described. The same php error and the gateway monitor not starting, with a gateway that only has a link-local address. There was also an instance of the gateway on the dashboard, but it was not online. I just updated. The php error is gone, but the gateway monitor is still not starting. Also, the gateway is gone.

If anyone would like info from my system, let me know what you need.

Okay, so much for the last post. I just updated. Now the gateway is missing and the error is gone. Maybe it is the same problem, after all.

Here are some screen captures from my system. I'm not sure this problem is the same problem as others have reported.

Consistently, every time I try to restart the gateway monitor, this error is generated:

[30-Jul-2019 18:34:51 America/Vancouver] PHP Warning:  vsprintf(): Too few arguments in /usr/local/etc/inc/util.inc on line 986