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

    DHCP v6 - no route to host

    Scheduled Pinned Locked Moved IPv6
    51 Posts 4 Posters 35.6k 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
      MrKoen
      last edited by

      Might be work in progress, but works very well already :) I found out that deleting the existing /var/dhcpd/var/db/dhcpd6.leases file on my system and restarting the dhcpd service solved the problem of the dhcpd service only staying active for a few requests. It did give my quite some errors after restarting the dhcpd service the first time, but now it's up and running for two days already and still providing IPv6 addresses according to both the pool addresses and the configured reservations. So its almost perfect now.

      I'm still wondering how I can solve the problem where the clients assign a /128 route to the assigned IPv6 address thus sending all IPv6 traffic via the pfSense firewall which is the default gateway. For IPv6 traffic on my local LAN this causes a lot of problems. Remote desktops from one machine to another for example will go over IPv6 by default but pfSense will drop a few packets every now and then causing the remote desktop to freeze. These dropped packets are logged by pfSense. When connecting to the same client using its local IPv4 address, it works well. If I could just get it to assign a /64 in the routing table on the client the problem would be solved. Anyone got a clue how to get this done?

      1 Reply Last reply Reply Quote 0
      • D
        databeestje
        last edited by

        https://lists.isc.org/pipermail/dhcp-users/2010-January/010810.html

        1 Reply Last reply Reply Quote 0
        • M
          MrKoen
          last edited by

          Sounds like exactly the problem I was facing. Same errors and outcome. As stated above, for me it was solved by deleting the leases file and having dhcpd create a new one. Its still happily providing IPv6 leases now after being up for 2,5 day already.

          1 Reply Last reply Reply Quote 0
          • D
            databeestje
            last edited by

            Currently importing isc dhcpd 4.2.1-P1

            1 Reply Last reply Reply Quote 0
            • M
              MrKoen
              last edited by

              Cool :) Do you have a clue how I could have the DHCPv6 leases set to /64 in the clients routing table?

              1 Reply Last reply Reply Quote 0
              • D
                databeestje
                last edited by

                not yet, open for options. new snapshots on my site with the new dhcpd

                1 Reply Last reply Reply Quote 0
                • M
                  MrKoen
                  last edited by

                  Hmm.. isn't this a thing that rtadvd should provide? My knowledge about IPv6 isn't sufficient to know if router advertisements should provide this, but it sounds logical. I'll do some searches on the internet to find out more about this.

                  1 Reply Last reply Reply Quote 0
                  • M
                    MrKoen
                    last edited by

                    I found a statement in RFC4862 on page 8 which to me sounds like the router advertisement should indeed provide the cidr block by providing an address prefix. I quote:

                    Router Advertisements also contain zero or more Prefix Information
                      options that contain information used by stateless address
                      autoconfiguration to generate global addresses.  It should be noted
                      that a host may use both stateless address autoconfiguration and
                      DHCPv6 simultaneously.  One Prefix Information option field, the
                      "autonomous address-configuration flag", indicates whether or not the
                      option even applies to stateless autoconfiguration.  If it does,
                      additional option fields contain a subnet prefix, together with
                      lifetime values, indicating how long addresses created from the
                      prefix remain preferred and valid.

                    I remember seeing the cidr notation in the rta config before. I'll check out the rtadvd man pages for more info.

                    1 Reply Last reply Reply Quote 0
                    • M
                      MrKoen
                      last edited by

                      I see you already got this stuff included in the /var/etc/rtadvd.conf file and it looks fine. Hmm. What could it be.

                      1 Reply Last reply Reply Quote 0
                      • D
                        databeestje
                        last edited by

                        it appears to be a issue with a combination of the dhcp server and the client.

                        I've upgraded the dhcp server to 4.2, that should fix the issue with the dhcp leases file. Maybe i'm missing a option I need to send that carries the prefix length.

                        More work soon, I have a family issue that I find far more important then IPv6 atm.

                        1 Reply Last reply Reply Quote 0
                        • M
                          MrKoen
                          last edited by

                          Without a doubt Databeestje. Good luck solving the family issue.

                          I'll play with it some more to see if I can perhaps find something. I will share any possible findings in this topic.

                          1 Reply Last reply Reply Quote 0
                          • M
                            MrKoen
                            last edited by

                            I just updated my pfSense to the latest AMD64 release and gitsynced with the latest Smos updates. I now notice that my interfaces having the DHCPv6 service enabled (router advertisements set to Assisted - if this matters) will first at boot have their static IPv6 addresses assigned, but seconds after done booting they will acquire an IPv6 lease from the DHCPv6 service themselves. Interfaces not having the DHCPv6 service enabled stay with their configured static leases. To correct this, I go go the interface configuration page, don't change anything, press Save and after that Apply changes and the static IPv6 address is back again. I guess this is a thing for the todo list whenever you find time for it.

                            I'll continue to see if I can find something to change the /128 cidr notation on provided IPv6 leases.

                            1 Reply Last reply Reply Quote 0
                            • D
                              databeestje
                              last edited by

                              if there is 1 interface that has dhcp enabled I toggle the allow router advertisements sysctl. Problem is that it is not a per interface, but a global.

                              Thus pfSense receives it's own advertisement. That wasn't supposed to happen. There should have been a few new arguments I could pass to ifconfig to enable or disable those.

                              Needs more work.

                              1 Reply Last reply Reply Quote 0
                              • M
                                MrKoen
                                last edited by

                                I think I might have found a solution to the /128 problem on DHCPv6 leases. If you remove the following parameter from the /var/etc/rtadvd.conf config file, it does work as expected and it does register a /64 route on the provided DHCPv6 address:

                                :pinfoflags#64

                                My working config:

                                common definitions.

                                default:
                                       :raflags#0:rltime#3600:
                                       :vltime#360000:pltime#360000:mtu#1500:
                                ether:
                                       :mtu#1280:tc=default:

                                Generated for DHCPv6 Server lan

                                em0:
                                :addr="2001:470:1:1:0:0:0:0":
                                :prefixlen#64:
                                :raflags="mo":
                                :tc=ether:

                                Generated for DHCPv6 Server opt1

                                em0_vlan3:
                                :addr="2001:470:1:2:0:0:0:0":
                                :prefixlen#64:
                                :raflags="mo":
                                :tc=ether:

                                With this config, I do get assigned an address in the 2001:470:1:1/64 range on my em0 interface and an address in the 2001:470:1:2/64 range on my em0_vlan3 interface. Clients on both interfaces now do register a /64 route in the routing table.

                                /edit: some additional info

                                I test this by going to the console and executing the "killall -9 rtadvd" command. Next I edit the /var/etc/rtadvd.conf file taking out the :pinfoflags#64 and leave all else as is. Then on the console I run "rtadvd -d -D -c /var/etc/rtadvd.conf em0 em0_vlan3". On my Windows 7 client I run the following command "ipconfig /release6 | ipconfig /renew6" and after that I run "route print". I now see the default gateway being registered at its fe80 link local address and an On-link registration for 2001:470:1:1::/64.

                                :D

                                1 Reply Last reply Reply Quote 0
                                • M
                                  MrKoen
                                  last edited by

                                  Just gitsynced with the new gitsync hub. I notice the DHCPv6 service is no longer working. In the DHCP logs I find many of these errors:

                                  dhcpd: dhcpv6: send_packet6() sent -1 of 120 bytes
                                  dhcpd: send_packet6: Operation not permitted

                                  Any clues to what could be wrong this time?

                                  1 Reply Last reply Reply Quote 0
                                  • W
                                    wallabybob
                                    last edited by

                                    The interface dhcpd is using has a link local (fe80::…) IPv6 address? http://forum.pfsense.org/index.php/topic,37079.0.html might be relevant.

                                    1 Reply Last reply Reply Quote 0
                                    • M
                                      MrKoen
                                      last edited by

                                      Yes it is. This is my ifconfig output:

                                      ifconfig em0
                                      em0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
                                              options=1209b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,vlan_hwfilter>ether 00:ff:ff:51:00:01
                                              inet6 fe80::225:90ff:fe34:bfae%em0 prefixlen 64 scopeid 0x1
                                              inet 192.168.xxx.1 netmask 0xffffff00 broadcast 192.168.51.255
                                              inet6 2001:470:xxx:xxx::1 prefixlen 64
                                              nd6 options=3 <performnud,accept_rtadv>media: Ethernet autoselect (1000baseT <full-duplex>)
                                              status: active</full-duplex></performnud,accept_rtadv></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,vlan_hwfilter></up,broadcast,running,simplex,multicast>

                                      I gitsynced against the latest version, so what you're describing in your topic should also be included with that version. I finally had the DHCPv6 thing to work and now its broken again. Humpf :) Any other clues to what it could be? The RTADVD announcements work well. When the machine times out querying for a DHCPv6 address, it will auto generate one in the proper subnet with the proper route and proper gateway.

                                      1 Reply Last reply Reply Quote 0
                                      • W
                                        wallabybob
                                        last edited by

                                        @Koen:

                                        Yes it is. This is my ifconfig output:

                                        ifconfig em0
                                        em0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
                                                options=1209b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,vlan_hwfilter>ether 00:ff:ff:51:00:01
                                                inet6 fe80::225:90ff:fe34:bfae%em0 prefixlen 64 scopeid 0x1
                                                inet 192.168.xxx.1 netmask 0xffffff00 broadcast 192.168.51.255
                                                inet6 2001:470:xxx:xxx::1 prefixlen 64
                                                nd6 options=3 <performnud,accept_rtadv>media: Ethernet autoselect (1000baseT <full-duplex>)
                                                status: active</full-duplex></performnud,accept_rtadv></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,vlan_hwfilter></up,broadcast,running,simplex,multicast>

                                        I gitsynced against the latest version, so what you're describing in your topic should also be included with that version.

                                        Yes, but that should have been relevant only on bridges because they don't automatically create an IPv6 link local address from their generated MAC address. (My LAN interface is bridge0).

                                        I notice that your em0 interface has a link local IPv6 address that seems totally unrelated to the reported MAC address. This doesn't seem right but I don't know if it is relevant.

                                        On my system vr0 is a member of bridge0, the LAN interface. Notice the relationship between MAC address and IPv6 link local address:

                                        ifconfig vr0

                                        vr0: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
                                        options=82808 <vlan_mtu,wol_ucast,wol_magic,linkstate>ether 00:30:18:b0:19:48
                                        inet6 fe80::230:18ff:feb0:1948%vr0 prefixlen 64 scopeid 0x3
                                        nd6 options=3 <performnud,accept_rtadv>media: Ethernet autoselect (100baseTX <full-duplex>)
                                        status: active
                                        #</full-duplex></performnud,accept_rtadv></vlan_mtu,wol_ucast,wol_magic,linkstate></up,broadcast,running,promisc,simplex,multicast>

                                        1 Reply Last reply Reply Quote 0
                                        • M
                                          MrKoen
                                          last edited by

                                          This might be because I have spoofed my WAN side MAC address. The "official" MAC address can be noted in the fe80 address. It has been like that for a while already, so don't think that will be the problem.

                                          Does the DHCPv6 service work correctly at your installation? Would you mind comparing settings to see if something is different there?

                                          My DHCPv6 settings are (/services_dhcpv6.php):

                                          Router Advertisements: Assisted
                                          Enable DHCPV6 server on LAN interface: Checked
                                          Deny unknown clients: Not checked
                                          Subnet: 2001:470:xxx:xxx:0:0:0:0
                                          Subnet mask: 64 bits
                                          Available range: 2001:470:xxx:xxx:0:0:0:1 - 2001:470:xxx:xxx:ffff:ffff:ffff:ffff
                                          Range: 2001:470:xxx:xxx::1000 to 2001:470:xxx:xxx::1050
                                          Prefix Delegation Range: <empty>to <empty>prefix length 48
                                          DNS servers: 2001:470:xxx:xxx::20 and 2001:1af8:xxx:xxx:2::1001
                                          Gateway: 2001:470:xxx:xxx::1
                                          Domain name: home.networks.zomers.eu
                                          Domain search list: <empty>Default lease time: <empty>Maximum lease time: <empty>Failover peer IP: <empty>All of the Advanced options are also emtpy.
                                          No additional BOOTP/DHCP options.

                                          I do use static DUID/IPv6 mappings.</empty></empty></empty></empty></empty></empty>

                                          1 Reply Last reply Reply Quote 0
                                          • M
                                            MrKoen
                                            last edited by

                                            I have found the problem! I accidentally added the fe80::/16 range to the EasyRuleBlockHostsLAN alias to avoid my pfSense logs being swamped with local traffic. This caused these packets to be blocked thus the errors to be generated. I have removed the fe80::/16 range from the alias and the problem went away. DHCPv6 and static mappings are working smoothly now :D

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