@Cathal1201 said in IPv6 Policy Routing and OpenVPN:

Delete for testing the source and test it. When it works, "HOUSEVLAN net" delivers the wrong IPv6 Net.

What do you mean?

Configure "*" as Source and not "HOUSEVLAN net", test it. If it works, Problem is within "HOUSEVLAN Net". If not, rewind it back to "HOUSEVLAN net".

Link Local are often use to route, but that is not that clear to me as I could explain it to you.

Try this first:
Ok, think about the Gateway. Did it know, where the network of your desktop is? You reach Opt1 because pfsense is your default gateway. You reach OPT1_VPNV6 from OPT1 because its the same network. You reach OPT1_VPNV6 from desktop because your default gateway knows the OPT1_VPNV6 Network, BUT OPT1_VPNV6 don't know about the Network of your desktop. The answer is send to gateways default gateway. This is often the problem with IPv4 and I guess it is IPv6 too.

@Derelict Thanks for quickly pointing out my error.

I reconfigured the DHCPv6 server address range as suggested. So far it seems to be more reliable at getting an IPv6 address from the cable modem after a reboot of pfSense, but only experience over a number of weeks will tell for sure.

I have noticed that pfSense boots up and receives an IPv4 address immediately. The IPv6 addresses for the WAN, LAN, and devices on the LAN take a good 3 - 4 minutes to appear. Which has confused me at times, but I do think this is the correct configuration.

I saw the prefix delegation option does not have a "not used" selection in the drop down menu, so there will always be a number there, in my case I left it at /48. I think without a prefix delegation range specified, it is unused.

b1622cdd-5328-4f27-9e53-93e16e300b63-image.png

@JKnott

Further on this, the base prefix and prefix length are provided as part of the DHCPv6-PD process. The prefix ID is provided on the LAN config page. Why can the two not be used, if necessary, to automatically provide the first prefix?

Hi

Just wanted to add also saw this issue during an upgrade from 2.4.4_3 to 2.4.5, I had previously unchecked "Register DHCP leases in the DNS Resolver" due to loads of restarts on the DNS Resolver service. On upgrading to 2.4.5 (I think unrelated to the upgrade, it was just because of the restart) I found an issue with my VoIP phone over IPv6 failing to register. Various trouble shooting later I ended up testing from a Windows PC using NSLOOKUP which picked up the DNS server on the IPv6 address but it was timing out and returning no results.

A Goggle brought me here, so as per OP I restarted the DNS Resolver and NSLOOKUP started returning addresses, and low and behold the VoIP phone registered back up. So definitely a bug somewhere.

Regards

Phil

Just wanted to give an update on the issue.

I wrote to my ISP explaining the problem. I didn't get an answer, but the following day, my IPv6 connection got miraculously rock solid (since 5 days now), whereas I hadn't touched the system.

A big thanks to all the people on this forum who helped trying to find a solution 👍

@riften Yep, I get the same behavior from the Arris BGW210-700.

@JKnott said in Getting upstream delegating router to create a route to pfSense gateway:

@AaronL

That is surprising, given that Comcast has long promoted IPv6. However, what you can do is capture the DHCPv6 packets. Set up Packet Capture to capture ICMPv6 on the WAN port. Then disconnect/reconnect the WAN cable. This should result in capturing the DHCPv6 packets. Download the capture and open it with Wireshark. The advertise and reply XID lines should show the assigned prefix.

Yeah, that is the first thing I did. The DHCPv6 conversation works great, and goes exactly how it should. (That's not entirely true; it gives out T1 and T2 values that dhcp6cd thinks are 'too short,' but as far as I can tell, that's not causing any actual trouble.)

The problem is that a route matching the assigned prefix doesn't seem to get added on the cablemodem, which I can also see clearly in Wireshark from the neighbor discovery packets.

Because Comcast has had a reputation for making an effort on IPv6, I want to push on this as hard as I can: this is really something that should be right, and from an engineering standpoint, is probably pretty straightforward to fix.

@Bob-Dig said in IPv6 / track interface / pass DNS server to client:

rewall-aliases of my hosts by itself, bravo.

What? What? Really? No joke?

Charter will allow you a /56 if you select that on the "DHCPv6 Prefix Delegation size" config on the WAN interface. Then as stated you can use a 0-ff for the prefix ID on your internal interfaces to assign a /64 to that network.

@Crunk_Bass said in DHCP6 request specific address:

Is there any way I can request an address with a specific interace identifier?

Not that I'm aware of.

What does your current setup look like?
Is your pfSense behind your Fritz!Box router?
Wich device does all the PPPoE stuff?

I'm a little confused. Is IPv6 working when you are using the Fritz!Box?

At first glance it looks like you would be better off using something like a DrayTek Vigor165 as a modem instead of the Fritz!Box.

@dr_tech

Did the ISP provide configuration info?

@amello

So open a ticket - https://redmine.pfsense.org/issues/10364 - and was rejected asking for more information to be provided here.

Not sure what information to provide, but on the ISPs side all is working, as with two pfSenses works without any issues. Only when consolidating to one box is that the problem appears.

@jimp If states are not to be preserved, then a disable/enable (via a heartbeat mechanism or otherwise) might do the trick.. of course with a disruption of the IPv6 connectivity while the tunnel is re-establishing itself.

No, Netgear and HP. All managed.

What I finally did was deleting the interface and then creating it new. This time there seems to be no problem.

Thanks everybody.

I have to read more log files to get a sense, when there is something not ok.

Also I crafted some new IPv6 addresses in the DHCPv6 Server, like this one:
::192:168:2:37

😋