You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OpenWRT currently has no effective support for firewalling IPv6 on a per-device basis, either to allow inbound connections or to block outbound connections. IPv4-style firewall rules, based on the assumption of fixed IP addresses, do not work in IPv6 dynamic addressing environments (e.g. DHCPv6-PD) encountered by most OpenWRT users. As a result, the benefits of IPv6 in allowing for easier, NAT-free, VOIP communications, gaming, and other purposes that need inbound connectivity are not available to OpenWRT users.
IPv6 firewalling needs rules tied to devices by hostname, DUID, or MAC address. Ip6tables does not support this, and much of the functionality would need to be developed in the form of a shim that would dynamically update ip6tables as IPv6 addresses change on the user's LAN.
As I see it, the shim architecture would need two parts plus a user interface:
a configuration management component that stores IPv6 firewall rules in terms of hostnames, DUIDs, MAC addresses, or other unique identifiers, such as captive portal logins, or 802.1x.
a tracking component that maps hostnames/DUID/MACs to IPv6 addresses that ip6tables can use, and updates ip6tables as these addresses change. This component would need to tie into the LAN-side addressing infrastructure to detect changes in device addresses, such as DHCPv6 leases. It would also need to periodically use [[https://man7.org/linux/man-pages/man8/ip-neighbour.8.html|ip neigh]] to identify IPv6 devices, such as those running Android, that don't use DHCPv6. It could also tie into a default-deny ip6tables rule so when an unknown address attempts to connect via IPv6, the tracking component would use ip neigh to identify the MAC of the device and load the appropriate ip6tables rules.
The address mapping component I have described wouldn't work for non-DHCPv6 devices on LANs with multiple broadcast domains (IPv6 neighbor discovery doesn't work through routers. Coping with non-DHCPv6 devices on routed LANs would require a captive portal system, or 802.1x support, to tie IPv6 addresses to specific devices. I doubt this situation would apply to very many, if any, OpenWRT users.
Any thoughts?
The text was updated successfully, but these errors were encountered:
You can use a notation like option dest_ip ::73cd:243d:7c20:937/::ffff:ffff:ffff:ffff to match the last 64 bit (the host part) of an IPv6 address while ignoring any dynamic prefix portion.
This works for both ip6tables and the UCI firewall and should give sufficient abilities to create device-specific, prefix-agnostic rules assuming that the target device uses any sort of stable IPv6 address assignment.
nowhere:
OpenWRT currently has no effective support for firewalling IPv6 on a per-device basis, either to allow inbound connections or to block outbound connections. IPv4-style firewall rules, based on the assumption of fixed IP addresses, do not work in IPv6 dynamic addressing environments (e.g. DHCPv6-PD) encountered by most OpenWRT users. As a result, the benefits of IPv6 in allowing for easier, NAT-free, VOIP communications, gaming, and other purposes that need inbound connectivity are not available to OpenWRT users.
IPv6 firewalling needs rules tied to devices by hostname, DUID, or MAC address. Ip6tables does not support this, and much of the functionality would need to be developed in the form of a shim that would dynamically update ip6tables as IPv6 addresses change on the user's LAN.
As I see it, the shim architecture would need two parts plus a user interface:
a configuration management component that stores IPv6 firewall rules in terms of hostnames, DUIDs, MAC addresses, or other unique identifiers, such as captive portal logins, or 802.1x.
a tracking component that maps hostnames/DUID/MACs to IPv6 addresses that ip6tables can use, and updates ip6tables as these addresses change. This component would need to tie into the LAN-side addressing infrastructure to detect changes in device addresses, such as DHCPv6 leases. It would also need to periodically use [[https://man7.org/linux/man-pages/man8/ip-neighbour.8.html|ip neigh]] to identify IPv6 devices, such as those running Android, that don't use DHCPv6. It could also tie into a default-deny ip6tables rule so when an unknown address attempts to connect via IPv6, the tracking component would use ip neigh to identify the MAC of the device and load the appropriate ip6tables rules.
The address mapping component I have described wouldn't work for non-DHCPv6 devices on LANs with multiple broadcast domains (IPv6 neighbor discovery doesn't work through routers. Coping with non-DHCPv6 devices on routed LANs would require a captive portal system, or 802.1x support, to tie IPv6 addresses to specific devices. I doubt this situation would apply to very many, if any, OpenWRT users.
Any thoughts?
The text was updated successfully, but these errors were encountered: