Interface disabled but IPv6 addresses get assigned?!

[gd3000]

Hello!

I've a not-assgined, disabled interface which is connected to a network (link up). Even though it's disabled it gets IPv6 addresses assigned (link-local and global via slaac).
How can I prevent this behavior?

Is it possible to run an active VLAN interface on top of this disabled interface?

[stefan00]

VLAN: You don't have to disable the parent interface. Indeed in all my use cases I have it enabled (HW settings etc).

Example config for VLANs:

hardware interface settings:

(1) enable the interface

(2) set both IPv4 and IPv6 Configuration Type "none" *)

(3) adjust hardware settings as needed

VLAN setting:

(4) create your VLANs

(5) assign your hardware interface as parent

Assignments:

(6) assign / add the VLAN interfaces


*) note: The interface will still have a link-local IPv6. That's correct.

[gd3000]

Thanks for your reply.
I'm sorry to not be clear enough: I want the parent interface to be disabled and not have an IPv6 address assigned. It's important for routing reasons that the parent interface does not get an global address assigned via slaac. But I can't figure out how to prevent this.
Also currently i deleted the vlan interface for testing. But either way the parent interface receives IPv6 addresses. I want to make this auto-assignment stop.

[Patrick M. Hausen]

This is one of the situations where the "don't mix tagged and untagged on the same port" comes into play.

Apparently the untagged parent receives a router advertisement and performs SLAAC. This (the presende of the router advertisements) should not be the case on the untagged interface.

What is connected to that port and why is there untagged traffic? Can you change the "native VLAN" to something unused on your switch and run all VLANs tagged as generally recommended?

HTH,
Patrick

[gd3000]

It is currently a "simple" interface, which is not assigned or configured. It has a link to a LAN where lots of ordinary untagged LAN traffic is going on. On the LAN is another router which does to RAs and provides the SLAAC prefix information.
Leaving all the thoughts about VLANs out of the story for now: why does a "not assigned" (and thus deactivated) interface react on RA packages?
When I read "deactivated" in the interface listing, I expect it to be inactive and quiet.

See the interface list in the attachment. I'm talking about interface `vtnet0`.

[Patrick M. Hausen]

Leaving all the thoughts about VLANs out of the story for now: why does a "not assigned" (and thus deactivated) interface react on RA packages?
When I read "deactivated" in the interface listing, I expect it to be inactive and quiet.

Agree - please file an issue on Github.

Reading your previous post I assumed you want to run VLANs over that port? So while that problem is not fixed in OPNsense you can configure around it by not allowing untagged traffic on that port.

[gd3000]

Thank you for your confirmation that this is not an expected behavior.

Agree - please file an issue on Github.

Issue created: https://github.com/opnsense/core/issues/8110

Reading your previous post I assumed you want to run VLANs over that port? So while that problem is not fixed in OPNsense you can configure around it by not allowing untagged traffic on that port.

Yes, actually I want to run an VLAN on top of this interface. But since this issue currently ruins my routing table I'll need to wait until it is fixed.

[Patrick M. Hausen]

Reading your previous post I assumed you want to run VLANs over that port? So while that problem is not fixed in OPNsense you can configure around it by not allowing untagged traffic on that port.

Yes, actually I want to run an VLAN on top of this interface. But since this issue currently ruins my routing table I'll need to wait until it is fixed.

Just set the native VLAN for that port to something unused on your switch and you should be good.

[stefan00]

Just checked on a OPNsense VM. Setup of this VM: Pure LAN client (other box on this network advertises stateless)

Two findings, not to mix up:

(1) VTNET (parent) interface enabled and assigned, both IPv6 and IPv6 config types set to "none": Interface does not receive a IPv6, only link-local

(2) unassigning the interface without disabling it first: status active, full IPv6 assigned (nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>).

After rebooting, everything is fine (if down, no IPv6). So it seems changes to not properly reflect right away. That might indeed be worth a bug report but should be double checked by someone running a recent version (older install on this VM here).

Edit1: Additionally, I think this whole thing would be more clear if interfaces->overview would have 4 colored "plug" icons for the 4 displayed states (up, up disabled, down, down disabled) - which are currently only visible while hovering with the mouse - so not on a tablet.

Edit2: checked across reboots

[franco]

> (2) unassigning the interface without disabling it first: status active, full IPv6 assigned (nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>).

I'd rather not touch this. If it's consistently disabled across reboot that is the more important question.

Take for example someone assigning a parent interface then removing... you don't know what traffic is flowing.

[gd3000]

A reboot of the VM resolved the issue for me. The unassigned interface now does not set any IPv6 addresses anymore.

Not quite intuitive, but it seems like this situation is not clearly reproducible by other. Hence it may be some weirdness appearing in my specific setup....

[franco]

Discussion in the bugtracker had a little more of the gory details and problems faced. Linking here for reference.

https://github.com/opnsense/core/issues/8110#issuecomment-2523657842


Cheers,
Franco

[pfry]

Bumping this here as I don't have a github login (at the moment)...

Uncontrollable autoassignment of IPv6 link-local addresses to physical interfaces and VLANs (but not bridges, which offer a checkbox) is rather disturbing, especially to bridge members. Could be a nitpick, but I'd rather simply get rid of them rather than dig into potential issues.

[pfry]

...aaaand replying to myself, as usual.

sysctl net.inet6.ip6.auto_linklocal=0

I'll get this research-before-posting deal one of these days. Heh -- back in the '90s on usenet folks were a bit less polite. Ah, the good old days...