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

    How to Allow "Privacy Addresses" on the LAN?

    Firewalling
    2
    4
    588
    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.
    • beremonavabiB
      beremonavabi
      last edited by beremonavabi

      Examining my Firewall log, I'm seeing LAN UDP traffic from "privacy addresses" (they look like the first 4 hextets of the device's IPv6 address with another 4 hextets of something else added on) hitting the default deny rule on my LAN. According to the MAC addresses associated with those privacy addresses, these are all valid devices on my LAN interface. It looks like the default deny rule is preventing them from talking to the actual LAN interface (they're all trying to talk to port 53 (DNS)). I'd put a screenshot of my log entries, but I'm not sure if I should be posting those privacy addresses publicly.

      Anyway, since I'm only guessing that those addresses are generated by tacking some random stuff onto the first four hextets of the device's IPv6 addresses, I'm not sure of the best way to write a rule to allow them. Any suggestions?

      EDIT 1: It would probably have been a good idea to include a copy of my current LAN firewall rules:

      0_1543890560913_20181202 -- pfSense 2_4_4 Firewall Rules LAN.jpg

      EDIT 2: And here's an example of what I'm seeing in the Firewall log:

      0_1543938870779_20181204 -- pfSense 2_4_4_1 Firewall LAN Blocked IPV6 Stuff.jpg

      SG-4860, pfSense 2.4.5-RELEASE-p1 (amd64)

      1 Reply Last reply Reply Quote 0
      • JKnottJ
        JKnott
        last edited by

        Didn't I answer this earlier?

        Privacy addresses are normal. The reason for them is privacy concerns with using addresses based on the MAC addresses. Privacy addresses are generated daily from random numbers and last for a week. Incoming connections, such as for servers, use the consistent address, often based on the MAC.

        PfSense running on Qotom mini PC
        i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
        UniFi AC-Lite access point

        I haven't lost my mind. It's around here...somewhere...

        beremonavabiB 1 Reply Last reply Reply Quote 0
        • beremonavabiB
          beremonavabi @JKnott
          last edited by

          @jknott said in How to Allow "Privacy Addresses" on the LAN?:

          Didn't I answer this earlier?

          Privacy addresses are normal. The reason for them is privacy concerns with using addresses based on the MAC addresses. Privacy addresses are generated daily from random numbers and last for a week. Incoming connections, such as for servers, use the consistent address, often based on the MAC.

          No. You explained what they were. The problem I'm seeing is that pfSense is blocking them on my LAN. I'm now trying to figure out how to stop that. I'm assuming that if the devices on my LAN are trying to send that traffic to the router/firewall (i.e., pfSense), the traffic must be valid. Are you saying it's OK that pfSense is blocking the internal traffic that uses those privacy addresses?

          SG-4860, pfSense 2.4.5-RELEASE-p1 (amd64)

          1 Reply Last reply Reply Quote 0
          • beremonavabiB
            beremonavabi
            last edited by beremonavabi

            I'm also seeing traffic sourced from the link local address of some devices (my wife's phone is the one I'm now looking at) being blocked on the way to port 53 of the LAN address. I wish these IPv6 additional addresses fell into the "LAN net" macro (or whatever that's called). Am I going to have to add a rule on the LAN allowing ALL IPv6 traffic to all destinations? That doesn't sound good.

            SG-4860, pfSense 2.4.5-RELEASE-p1 (amd64)

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