OPNsense Forum

Archive => 17.1 Legacy Series => Topic started by: baer on February 12, 2017, 02:48:22 am

Title: IPv6 prefix delegation - "unsupported authentication protocol"
Post by: baer on February 12, 2017, 02:48:22 am
tl;wr: I am trying to get prefix delegation to work. Virtual machine with OPNsense behind a LEDE (OpenWRT) router hits the error "unsupported authentication protocol" and never successfully configures the received prefix.

tl;wr 2: Looks like the 'reconfigure' authentication protocol is not implemented in dhcp6c?



I recently found out that I can receive more than just a /64 prefix from my ISP. After setting a more preferable /56 request size, changing the MAC and rebooting both router and modem I now successfully get an IPv6 prefix of desired size. The router which receives that prefix is running on LEDE firmware and then distributes that in my home network via stateless + stateful mechanisms. I.e. I assigned a /60 subnet to my LAN interface together with an assignment hint and the router runs odhcpd as a DHCPv6 server.

(http://i.imgur.com/iNOs0wQ.png)

Now I wanted to put my virtual machines into another seperate subnet and decided to use OPNsense for that. The host machine runs ESXi 6.5 and the virtual machine gets two interfaces: one in the home LAN, where the LEDE router is the DHCP server, and a second one in another VLAN, for which this machine shall be the server.

After configuring the larger subnet on the router, I checked if prefix delegation in general works by running ISC's dhclient on my machine. (It's a laptop running Arch Linux, in case that matters.)

Code: [Select]
• baer @thinkmett ~ $ sudo dhclient -6 -d -P wireless
[sudo] password for baer:
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on Socket/wireless
Sending on   Socket/wireless
PRC: Soliciting for leases (INIT).
XMT: Forming Solicit, 0 ms elapsed.
XMT:  X-- IA_PD 18:d1:f9:d9
XMT:  | X-- Request renew in  +3600
XMT:  | X-- Request rebind in +5400
XMT: Solicit on wireless, interval 1060ms.
RCV: Advertise message on wireless from fe80::a62b:b0ff:fecd:f649.
RCV:  X-- IA_PD 18:d1:f9:d9
RCV:  | X-- starts 1486860071
RCV:  | X-- t1 - renew  +1101
RCV:  | X-- t2 - rebind +1761
RCV:  | X-- [Options]
RCV:  | | X-- IAPREFIX 2axx:xxxx:xxxx:74f8::/62
RCV:  | | | X-- Preferred lifetime 2202.
RCV:  | | | X-- Max lifetime 4902.
RCV:  X-- Server ID: 00:03:00:01:a4:2b:b0:cd:f6:49
RCV:  Advertisement recorded.
PRC: Selecting best advertised lease.
PRC: Considering best lease.
PRC:  X-- Initial candidate 00:03:00:01:a4:2b:b0:cd:f6:49 (s: 10104, p: 0).
XMT: Forming Request, 0 ms elapsed.
XMT:  X-- IA_PD 18:d1:f9:d9
XMT:  | X-- Requested renew  +3600
XMT:  | X-- Requested rebind +5400
XMT:  | | X-- IAPREFIX 2axx:xxxx:xxxx:74f8::/62
XMT:  | | | X-- Preferred lifetime +7200
XMT:  | | | X-- Max lifetime +7500
XMT:  V IA_PD appended.
XMT: Request on wireless, interval 1000ms.
RCV: Reply message on wireless from fe80::a62b:b0ff:fecd:f649.
RCV:  X-- IA_PD 18:d1:f9:d9
RCV:  | X-- starts 1486860072
RCV:  | X-- t1 - renew  +1100
RCV:  | X-- t2 - rebind +1760
RCV:  | X-- [Options]
RCV:  | | X-- IAPREFIX 2axx:xxxx:xxxx:74f8::/62
RCV:  | | | X-- Preferred lifetime 2200.
RCV:  | | | X-- Max lifetime 4900.
RCV:  X-- Server ID: 00:03:00:01:a4:2b:b0:cd:f6:49
PRC: Bound to lease 00:03:00:01:a4:2b:b0:cd:f6:49.
PRC: Renewal event scheduled in 1100 seconds, to run for 660 seconds.
PRC: Depreference scheduled in 2200 seconds.
PRC: Expiration scheduled in 4900 seconds.

So that seems to work and it shows up on the router's GUI as a DHCPv6 lease. Now for the OPNsense machine. I am using the latest release with OpenSSL I think? I've tried it with LibreSSL, too. That didn't help much and I don't think it's relevant to the problem at hand anyway:

Code: [Select]
OPNsense 17.1-amd64
FreeBSD 11.0-RELEASE-p7
OpenSSL 1.0.2k 26 Jan 2017

I've set the 'IPv6 Configuration Type' of the WAN interface (home network) as DHCPv6 and left the options below mostly at thir defaults. In Basic mode I've entered a preferred Prefix Delegation size of 60 and ticked 'Send IPv6 prefix hint'. I've tried experimenting with these options but couldn't get it to work with any combination so far. Following is an excerpt from the DHCP log from what I think is one entire delegation request. I've somehow managed to have debug logging enabled, despite using the Basic mode in configuration ...

(http://i.imgur.com/6gd2lGP.png)

I believe the 'culprit' is the unsupported authentication protocol, which gets 'thrown' here (https://github.com/jinmei/wide-dhcpv6/blob/master/common.c#L1702).
(edit: wrong file, and use bbcode)

Reading the RFC 3315 (https://tools.ietf.org/html/rfc3315), the logged protocol 'reconfiguration' should have the number three (as seen in chapter 21.5 (https://tools.ietf.org/html/rfc3315#section-21.5) of said RFC) and a protocol 1 does not even appear to exist? To be honest I haven't looked at the sources of odhcpd yet. But what might be the matter here?

Is there, alternatively, an easy way to switch the DHCPv6 client to ISC's dhclient on OPNsense? It's present under /usr/local/sbin/dhclient and it behaves similarly to my own machine in that it seems to successfully receive a delegated prefix ...

Edit: the (probably) relevant odhcpd code (http://lxr.mein.io/source/odhcpd/src/dhcpv6.c#L173). I'm trying to read it but I'm not sure what is going on yet and I don't see any hints of an authentication protocol so far ..

I'd be thankful for any leads ..



I quickly verified that a second LEDE instance as a virtual machine correctly configures a received prefix.



So what confuses me, is that the debug printout clearly shows a protocol 'reconfigure' but it then fails because of a protocol '1' ...
Code: [Select]
dhcp6c[68129]: proto: reconfig, alg: HMAC-MD5, RDM: mono counter, RD: ...
Debug printing happens in sprint_auth and the switch on optinfo->authproto clearly matches the enum value DHCP6_AUTHPROTO_RECONFIG, i.e. authproto is '3' at that point.

The switch in dhcp6_get_options right after that hits the default case though. The DHCP6_AUTHPROTO_RECONFIG case (https://github.com/jinmei/wide-dhcpv6/blob/master/common.c#L1696) is enclosed in an #ifdef:
Code: [Select]
#ifdef notyet
case DHCP6_AUTHPROTO_RECONFIG:
break;
#endif
default:
dprintf(LOG_INFO, FNAME,
    "unsupported authentication protocol: %d",
    *cp);
goto fail;

So, does that mean it is simply not implemented (yet)?