DHCP v6 - VLAN priority not honored

[renehonig]

Important notices

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug
I am running the OPNsense 23.1_6-amd64 (FreeBSD 13.1-RELEASE-p5, OpenSSL 1.1.1s 1 Nov 2022) release.
My ISP requires all WAN communications on VLAN 832 and the use of VLAN priority/DSCP CS6 for all control comms like DHCP and CS0 for the rest. I have configured the 'Use VLAN priority' field in the DHCP v6 config as 'Internetwork Control (6)'.

Capturing the network traffic on the interface shows that all DHCP v6 related comms from the firewall to the ISP router does not honor the DSCP CS6 setting, whilst all related comms back from the ISP is tagged as CS6 (as expected).

To Reproduce

Steps to reproduce the behavior:

1. Create a VLAN tagged 832 on the WAN interface
2. Set 'VLAN priority' to 'Internetwork Control (6)' in 'DHCPv6 client configuration'
3. Start packet capture on interface
4. Renew the lease
5. Inspect the DHCP related packets and look for DSCP label

Expected behavior
DSCP property of DHVP v6 related packets to be labeled as CS6.

Describe alternatives you considered
I tried this on the most recent set of OPNSense releases, all with the same result.

Screenshots

interface configuration:

---

Wireshark packets overview:

---

Wireshark request packet details:

---

Wireshark reply package details:

Environment

OPNsense 23.1_6-amd64 (FreeBSD 13.1-RELEASE-p5, OpenSSL 1.1.1s 1 Nov 2022)
Intel(R) Celeron(R) N5105 @ 2.00GHz (4 cores, 4 threads)
Network Intel i225-V B3 2.5G

[fichtner]

# grep set.prio /tmp/rules.debug

The likely problem could be that another rule overwrites the one that tries to set the priority. Let's first make sure set prio statement is there and tries to apply the correct value to correct traffic.

Cheers,
Franco

[fichtner]

PS: Does IPv6 connectivity work in general? Tapping from WAN interface with bpf might show the state before the outgoing traffic is modified accordingly.

[renehonig]

Thanks for the quick response! IPv6 works in general, but obtaining a lease does not always work or may take a long time. The ISP (Orange) has also indicated that they are tightening controls around non-compliant DHCP requests which will result in not being able to obtain an IPv4 address or IPv6 PD.

output of grep set.prio /tmp/rules.debug:
pass out log quick on igc0_vlan832 proto udp from {any} port {546} to {any} port {547} set prio 6 label "f053842de04b0878ad62f35508490428" # allow dhcpv6 client in VLAN832

So rule seems to be there...

[fichtner]

It's set to log so you you should at least see if it matches in firewall live log?

If it matches it would be better to dump traffic in front of the opnsense to see the actual traffic on the wire. If there is no match in rules something else seems to snatch this traffic.

Worst case igc driver could refuse to set the tag for one reason or another. Was this working in 22.7.x or new setup?

Orange and conformity is a joke with what hoops one has to deal with regarding their "standard" connectivity ;)

[renehonig]

Thanks, helpful. The rule matches:

---

Will try to make a dump of traffic upstream of opnsense later. This was not working in 22.7.x either (discovered it a while ago). And yes, if Orange had a bridging mode for IPv4 and would do proper distribution of IPv6 PDs on their Livebox, we would not have to jump through all these hoops...

Any suggestions on debugging whether this is a igc driver problem?

[fichtner]

The packet capture in front of the OPNsense is crucial information now. It looks correct so far :)

[OPNsense-bot]

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository,
please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue,
just let us know, so we can reopen the issue and assign an owner to it.