@bigtfromaz said in DDNS pfSense to Windows AD DNS DHCPv6: I am in the software and services business and we have begun running into situations where some client host machines only have IPv6 because their ISPs have run out of IPv4 addresses. That means the only way they can reach my servers is via IPv6. There aren't many and they are non-US but they are important. It's probably time for the industry to switch to an IPv6-first stance (Apple and Google seem to be there already). Given the absence of vigorous competition in my area, the ISPs are putting themselves before their customers. I am betting it's a common theme. Thanks for the heads-up regarding the lack of fair play by Netflix. It's probably due to the fact that they have restricted distribution rights for content and can't be sure of your location. You could probably work around that with a guest VLAN having no IPv6. Kids are really good at getting and spreading computer viruses. A guest VLAN would help you minimize your risk. I am going to see if I can get the addresses registered in a DNS server on the pfSense and replicate to my Windows AD Server. If I write some code that turns out to be useful I'll put it on GitHub and share a link here. Yeah, there are several avenues to deal with the IPv6 and Netflix thing, but the kids are only here rarely and I have plenty of IDS/IPS protections for critical stuff. Also, it's only a home network. There are no national defense secrets, Democratic National Committee emails, or documents relating to secret payoffs to porn stars stored here ... LOL. And yes, Netflix blocks HE IPv6 blocks for precisely the reason you stated: users without strict morals use those to get around geoip blocks that Netflix has in place to enforce their distribution contracts with content owners. I wish all the ISPs of the world would just start supporting IPv6. Unfortunately that appears to be a very slow process. Even some of those that are supporting it are doing so in strange ways. They seem to be doing their darndest to avoid giving out static IPv6 addresses, for instance.

Even if your ISP doesn't provide IPv6, you can still have it, using a tunnel from hurricane electric. They are free, they perform well, they are very reliable and they work. I used one for years before my ISP implemented IPv6. There are lots people here who can help you set it up.

Ok, so the final update, I have everything fixed now (at least till now) So the final trick is to set my switch to tag port 5-8 which connect to my 4 APs apparently the tp-link APs will receice packages on it's selected wirelss VLAN + anything that's untagged (without vlan header) after change my switch to tag vlan1 on port 5-8 it ensures all the vlan1 tag won't be removed when outbound the port, which fixes the RA flood issue. Thanks everyone for the help

Solved by enabling " Enable Forwarding Mode"

This seems connected to this issue https://forum.netgate.com/topic/114786/pppoe-disconnects-requiring-reboot/2

See if using a scheme like this using both ULA and GUA-PD on the inside interfaces helps with that sort of problem. That is the recommended way to operate when an ISP insists on changing the PD. https://forum.netgate.com/post/825770 If that doesn't help you'll need to post specific details as to exactly what the ISP is doing and exactly what is causing your problems. Not a description, but screen shots and real, actual troubleshooting output. https://www.ripe.net/publications/docs/ripe-690#5--end-user-ipv6-prefix-assignment--persistent-vs-non-persistent Note that's RIPE - as in Europe. So it's their own RIR telling them they're doing it wrong, too. RFC7368 is about as close as we have to a controlling document here. https://tools.ietf.org/html/rfc7368 ULAs should be used within the scope of a homenet to support stable routing and connectivity between subnets and hosts regardless of whether a globally unique ISP-provided prefix is available. In the case of a prolonged external connectivity outage, ULAs allow internal operations across routed subnets to continue. ULA addresses also allow constrained devices to create permanent relationships between IPv6 addresses, e.g., from a wall controller to a lamp, where symbolic host names would require additional non-volatile memory, and updating global prefixes in sleeping devices might also be problematic.

So what does the config on pfSense look like vs your external server config? There must be some difference in the formatting or naming of the option to explain what is happening. Look in /var/dhcpd/etc/dhcpdv6.conf

You need to push the IPv6 /64 as a route. It needs to be distinct from the tunnel network. I assume you have more than a /64 to use? /48 or /56? Similar to how HE's TunnelBroker provides IPs, Unfortunately TunnelBroker does not work in this case because they Block CloudFlare (YES THEY FREAKING BLOCK CLOUDFLARE!!!). Based on my experiences with HE over the years, if they did in fact block these sources, they have a good reason for doing so.

