@Gilera said in Issues with IPv6 PD over PPPoE IPv4:
Learning everyday about ipv6........@JKnott, why do i only get a link local ipv6 address on the WAN? I do not have that option selected.
You do in that screen capture you posted. That's why I mentioned it.
So I finished my testing somewhat successful.
I divided that one and only /64 Prefix from my pesky ISP into some /80s. All my PCs, physical and virtual (Windows 10, Ubuntu Server 18.04) worked fine with that /80s, tested from inside and outside.
My older Asus-Router, configured as an AP, my Android10-Phone, connected to that AP, and my Dell MuFu-Printer, connected via Ethernet, stayed on IPv4 only.
Not the worst outcome I think.
So it is doable, but not for every device.
NPt with that ULA seemed to work also for one interface, for one other it wasn't at the time of testing, so I skiped this test, to later find out, that there was this bad static-route... So my conclusion, although not thoroughly tested, it would be working with ULA and NPt the same as with direct public IPv6 Prefixes.
@JKnott No. I meant my ISP-WAN-IPv6-Addresse, which is more or less dynamic and I find the support for something like that in pfSense not as good as it could be and I am rumbling about that here from time to time...
Now I got all those IP-Addresses from HE and all those PTR possibilities but not enough machines for it to use. All servers need there own machine to fully take advantage of PTR is what I meant.
@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.
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.
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?
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.
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
@JKnott said in Getting upstream delegating router to create a route to pfSense gateway:
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.
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.
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.
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.
What I finally did was deleting the interface and then creating it new. This time there seems to be no problem.
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:
To the ones that may have the same problem as me, I managed to go a little further. To allow incoming ICMPv6 ping messages I had to uncheck those two options on my interface:
I'm still having a problem with my Cisco SG250-26 which does not let some IPv6 packets passing through...
I think it's being blocked by the default deny rule. Make a rule on that VLAN3_HB interface for tcp port 22 and set it to accept.
If you assign a new interface there aren't any rules applied to it so everything will be blocked by default. Also if the machine your connecting to is on another segment make sure a firewall rule that will let that traffic pass is applied.
I assume ssh to pfsense is working because pfsense has anti lockout rules for local ssh managment.
Sounds like a similar issue to what happens when devices use NIC teaming or similar to impersonate one another's addresses in non-standard ways.
I don't see a sysctl to affect that directly but you might try adjusting the value of the net.inet6.ip6.log_interval tunable. You can make an entry for it under System > Advanced on the tunables tab. It controls the number of seconds between log messages. So you could maybe try -1 or 0 to disable, or a much higher value so it happens less frequently (e.g. 120, 3600, 86400...)
Alright so that is working, but now the LAN VM's have no access to the WAN. I have been troubleshooting for a while now on what this could be but cannot find anything on it... I have no gateway for LAN nor routing setup.
As noted, so long as you have zero-loss connection, fragmentation is not an issue. For example, my HE.NET connection is a corporate one and out of the peak times (around 3 p.m. work days) it passes all tests for any MTU <= 1472 and MSS <= MTU - 20. Problems arise only under heavy load.
By the way, the harder targets (to me) are those in Eastern Europe, Latin America, and Africa.
@JKnott said in IPv6 setup with public subnet:
There are enough /48s to give every single person on earth over 4000 of them. This is with only 1/8 of the IPv6 address space assigned to GUAs. Over 3/4 of the address space isn't even allocated to anything.
This is true, but it is not reflected in the price ARIN charges for v6 space. For a small provider, the annual fee doubles when you go from a /40 (256 customer allocations) to a /36 (4096 customer sites), and doubles again when you go to a /32 (65,536 sites). Probably smaller shops are trying to cut costs on v6 deployment, as it offers little benefit to them if they have sufficient v4 space.
@karsten_berlin said in IPv6 on Telekom Business Line:
known by me, but the "internal routing" within the pfsense from LAN to WAN and vice-versa is a mystery in that case to me.
We have a normal business DSL by DTAG, WAN is PPPoE, DHCP6, DHCPv6 Prefix of /56, LAN with Trackinterface WAN. All is static. It's like dynamic but always the same IPs. Maybe it helps, don't know if its different with other connection types.
You can have a lot more than 8. I don't know if there is a limit. Probably each OS might have it's own limits.
Both Linux & Windows have 8 addresses, after being up for a week, with a new one each day
One concept of multiple addresses on an interface is for each service on the host to have its own GUA. That way you don't have to worry about port conflicts.
There are also privacy addresses with SLAAC, which change daily
That was one of the reasons they decided on 64 bits for the host part of the address so that they could be randomly generated by the service with a reasonable chance that it wouldn't be a duplicate
Also, to work with the EUI-64 MAC addresses. EUI-48 addresses are converted to EUI-64 by inserting fffe in the middle.
On my own network, I have both GUA and ULA addresses, 8 of each.
@Overclock said in Non local gateway IPv6:
I let you inform about OVH response.
Ask them how SLAAC is supposed to work with a /56. You may be able to get a single /64 to work, but the other 255 will be unusable.
We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.
Subscribe to our Newsletter
Product information, software announcements, and special offers. See our newsletter archive for past announcements.