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

IPv6 temporary address rule

Scheduled Pinned Locked Moved General pfSense Questions
8 Posts 4 Posters 2.8k 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.
  • Z
    zarje
    last edited by Feb 23, 2017, 1:46 PM Feb 23, 2017, 1:24 PM

    I use IPv4/IPv6 at home on all my VLANs and the pfsense webgui has both IPv4/IPv6 addresses. I access the pfsense webgui from my desktop which is in a VLAN called "Desktops" and the pfsense webgui is in a VLAN called "Management".

    All my VLANs use static IPv4/6 addresses EXCEPT for the desktop VLAN which uses RA and DHCPv4/v6. So my desktop has the following IP addresses:

    2001:xxx:xxxx:10:e16c:342e:e07d:fc6c
    2001:xxx:xxxx:10:b965:b517:20d9:b466 (temporary/private IPv6 address)
    fe80::xxxx:342e:e07d:fc6c%8 (link local)
    192.168.10.136 (DHCPv4 address)

    My pfsense firewall rule to allow me to access the webgui is as follows:

    Protocol: IPv4+6 TCP
    Source: hostname.domain.com
    Destination: This Firewall
    Ports: 22 + 443

    So what happens is it takes some time for me to access the webgui from my desktop as it tries to access the webgui using IPv6 but I can see in the logs that it drops the connections from the temporary IPv6 address. It then changes to an IPv4 connection and I can view/login to the webgui

    How can I get my desktop to access the webgui via a dynamic (temportary) IPv6 address? I can't use a static IPv4/6 address on my deskop and I can't enter a source IPv6 address in the firewall rule as the temporary IPv6 changes everyday.

    If I temporarily assign myself a static IPv6 address it works.

    Any ideas?

    1 Reply Last reply Reply Quote 0
    • D
      doktornotor Banned
      last edited by Feb 23, 2017, 1:32 PM

      Fix your rule to not use broken alias.

      1 Reply Last reply Reply Quote 0
      • Z
        zarje
        last edited by Feb 23, 2017, 1:44 PM

        @doktornotor:

        Fix your rule to not use broken alias.

        The rule is using a valid hostname so I'm not sure what you mean?

        1 Reply Last reply Reply Quote 0
        • D
          doktornotor Banned
          last edited by Feb 23, 2017, 1:57 PM

          That valid hostname is obviously not valid for your temporary IPv6. So, you can either stop using the broken alias, or stop using the temporary addresses on your client.

          1 Reply Last reply Reply Quote 0
          • G
            garyd9
            last edited by Feb 23, 2017, 3:58 PM

            I think I understand the problem here…  and it's not something that ANY L3 firewall handles very well.

            To completely rephrase (and hopefully simplify) the issue:

            Assume that pfsense is set to block all outgoing traffic (from LAN to WAN.)  Now, you want to allow traffic from host "awesome-dude" to do whatever they want.  So, you go to Firewall->aliases, and create a new alias:

            Name:  Awesome_Dude
            Description:  This guy can walk on a water, so let him do anything he wants
            Type:  Host(s)
            IP or FQDN:  awesome-dude.my.net

            Then, you go into the firewall rules, and decide to brute force via a "floating" rule (not how I'd do it, but it illustrates the point).  You set things up however you want to pass the traffic, including an "Address Family" of "IPv4+IPv6", a "source" of "single host or alias" followed by "Awesome_Dude".  (There'd be other stuff to fill in for the rule, of course.)

            Then you discover that your rule isn't working.  You dig and find out that the REASON it's not working is that awesome-dude.my.net is giving itself a temporary IPv6 address, and using THAT for outgoing traffic.

            If you dig some more, you can check to see why, exactly, why this isn't working:  In pfsense, go to Diagnostics->Tables, and find the table matching the alias name in the droplist.  You'll see that any temporary IPv6 address will NOT be found here.

            The reason, as far as I can tell, is that pfsense uses DNS to resolve alias FQDN's into IP addresses.  Temp IPv6 addresses aren't registered into DNS, and so pfsense has no way to know what the temp IPv6 address is.  As a result, pfsense has no idea it should allow traffic from that temp IPv6 address.

            How to deal with the situation:  To make things work with existing pfsense, you'll have to disable the generation of temporary IPv6 addresses on awesome-dude.  If all your clients use DHCPv6 and/or register their IPv6 addresses with DNS, that will allow things to work.  However, any clients that use IPv6 SLAAC (which includes 100% of all android devices) likely don't register their IPv6 addresses with DNS.

            One alternative would be to generate code that uses ARP and NDP to try and match any NDP seen IPv6 addresses with MAC addresses from ARP. 
            Then insert those seen IPv6 addresses into whatever DNS resolver your using.  Of course, then you'd ALSO have to get pfsense to re-generate it's alias table any time the list of ipv6 addresses changes for a given MAC address.  (I've written code that does some of this, and it's NOT as easy as it sounds... and doesn't work quickly enough to help.)

            Another alternative would be to use a L2 firewall instead of pf.  The L2 firewall could allow/block/reject based on MAC addresses.  I saw something somewhere on this forum a while ago that allowed doing that (though I think it was used to block, and not to allow.  I don't know if it could be used to override a default "deny all" pf rule.)

            1 Reply Last reply Reply Quote 1
            • Z
              zarje
              last edited by Feb 23, 2017, 8:57 PM

              @garyd9:

              I think I understand the problem here…  and it's not something that ANY L3 firewall handles very well.

              To completely rephrase (and hopefully simplify) the issue:

              Assume that pfsense is set to block all outgoing traffic (from LAN to WAN.)  Now, you want to allow traffic from host "awesome-dude" to do whatever they want.  So, you go to Firewall->aliases, and create a new alias:

              Name:  Awesome_Dude
              Description:  This guy can walk on a water, so let him do anything he wants
              Type:  Host(s)
              IP or FQDN:  awesome-dude.my.net

              Then, you go into the firewall rules, and decide to brute force via a "floating" rule (not how I'd do it, but it illustrates the point).  You set things up however you want to pass the traffic, including an "Address Family" of "IPv4+IPv6", a "source" of "single host or alias" followed by "Awesome_Dude".  (There'd be other stuff to fill in for the rule, of course.)

              Then you discover that your rule isn't working.  You dig and find out that the REASON it's not working is that awesome-dude.my.net is giving itself a temporary IPv6 address, and using THAT for outgoing traffic.

              If you dig some more, you can check to see why, exactly, why this isn't working:  In pfsense, go to Diagnostics->Tables, and find the table matching the alias name in the droplist.  You'll see that any temporary IPv6 address will NOT be found here.

              The reason, as far as I can tell, is that pfsense uses DNS to resolve alias FQDN's into IP addresses.  Temp IPv6 addresses aren't registered into DNS, and so pfsense has no way to know what the temp IPv6 address is.  As a result, pfsense has no idea it should allow traffic from that temp IPv6 address.

              How to deal with the situation:  To make things work with existing pfsense, you'll have to disable the generation of temporary IPv6 addresses on awesome-dude.  If all your clients use DHCPv6 and/or register their IPv6 addresses with DNS, that will allow things to work.  However, any clients that use IPv6 SLAAC (which includes 100% of all android devices) likely don't register their IPv6 addresses with DNS.

              One alternative would be to generate code that uses ARP and NDP to try and match any NDP seen IPv6 addresses with MAC addresses from ARP. 
              Then insert those seen IPv6 addresses into whatever DNS resolver your using.  Of course, then you'd ALSO have to get pfsense to re-generate it's alias table any time the list of ipv6 addresses changes for a given MAC address.  (I've written code that does some of this, and it's NOT as easy as it sounds... and doesn't work quickly enough to help.)

              Another alternative would be to use a L2 firewall instead of pf.  The L2 firewall could allow/block/reject based on MAC addresses.  I saw something somewhere on this forum a while ago that allowed doing that (though I think it was used to block, and not to allow.  I don't know if it could be used to override a default "deny all" pf rule.)

              Firstly, thank you for such an excellent post and for taking the time to type it up.

              What you described is EXACTLY the issue I am experiencing.

              So what I tried after reading your post is the following on my Windows 10 box:

              netsh interface ipv6 set privacy state=disabled
              netsh interface ipv6 set global randomizeidentifiers=disabled

              and then rebooted. This disabled the temporary IPv6 address assigned to the NIC and disabled a randomly generated IPv6 address. The IPv6 address generated uses the MAC address so I assume it'll always stay the same.

              After clearing out the cached DNS entries and clearing my browser cache…voila! I can now connect to my pfsense webgui using IPv6 without any delays and the firewall rule works using my Win10 hostname as the source in the firewall rule.

              Obviously I lose out on the "privacy" IPv6 address assigned to my machine that changed daily but I tihnk I can live with that. IPv6 is kinda strange in some ways compared to IPv4 but thanks for helping me solve this!

              1 Reply Last reply Reply Quote 0
              • J
                johnpoz LAYER 8 Global Moderator
                last edited by Feb 23, 2017, 9:09 PM

                "IPv6 is kinda strange in some ways compared to IPv4"

                Understatement of the week ;)

                An intelligent man is sometimes forced to be drunk to spend time with his fools
                If you get confused: Listen to the Music Play
                Please don't Chat/PM me for help, unless mod related
                SG-4860 24.11 | Lab VMs 2.7.2, 24.11

                1 Reply Last reply Reply Quote 0
                • G
                  garyd9
                  last edited by Feb 24, 2017, 12:32 AM

                  @zarje:

                  IPv6 is kinda strange in some ways compared to IPv4 but thanks for helping me solve this!

                  Is it that IPv6 is kind of strange compared to IPv4, or that IPv4 made us think of things in a strange way? ;)

                  In a LOT of ways, IPv6 makes much more sense to me than IPv4.  You have an interface.  It has it's own address in the world.  Nothing else has that address.  It's kind of like your physical home mailing address.

                  Compare that to IPv4 and "192.168.1.1".  I bet there are more interfaces in the world with that single address than there are unique IPv4 numbers.  That would be like trying to send something via the ground postal service addressed to only "over there."

                  In my opinion, IPv4 required so many hacks (and they are hacks) to make things work how we want, that we've grown accustomed to those hacks, and now we try to apply those same ideas to IPv6 where they aren't needed (and don't work.)

                  I still believe that a proper daemon with kernel hooks could monitor ICMPv6 to watch for the MAC addresses of devices that announce usage of an IPv6 address (via ICMPv6 NDP NA and NS messages) and somehow use that information along with ARP and reverse DNS lookups to find the hostname of every used IPv6 on a local network.

                  In fact, I had written something like that (and injected the information into unbound's config files) but it wasn't a daemon that monitored ICMPv6, but instead just ran every 30 minutes or so.  In that time, many IPv6 addresses would expire from the NDP table, or the IPv6 would expire very quickly after I logged it (but before the process ran again to clean up the data.)  I'll admit that I had a few other bugs, but because of the above issues, I abandoned my effort.  It was a fun exercise and I proved to myself that it was feasible.

                  As others pointed out to me, even if I had perfected the program, it STILL would suffer from some flaws due to some devices apparently randomizing their MAC addresses!  (I haven't seen that in my home or work, but I believe others who say it's done.)  It also couldn't ever recognize an IPv6 address if it never sees the address to begin with.  (Of course, if it never sees the address, then there isn't any traffic using the address, so it really doesn't matter.)

                  Oh, and even with the above program, assuming it was working PERFECTLY, you'd still be experiencing the same problem (because pfsense refreshes it's alias tables on a schedule… so it might take quite a bit of time before it'd notice a new ipv6 address associates with a given hostname.)

                  However, ALL that being said...  pfsense is still one of the better router/firewall/UTM type programs for dealing with IPv6.  Most others either completely ignore that IPv6 exists, or they have barely half-baked hacks that kind of support very specific cases of IPv6 (such as only supporting static IPv6 /128 addresses)

                  (Can you tell that I'm passionate about this subject? ;))

                  Take care
                  Gary

                  1 Reply Last reply Reply Quote 1
                  1 out of 8
                  • First post
                    1/8
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                    This community forum collects and processes your personal information.
                    consent.not_received