@johnpoz:

"the provider actively blocks 6in4 on their RGs"

So they are blocking protocol 41?  You ask them this and they gave you reason why?  This is AT&T

http://www.dslreports.com/forum/r30137020-AT-T-U-Verse-Protocol-41-IPv6-Net-Neutrality-Complaint-with-FCC

What equipment do you have from them?

I've got a Pace 5268AC.  Disappointingly, there is native v6 available, but it doesn't support the /60 they hand out when you use it in DMZ+ (with pfSense).

I've thought about filing a net neutrality complaint, but I can likely see them citing security issues with allowing 6in4.  Based on my research, they either deny or act confounded when asked (or served).

I called the support line and advised them.  They said IPv6 isn't officially supported yet, so there may still be issues.  They said they'd forward my probelm to the appropriate people.  Hopefully, it's just a teething problem that will be resolved shortly.  At least the person I was talking to knew what the DUID was and what it's supposed to do.

Actually, they are real, public addresses, every one of them.  It's up to your firewall to keep them "private".  Any IPv6 address that starts with a 2 or 3, in the first digit, is a public (global) address.

No. You always want to filter on the interface the traffic enters.

You can't manage traffic entering GIF on the LAN tab, a floating rule outbound on LAN maybe, but why would you want to let traffic enter the firewall before blocking it? Block it at the GIF interface. You do have to assign the GIF interface first so it gets its own firewall tab, if you haven't already.

So much of the ipV6 talk presupposes subnets smaller than /64 are in the category of 'error' it just never occurred to me an ISP would expect it.

Hi,

It is possible my problem is due to bugs already logged. I checked out https://redmine.pfsense.org/issues/6717 and https://redmine.pfsense.org/issues/6541

Yes your pfSense get the "Kundennetz/WAN" Subnet on the WAN interface and the "Kundennetz/Lan"/56 on all other interfaces splitted as /64.

You configured Track Interface(WAN) on the other Interfaces? And dont forgett to reboot.

…and based on the cause listed in the previous message, the solution is to go into Interfaces->WAN, scroll down to "DHCP Client Configuration" and add your cable modem's IP address to the "Reject leases from" field.

The IP address of the cable modem depends on the specific hardware.  For nearly all Motorola/Arris modems, it'll be "192.168.100.1".

You can figure it out if you examine the "dhcp" logs in pfsense after a reboot of the modem.  It'll be the IP address listed as the DHCP server assigning pfSense an IPv4 before the modem is completely rebooted.

That sounds plausible but we have "router solicitation" and that article is about "neighbor discovery"
Will look deeper into that.

I contacted the engineer at my ISP for clarification about the "UUID". It was a typo. He said their gateways use LL, but they tested EN and LLT. I think having an option to preserve LLT and enable it to be entered as a configuration parameter would be useful for situations where preservation of prefix is based on consistent DUID.

How do I set this up on the pfsense side?
Thank you.

Little bit awkward to answer my own question.

Here's a short howto for FreeIPA and pfsense:

For the specific zone in Freeipa Settings make sure "Dynamic update" is set to: true generate key, me using srvxxx.my.domain dnssec-keygen -a HMAC-MD5 -b 512 -n HOST srvxxx.my.domain

Open generate *.private file and copy the Key in the line that starts with Key:
3) On all FreeIPA hosts in replication edit /etc/named.conf by adding

include "/etc/named.srvxxx.key"; On all FreeIPA write file /etc/named.srvxxx.key key "srvxxx.my.domain" {       algorithm hmac-md5;       secret "your_key_from_2)"; }; restart ipa via```
ipactl restart You can add this for DHCP server if you like also for DHCPv6 server. Unfortunately the updates are being refused. I think the grant statement is not just right. I'll update this post if I get it resolved.

I'm guessing that the global address is used because a downstream IPv6 router could pick the RDNSS entry up and re-use it for its own LAN, this won't work if the address is a link-local address because the address wouldn't be reachable outside the original LAN.

In my case, I don't have any routers downstream.

Thanks,
Chris.

@JKnott:

In the case of my ISP (Telus), their edge router does not allocate such an address. Their gateway allocates its global WAN address in prefix+ff/64, using RFC 2464.

Are you using both pfSense and their modem in gateway mode?  If so, put the modem in bridge mode and use pfSense for your firewall.  pfSense is expecting to be assigned a prefix.  But the modem, in gateway mode, is taking that prefix.  I'm on Rogers and have a Hitron cable modem.  It's configured in bridge mode and I have a computer running pfSense as my firewall/router.

No, that's not what's happening. The modem is in bridged mode. (Actually one port is bridged, not the entire modem.) pfSense is getting its own prefix. It's working perfectly, albeit using the "dhcp before RA" patches. (FYI, I'm running two pfSense VMs on the server, each getting its own prefix.)

That's interesting.
No it isn't. In Dual Stack IPv6 connectivity never may rely on any IPv4 configuration parameter, ever.
Fritzboxes have been acting strange with IPv6 for some time now. There is a quite recent (german) article linking to some issues by heise in c't 10/2016. Your issue isn't in there.
This need to be examined in more detail. Try Wireshark or something and make more sense of the Neighbor Discovery packages (ICMP6).

https://redmine.pfsense.org/issues/6667

Instead of manually copying the file to /conf, you could install the cron package and back up the duid file every hour.  Because the file shouldn't change once created, and performing all kinds of extra writes to a CF or SSD is A Bad Thing, I use "-n" (no clobber) to make the backup.

I have the following cron job:

*  */1  *  *  *  root  /bin/cp -n /var/db/dhcp6c_duid /conf/dhcp6c_duid

…and the shellcmd setting (copying from /conf/ instead of from /conf/dhcp/) above.

(This should be improved to use "cp -f" if the timestamp of the copy in /var is newer than the backup.  In most linux distros, the "-u" parameter to cp would take care of that, but I don't see an equivalent in freebsd cp.)

The whole idea is that a user could still manually delete the duid file if they needed to "fix" a broken duid (or get a new lease or something.)  If that happens, you'd want a new backup taken.  If DUID changes, update the backup.  Else, don't write to it.

Of course, it'd be better still if backing up the duid file was incorporated into the scripts that backup (and restore) the dhcp leases automatically.

Thanks for the reply!