strange thing this dhcpv6..

lost the reservation again.

Thanks to /dev/null for pointing me in the right direction, based on his notes I was able to get it working.

This thread had the solution:

https://forum.pfsense.org/index.php?topic=90699.msg508549#msg508549

I had to setup the prefix delegation in the advanced section on the WAN page

send options: ia-pd 0

prefix delegation: checked

That was all that was required. I originally tried the options /dev/null provided but it didn't work. Once I cleared the fields so it was like the screenshot c0re had in the other post it worked straight away. Even after rebooting the pfSense box in continued to work OK.

Frustrating how it all works though.

It's been brought up in several places on the forum already. It's actually a Chrome bug.

You can use the System Patches package to apply https://patch-diff.githubusercontent.com/raw/pfsense/pfsense/pull/3127.patch which will allow the validation to work with the latest Chrome. The Chrome regex parser has a bug in that it does not allow escaped characters inside a list, even though it is a valid – but not required -- regex expression.

Because that /112 (which isn't a real /112, it's a shared /64 where i'm simply only allowed to use /112 without it being an actual subnet) is the dynamic standard for single-server-single-link in their provisioning system,

That makes more sense.  They give you a 65K block of addresses and you're supposed to do a static config or possibly mapped DHCP for your systems.  That means there could be 2^48 other systems in there sharing that /64.  ;)

You have to switch to non aiccu mode.

Hi everyone, just an update regarding this issue.  I posted in a Teksavvy dslreports forum about the issue I'd been having and got some interesting feedback.  They recommended allowing IPv6 ICMP packets to hit the WAN interface of the firewall.  After doing this, my IPv6 connectivity to my LAN has remained constant and is at 5 days straight now vs losing it after 2 days.  So either something has changed on the Teksavvy side to monitor the CPE/FW of their customers to ensure that the DHCP /56 that is handed out is still valid and should stay in their routing tables vs removing it.  Or something on the pfsense configuration changed in that Teksavvy is no longer able to tell whether the FW is alive or not via some kind of ND or whatever.  This started about a year ago so it's not something recent.  Others seem to have experienced similar problems with one person using a cron job to reset the DHCP6 session nightly.

I'll post back if things change and I lose connectivity again.

LoboTiger

@rancid-lemon:

@bimmerdriver:

@rancid-lemon:

I tried to install patch 3102 for this issue, but I run into a 'this patch can't be applied cleanly' error.

Can anyone advise how to install on 2.3.2?

PR 3102 hasn't been backported to 2.3.2 (yet, I hope). If you want to run the patches, you need to run the development snapshot. I'm running PRs 3102/1, 3102/2, 3103, 3105, 3106 and 3107 and they are working quite well. The only patches that are specifically for the RA issue are 3102/1 and 3102/2. The rest are for dhcp6. Refer to https://redmine.pfsense.org/issues/5993 and https://github.com/pfsense/pfsense/pulls. The shapshot already has an earlier version of the fix, so it should get a prefix even without the PRs.

Understood, thank you for the explanation. I will give the snapshot a go and see how I get on before installing the patches, will keep an eye on this thread too.

In case you didn't notice, if you upgrade to the latest 2.3.3 development snapshot, all of the pertinent patches have already been merged.

You're not missing it. It's not supported. I believe it should be, however. If you want to set up a reservation for a host, such as a laptop, with wifi and wired interfaces, it's needed to prevent an address clash.

@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.