Additional noteworthy observations. There was one strange thing about GIF configuration on pfSense 2.4.3 (and before?). I had to disable Outer Source Filtering on gif0 for the traffic to flow — otherwise even gateway monitoring pings were discarded upon reception: that is, if I remember correctly, ping replies were received on parent interface but rejected at GIF level. Those ping replies had proper source and destination addresses for both IPv4 and IPv6 and came in via proper interface. Of course, the IPv6 network for GIF tunnel itself was not the same as for overlaid network — but that is the case for all tunnels of all brokers. In particular, gif2 to the same broker was functioning well with Outer Source Filtering enabled by default, as well as gif1 to another broker. Right before upgrading from 2.4.3 to 2.4.4, I noticed that gif2 also needs disabling Outer Source Filtering. I had no idea on why this happened and how long ago — just switched the offending setting, and the tunnel became operational for about a couple of hours until the update took place. Same as earlier, however, gif1 to another broker was functioning with Outer Source Filtering enabled by default, and used proper parent interface even after upgrading to pfSense 2.4.4. Now that pfSense 2.4.4 is installed, I tried switching Outer Source Filtering back on and then off again — just in case — but observed no effect. That was expected indeed, as the primary issue is not with ingress filtering on local side: outgoing traffic is filtered by remote end because of improper source addresses caused by improper parent interface being used. I also tried Disable Gateway Monitoring for both gateways corresponding to gif0 and gif2. That allowed the traffic to flow out unconditionally, but only showed that any kind of traffic — not just ICMP pings — chose wrong parent interface. I once again tried changing default gateway settings, and the outcome was equally negligible. That is, sometimes I saw small bursts of legitimate traffic pass out and then in (such as my NTP server making a request and receiving a reply), but it is hard to correlate to settings change as those bursts stop soon. The other times I see legitimate inbound traffic entering proper parent interface, but somehow filtered on local side — such as incoming NTP and DNS requests with no reply from my home server [because pfSense filtered those requests out]. :puzzled:

@Norris : Pouvez vous cesser de poster ce type de message qui ne servent à rien ?

Yes, JKnott, I do have "do not allow PD Address release" checked. And you're right, there is no control over what the ISP will actually do. I think the addresses had been the same for about 2 months but it seems like a power cycle of the modem is what triggered the IP change. pfSense had little control over it. I'm actually on the phone with Comcast Xfinity now, it's taken 1h22m to get to a supervisor. Seems I've been talking a foreign language to both reps I've talked to so far. How hard is it to get a static /60 - /48 on an account? :) I'm currently finding out. It's not like I'm asking for a static IPv4, I'm not even bothering with that. ...and after the call, Comcast Xfinity confirmed they still don't hand out/sell IPv6 blocks to Residential customers. So it is what it is. Would it be a fair (acceptable?) compromise to only run DNS lookups over IPv4? It looks like if I reorder my IPv4 DNS servers System -> General to place my DCs IPv4 addresses at the top of the list (with no outside interface assigned to it), then remove the RA & DHCPv6 DNS servers - the pfSense DHCPv6 server will assign out its own IPv6 per-interface address as a DNS server, and proxy the replies from the servers, in sequence, from Settings -> General. Seems to do away with the need for a DNS forwarder, which also seems to be IPv6-dependent (i.e. only take IPv6 addresses).

It's also been in Linux for a while.

How many hours of work... Seems like quite a few to me.. So unless you get lucky and someone writes it up for their own use and shares it. You have to provide enough incentive for someone to do all the work. $100 at best at best cover an hour worth of work - this is clearly more than 1 hour to implement, etc.

They are running out of IPv4 rfc1918 space because they choose to do so.. Plain and simple! Sure some devices might need to talk to each other.. Not ALL of them!! And if need be they can nat, etc. etc.. Sorry but they are touting their move to ipv6 like they are doing something innovative.. And they are using it as marketing.. they don't NEED to move to it.. Which is GREAT... But don't tell me you "have to" because your out of rfc1918 space. And to be honest here is the big problem with the eventual migration... Is once you move part of the network to IPv6.. That frees up lots of IPv4 that can be used now.. For example could their management vlans on Ipv6, they could put their storage vlans on IPv6, they could put xyz on IPv6, etc etc.. This frees up LOTS of address space to use where its needed, etc.