Messages

Could my problem be related to this topic? One of my opnsense boxes has erratic behavior since 24.7.x . Managed radvd stopped working but when I switch to Assisted, only hosts that don't have a static reservation are getting an IP (slaac i think).

Another opnsense box in a different location but on the same ISP and with almost the same settings doesn't have this issue.

I've found a user with the same issue and temporary solution https://github.com/opnsense/core/issues/6671

The LAN interface is set as a Static IPv4 + Track Interface for IPv6 (WAN, Prefix ID set and checked allow manual adjustments of DHCPv6). I haven't changed anything on the interfaces for a few years though.

I've been running 23.7 for a week, and I have an issue with getting an IPv6 assigned on WAN.

I have 3 setups, almost identical, in different geographic regions within my country but with the same ISP (Digi Romania).

The settings are:

• ipv4: PPPoE
• ipv6: Dhcpv6
• MSS: 1452
• Prefx Delegation size: 56
• Send IPv6 prefix hint: checked
• Use IPv4 Connectivity: checked
• Advanced: Use IPv4 Connectivity: Checked

So, this setup worked pre-23.7, till 23.1.11 and now it doesn't. As I upgraded all 3 sites, they all lost IPv6 (but they do work via Hurricane Electric). At some point, I think it was 23.7, I used to get ipv6 addressess assigned to WAN and lose it after about 5 minutes, but now on 23.7.1_3 I'm not getting any from the get-go (reboot).

I've rolled back one of my sites to 23.1.11 and IPv6 works again.

I've looked through the logs, but I can't identify the issue. Except for the following:

Code Select Expand

2023-08-21T00:52:53 Notice kernel <7>cannot forward src fe80:2::18de:[redacted]:fe9f:cca7, dst 2a02:[redacted]:fe68:f8d0, nxt 17, rcvif vtnet1, outif pppoe0

That IPv6 looks like something I'd usually get assigned by the ISP - and they're similar on both non-working sites. My ISP assigns different IPv6 on each reboot. I haven't changed any rules between upgrades. The only thing I did, was add DNS servers in System -> General per my post

Hello!

Thanks for the fast reply and sorry for my delay.

I did some tests and I couldn't do a connectivity audit. The screen just stayed blank, but it's kind of clear now that opnsense wasn't able to check the mirrors for updates. There were 2 lines in the update panel that hinted this:

Code Select Expand

Fetching changelog information, please wait... fetch: transfer timed out
fetch: /usr/local/opnsense/changelog/changelog.txz appears to be truncated: 0/285072 bytes

What threw me off was that the update always ended with this line:

Code Select Expand

Your packages are up to date.

I've been running without DNS forwarders in Systems -> Settings -> General - I think it had something to do with running NextDNS over TLS + VPN client or something. Weirdly I can't remember exactly why I did it.

Anyway, I've added DNS servers in General, rebooted the firewall, and voila.

This also fixed another issue. I wasn't getting an IPv6 address on WAN anymore. I could see it in the logs on boot, but then it dissappeared.

I'd say my issue is fixed. Thanks!

Hello.

I've upgraded from 23.1.11 to 23.7 (and separately, directly to 23.7.1_3). I did this on 2 separate systems and both times my plugins show up as orphaned.

On one of the systems I've rolled back and uninstalled dyndns as I thought it'd be the cause. But all plugins still showed up as orphaned.

I've reinstalled different packages on different systems, and upon plugin refresh, they still showed up as orphaned. But they showed up as misconfigured or installed initially. I don't know what to make of this. It also takes a very long time to display the status of the plugins (it's in the order of minutes).

I've been using the cron script to restart radvd and dhcpv6 since 2020. I've been on 22.1 for a few weeks and hadn't the issue anymore. Yay!

I've tried a variety of settings but I can't get to the bottom of this.

When I switch the Windows VMs to other test VLANs that have DHCPv6 and RA enabled, Windows picks up an IPv6 address and works. I've compared the wireshark icmpv6 RA packets and they look almost identical (LAN vs test  VLAN). It's not just the VMs, I've a baremetal Windows host with the same behavior.

The radvd settings for LAN and test VLAN interfaces look almost identical. I found only 2 differences between the them:

1. radvd for LAN shows and MTU of 1492 (same as WAN) whereas the test VLAN has an MTU of 1500. I've tried setting LAN AdvLinkTMU to 1500 in RAs but it's ignored and the generated radvd.conf file has 1492.

But I don't think that's the issue either. If I set an AdvLinkMTU of 1492 in the test VLAN when the interface has an MTU of 1500, Windows still works. When I set an interface MTU of 1492, it works.

So, I don't think MTU is the issue.

2. AdvRouteLifetime was 0 for LAN and 1800 for the test VLAN (even though the respective fields were left empty by default). So I've set an AdvRouteLifetime of 1800 for LAN with no effect.

I've enabled radvd logging with:

Code Select Expand


/usr/local/sbin/radvd -d 5 -p /var/run/radvd.pid -C /var/etc/radvd.conf -m logfile -l /var/log/radvd.log

but the only weird thing is this message via pppoe0 (WAN):

Code Select Expand

pppoe0 received icmpv6 RS/RA packet on an unknown interface with index 22


This is my generated radvd.conf file

# Automatically generated, do not edit
# Generated for DHCPv6 server lan
interface vtnet1 {
   AdvSendAdvert on;
   MinRtrAdvInterval 200;
   MaxRtrAdvInterval 600;
   AdvLinkMTU 1492;
   AdvDefaultPreference high;
   AdvManagedFlag on;
   AdvOtherConfigFlag on;
   prefix [LAN ipv6 prefix]::/64 {
      DeprecatePrefix off;
      AdvOnLink on;
      AdvAutonomous off;
   };
   route ::/0 {
      RemoveRoute off;
   };
   RDNSS [ipv6] {
   };
   DNSSL [local domain] {
   };
};
# Generated for DHCPv6 server opt12
interface vtnet1_vlan117 {
   AdvSendAdvert on;
   MinRtrAdvInterval 200;
   MaxRtrAdvInterval 600;
   AdvLinkMTU 1500;
   AdvDefaultPreference medium;
   AdvManagedFlag on;
   AdvOtherConfigFlag on;
   prefix [vlan ipv6 prefix]::/64 {
      DeprecatePrefix on;
      AdvOnLink on;
      AdvAutonomous off;
   };
   RDNSS [ipv6] {
   };
   DNSSL [local domain] {
   };
};

My Windows VMs are not renewing their DHCPv6 leases from Opnsense but Linux VMs don't have issues.

On a network with opn 2.1.6, the hosts don't renew unless I reboot or apply ipconfig /renew6 via cmd. On another network with opn 2.1.5, they won't renew even when I try /renew6. The sites and windows VMs are setup largely the same.

In wireshark I can see the RAs to ff02::01 (the lines are marked with pink if this matters).

How can I troubleshoot this?

Edit:
I believe I've encountered this open issue w/ regard to this part

On another network with opn 2.1.5, they won't renew even when I try /renew6.

If I restart the dhcpv6 service, then ipfconfig /renew6 works on the Windows host

Wrong ACL in Unbound maybe? Have you used log / log level to see if requests are made?


Cheers,
Franco

I've a custom ACL to allow all. I've enabled logging and I can't see the requests. They are not reaching the firewall at all cause I'm monitoring firewall traffic for port 53

I have two sites, A and B. Between them there's an IPv4 IPSEC connection. Both sites have dynamic IPv6 WANs and Hurricane Electric (HE_WAN) tunnels for static IPv6 WAN addresses. Problem is, Unbound doesn't use HE_WAN interface for address resolution of Domain Overrides.

In Unbound I've set Domain Overrides for each others' site internal domain, to the respective HE_WAN IPv6 address. For example Domain A has a Domain Override: DomainB.com -> HE_WAN_Site_B_IPv6 and Site B has DomainA.com -> HE_WAN_Site_A_IPv6 .

Unbound's Outgoing network interfaces have WAN, HE_WAN and IPSEC set on both sites. They both listen on all interfaces.

Unbound won't do lookups via HE_WAN on either site. They use WAN IPv6 and IPSEC IPv4 interfaces but won't use HE_WAN, even if it's the only one selected as Outgoing Network Interface - in this case, it'll use WAN IPv6.

I've checked all rules and HE_WANs respond to Unbound queries. If I use something like

Code Select Expand

dig -b HE_WAN_Site_A_IPv6 DomainB.com @HE_WAN_Site_B_IPv6

it works properly.

I've also a 3rd site which I've used to confirm this behavior. As far as I know, Unbound should use all interfaces for  queries and I'm pretty sure this was the behavior on pfsense. Site A runs opn 2.1.6 while Sites B and C use 2.1.5.

I have a /56 dynamic prefix allocated from my ISP. I've configured 4 VLANs with Track interface and Manual DHCPv6 and Router advertisments. One of those VLANs (i.e. VLAN D) has both DHCPv6 server and RA disabled. RA is set to Managed on the other interfaces.

Windows Hosts on VLAN A are getting an IPv6 address from their own VLAN (Native VLAN, i.e. VLAN A) but they're also getting an IPv6 address and termporary address from VLAN D. These extra IPv6 addresses are not present in DHCPv6 leases and they're not part of the DHCPv6 range set on the interface. Windows Hosts also have the other interfaces as DNS servers.

Make sure the Windows host and any non VLAN aware host are not on ports that send tagged VLAN traffic, those ports for end devices should ONLY have untagged packets for a single VLAN.

Yeah, so you were right. My Windows VM was sitting on the default vmbr0 bridge in Proxmox. When I've set VLAN tag 1 in Proxmox or within the Windows VM, I stopped getting IPv6 addresses from the other interfaces. I've tried researching this a bit to understand and ran a wireshark packet capture, but I'm lacking some fundamental networking knowledge that prevents me from understanding.

Is it because RAs are sent over ICMP to all VLANs? Or is it that the RA is sent via tagged VLAN and Windows simply picks up that packet? I saw that there's something called SLAAC snooping that should prevent this behavior.

And yes, the Windows Hosts are getting RAs (or IPv6 addressing) from an interface to which they're not connected to.

I wouldn't rule out network misconfiguration here. Basically I've Proxmox Host A (1 x Opnsense VM) -> Switch -> Proxmox Host B (other VMs). It might be that somehow I've indirectly connected the 2 VLANs.

I've enabled router mode again on VLAN D and now I'm getting an IPv6 address from VLAN B.

Update: I'm attaching a netsh query. So, ::7f02:: is the interface it's currently sitting on (LAN). The other 2 are other VLANs where RAs are enabled and not shown ::7f30:: which is currently in Router mode.

Disabled is disabled, meaning it shouldn't send any RAs. Can you post /var/etc/radvd.conf with mode "Disabled" and "Router Only"?

What also doesn't make sense to me is that your clients seem to receive RAs from a VLAN which they are not actually connected to. Did I get this correctly? Or are these clients connected to multiple VLANs simultaneously?

Cheers

Maurice

Here's the relevant bit with RA "Disabled":

Code Select Expand

# Generated config for dhcp6 delegation from wan on opt2
interface vtnet1_vlan68 {
AdvSendAdvert on;
AdvLinkMTU 1492;
AdvManagedFlag on;
AdvOtherConfigFlag on;
prefix [IPv6 Prefix)::/64 {
AdvOnLink on;
AdvAutonomous on;
};
RDNSS [xxx:xxxx] { };
DNSSL [domain name]{ };
};


This is how it looks like in "Router" mode:

Code Select Expand

# Generated for DHCPv6 server opt2
interface vtnet1_vlan68 {
AdvSendAdvert on;
MinRtrAdvInterval 200;
MaxRtrAdvInterval 600;
AdvLinkMTU 1492;
AdvDefaultPreference medium;
AdvDefaultLifetime 0;
prefix [Ipv6 prefix]::/64 {
DeprecatePrefix on;
AdvOnLink off;
AdvAutonomous off;
};
RDNSS [xxx:xxx] {
};
DNSSL [DOMAIN NAME] {
};
};

On this VLAN I have only 1 VyOS VM.

And yes, the Windows Hosts are getting RAs (or IPv6 addressing) from an interface to which they're not connected to.

(which I assume is SLAAC, given your experience).

Yeah looks like SLAAC. I don't have much experience with IPv6 though I'm learning just now.

Try setting "Router Only" in the RA config (as per the help text)

Thanks, looks like it works. I don't understand why would "Router" be better than "Disabled" in this case. The help text doesn't give details about "Disabled" so I just expected it to be ... disabled.