DHCP v6 - no route to host
-
One more question.. I notice that when getting an DHCPv6 address from pfSense (either a static reservation or pool address), my Windows 7 x64 client will add a route to the routing table like this:
2001:470:-removed-:51::1111/128
Meaning.. all data between hosts on my local 2001:470:-removed-:51::/64 subnet will be routed to the default IPv6 gateway being pfSense. This brings extra unnecessary load on pfSense and causes the pfSense logs to be filled with entries regarding my local IPv6 traffic. Is it possible to have the clients designate a /64 route to the assigned IPv6 address?
Another question.. what is the IPv6 Prefix Pool field for in a DCHPv6 reservation?
Last thing.. don't forget to put updating /status_dhcpv6_leases.php on the todo list. It does show the leases, but not the IPv6 addresses, still shows a column MAC address instead of DUID and does not allow for pool leases to be translated to a reservation.
-
I was playing with the IPv6 Prefix Pool field and apparently it can kill whole pfSense. I now know why I didn't see the error during boot on the interfaces.inc file anymore. It only appears when having this field set and if so, it will kill the WAN interface completely. I caught the error. Check the attached screenshot. The error points to this section in the interfaces.inc file:
/* Setup the prefix delegation */
foreach($IfList as $pdinterface => $friendly) {
if(is_numeric($interface['ia-pd'])) {
$realif = get_real_interface($friendly);
$dhcp6cconf .= " prefix-interface {$realif} {\n";
$dhcp6cconf .= " sla-id {$interface['ia-pd']};\n";
$dhcp6cconf .= " sla-len {$config['interface'][$interface]['dhcp-ia-pd-len']};\n";
$dhcp6cconf .= " };\n";
}
}I removed this block completely from the interfaces.inc file, rebooted pfSense and now I have a working pfSense installation again. So there is a bug in this block that kills the WAN interface.
-
I also just found out that the DHCPv6 service is still very unstable. After a couple of successful DHCPv6 requests, it will stop responding to DHCPv6 requests. Restarting the dhcpd service will get it going again for a few requests. No errors logged though, so probably very difficult to trace to the cause.
-
The dhcp support is still very much a work in progress. The prefix pool setting for the dhcp client static mapping is for dhcp-pd support. This is what preactically the world will use for deploying IPv6 to end users.
You can save the prefix pool but is not used anywhere yet. That will come later. I need to BBQ first.
-
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?
-
https://lists.isc.org/pipermail/dhcp-users/2010-January/010810.html
-
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.
-
Currently importing isc dhcpd 4.2.1-P1
-
Cool :) Do you have a clue how I could have the DHCPv6 leases set to /64 in the clients routing table?
-
not yet, open for options. new snapshots on my site with the new dhcpd
-
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.
-
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.
-
I see you already got this stuff included in the /var/etc/rtadvd.conf file and it looks fine. Hmm. What could it be.
-
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.
-
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.
-
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.
-
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.
-
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
-
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 permittedAny clues to what could be wrong this time?
-
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.