Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    pfSense and disapling prefix delegation for LAN side

    Scheduled Pinned Locked Moved IPv6
    dhcpv6lan
    1 Posts 1 Posters 412 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      mmmzon
      last edited by

      Good morning, forum

      I have a rather odd setup, in which I need to configure strictly controllable IPv6 scheme on the LAN side of pfSense. There is no IPv6 on WAN side, I tunnel IPv6 over WireGuard to the far end with the same setup, creating essentially for now two isolated IPv6 enabled LAN segments.

      I added my static IPv6 addresses on LAN subinterface, which seems to be straightforward enough

      e933dc05-1e6c-491d-aa58-1206df4b51b6-image.png

      9e1113a5-8d31-4e43-8dd5-1e6a04d2bb87-image.png

      The other side of my setup uses VLAN 151 (just for sake of forcing routing)

      f5964dca-f5c9-408a-8f9a-08783703caa1-image.png

      Now, within each LAN segment, I want to control address allocation to individual hosts and be able to track them for security reasons, similar to what would be done on DHCPv4. Down the road, I will want to disable SLAAC altogether. In this setup, I do not need prefix delegation at all

      b264ae41-7022-4500-8e7d-3be72a087ec6-image.png

      but there does not seem to be a way to bypass or not fill it in. The form checker seems to enforce the PD population unconditionally. Is there a way to disable PD altogether on the LAN side when and if PD is not to be used at all? This is always an option on bigger systems, where PD is just an option to be enabled (or not), depending on the use case. In pfSense, it seems to be required under the assumption that LAN prefixes are always derived from the ISP-assigned larger prefix.

      Thank you!

      1 Reply Last reply Reply Quote 0
      • First post
        Last post
      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.