Messages

I'm messing around with this again with the help of Google's AI.

Here is a fragment of a packet capture. 2***:****:****:e97f::2 is the domain controller running the DHCP server, and 2***:****:****:e97f::1 is the main LAN interface's static IPv6 address:

Code Select Expand

Frame 42: Packet, 193 bytes on wire (1544 bits), 193 bytes captured (1544 bits)
Ethernet II, Src: Intel_ff:09:6b (68:05:ca:ff:09:6b), Dst: Microsoft_01:04:01 (00:15:5d:01:04:01)
Internet Protocol Version 6, Src: 2***:****:****:e97f::1, Dst: 2***:****:****:e97f::2
User Datagram Protocol, Src Port: 547, Dst Port: 547
DHCPv6
    Message type: Relay-forw (12)
    Hopcount: 0
    Link address: fe80::6a05:caff:feff:96b
    Peer address: fe80::103c:445d:15f3:943e

After some time troubleshooting, this was the AI's opinion on the matter:

...this packet capture confirms OPNsense is doing something very specific: it is using its Main VLAN IP (...e97f::1) to send the packet, but it is putting the IoT Link-Local IP (fe80::...) inside the Link address field.

Windows Server sees that fe80 inside the "Link address" box and says, "I don't have a scope for fe80, so I'm ignoring this."

To fix this, we have to force the dhcp6relay binary to use the Global IP for that internal field.

So, is this a limitation of Windows Server, dhcp6relay, or is the AI just hallucinating?

Examining a packet capture, I was able to trace the requests back to my mail server, which is in a VM on a separate VLAN. I'll have to figure out why it's asking for this particular domain.

I'm seeing DNS queries for A and AAAA records for jetstream.tour.in. tour.in doesn't exist. In 'Reporting', it accounted for somewhere around 10 percent of passed domains (making it the largest by far) before I put it in a blocklist. I'm almost certain that I don't have any malware on any of my devices. Has anyone else encountered this domain?

You're correct that dhcp6d won't run when dhcrelay is running on the same interface.

I was more concerned by the fact that it doesn't seem to listen on specific interfaces, but it appears that the SO_REUSEADDR socket option would allow both to listen on the same port at the same time.

So, have you tried a packet capture (for port 547) on the interface that the DHCP server is routed through?

I did, and I saw the DHCPv6 solicit and relay-forward messages. No response from the server though.

Yep, under 'System: Diagnostics: Services', there are two dhcrelay services, one each of DHCPv6 for both opt1 (vlan01) and opt2 (vlan02). Both those are running. A screenshot of 'Services: DHCRelay: Configuration' is attached. You're correct that dhcp6d won't run when dhcrelay is running on the same interface.

I noticed a couple weeks ago that clients connected to my VLANs weren't receiving IPv6 addresses from my Windows DHCP servers. They do receive IPv4 addresses just fine. I think the Windows DHCP servers are configured correctly, so I'm wondering if there's something wrong with my OPNsense system. I have router advertisements set to 'Managed' for the LAN (clients there get assigned IPv6 addresses without any issues) and the two VLANs. 'Advertise Default Gateway' is checked, no route advertisements are specified, and 'Do not send any DNS configuration to clients' is checked. But, if radvd is set to 'Assisted', 'Unmanaged', or 'Stateless', the VLAN clients will get IPv6 addresses using SLAAC, not through the Windows servers though. DHCRelay is configured with the IPv4 and IPv6 addresses of the two Windows DHCP servers. I use Ubiquiti Networks Unifi switches, and DHCP snooping is disabled for both VLANs. 'Rogue DHCP Server Detection' is also disabled. A packet capture shows that there are DHCPv6 solicitations that are being transmitted from the clients (destination of ff02::1:2). Am I missing something here?

Thanks!

I'm using an AT&T residential gateway in passthrough and am using a DHCPv6 client configuration file override to get a few IPv6 prefix delegations. Since AT&T's gateway device clears all prefix delegations when it is rebooted, I lose IPv6 connectivity until I do a manual reset of the WAN interface in the OPNsense GUI, either by disabling and reenabling the WAN interface, or by doing a quick 'Save' and 'Apply changes'. IPv6 is restored, because the configuration file is reloaded, and OPNsense re-requests the delegations.

Is there any way to have this process happen automatically when OPNsense sees that the WAN connection is dropped and reestablished?

Thanks!

That is, maybe it's something in the way Hyper-V does PCI passthrough that FreeBSD 13.x doesn't like. When you do the same using Proxmox VE, does it give any errors upon the initial boot of your OPNsense guest?

I was having problems trying to pass through my Intel X710-T4L from a Windows Server 2022 Hyper-V host. I keep getting this under FreeBSD 13.x:

Code Select Expand

ixl0: PF reset failure I40E_ERR_RESET_FAILED

But this is well before any VLANs can be assigned. The card just doesn't work upon initial boot. It does in FreeBSD 14.0 though.

Maybe it's Hyper-V. I'll be moving my VMs to Proxmox VE very soon.

It was probably looping packets all day due to that setup?


Cheers,
Franco

Heh, probably, though I didn't do any packet capture to verify.

I don't even need to be running the DHCP relay on the LAN, since the DHCP servers are on the same subnet.

Is anyone else experiencing this? dhcrelay in 24.1.6 is pegged at 100 percent usage. The NIC (igb1) is passed through to the OPNsense VM guest (running on Windows Server 2022 in Hyper-V) and has the LAN plus two VLANs running through it. 'Activity' shows that it is the LAN's dhcrelay process.

I've come over from pfSense, and I was wondering if OPNsense is planning on adding ChaCha20-Poly1305 as a supported IKEv2 cipher suite, and maybe accelerating it using the Intel multi-buffer crypto for IPsec library. I use both Wireguard and IPsec for VPNs.

The problem is in FreeBSD 13.2. A FreeBSD 14.0 guest works with this card passed through without problems. I verified this by booting both ISO install images.

Hello!

I was trying out OPNSense running under Hyper-V on Windows Server 2022 with an Intel X710-T4L using PCI passthrough for two out of the four ports. I get this error message, and while the system boots, I have no network interfaces:

Code Select Expand

ixl0: PF reset failure I40E_ERR_RESET_FAILED

This occurs with both ixl0 and ixl1 when booting either 23.7 Production, or 24.1 Development. A screenshot is attached.

Is there a way to fix this?

Thanks!