Messages

I am also seeing this error, as a banner on the dashboard:

> Possible deployment misconfiguration: devices with public IP addresses detected
> Zenarmor's health check system detected 7195 devices with public ip addresses associated with them.

Under "Live Sessions" I see connections with correct internal src and external dst addresses, but where the "Device" is listed as the IP of the destination address. For example, I see a connection from a local Macbook to iCloud on VLAN1, where the device shows up as a public iCloud IP "Device (ip4:#.#.#.#)" instead of the private Macbook IP.

This started in May, but I just upgraded to 1.17.4 and opnsense 24.1.8 with no change. After rebooting, I still see the warning and incorrect Device names for new connections.

I currently have Zenarmor running in passive mode, monitoring 7 VLANs on a LAGG. (Zenarmor is configured to monitor each VLAN individually, as having it monitor the underlying LAGG interfaces separately resulted in packet loss in the past, due to some connections using both interfaces.)

I have multi-wan setup, but only internal VLANs are configured.

Confirming this is fixed in 23.1.2  :)

I think this is also related to the issue I'm experiencing in:
https://forum.opnsense.org/index.php?topic=32231

I suspect it has something to do with these changes in rc.newwanipv6, but not sure:
https://github.com/opnsense/core/compare/22.7..23.1#diff-f75df381ea54006769fdb7e552994d8d709ff9f9d71eb739db6311b6179f44f7R87

After upgrading from 22.7 to 23.1, I need to restart radvd in the web interface to get ipv6 PDs from my WAN to appear in /var/etc/radvd.conf. Before restarting radvd, I only see virtual IPs that I've assigned to the interfaces. After restarting it, I see virtual IPs along with the prefixes delegated from the WAN.

My LANs all use "Unmanaged" RAs with no DHCPv6 server running. I've also tried "Stateless" with no improvement.

I'm on AT&T fiber with a custom configuration (similar to https://github.com/lilchancep/att-pfsense-ipv6) to request four separate /64s from my BGW320. I had to patch a heap overflow in dhcp6c to make this stable in 22.7 (https://github.com/opnsense/dhcp6c/pull/33) but this issue is separate, and still occurs without the patch.

Seems like something should call dhcpd_radvd_configure after the prefixes are assigned to the interfaces?