@spacey

SLAAC is the normal way to configure IPv6.

Look on Services > DHCPv6 Server & RA > LAN > Router Advertisements. If you have things configured correctly, a prefix will be automatically provided and the suffix is provided by the device.

@ofloo

These also show up in systemlog

dpinger 16720 IPSEC31V6_VTIV6 xx:xx:xx:xx::1: sendto error: 50

@jknott No, disconnecting and reconnecting the cable does not cause the behavior to change. Even a full reboot does not seem to fix the issue. The DHCPv6 packets contain a Preferred lifetime of 86400 and Valid lifetime of 172800.

@ofloo

Sorry, I have never used TAP, but I can see problems in trying to bridge between networks.

Hello,

I attempted to upgrade to 2.5.1 last night but I believe that I encountered the problem above. I couldn't get IPv6 addresses or routing on any of my WAN connections. I tried troubleshooting for several hours but had to give up and rollback to 2.4.5_1.

From the messages above and in the bug tracker, it seems like this might be fixed but in a version that isn't released yet. Is that accurate? (I've been reading from https://redmine.pfsense.org/issues/11454 and they mention installing 2.5.1 plus a patch..) Is there any way to know when this should be published and I could re-attempt upgrading?

Thanks,
Ryan

@wineguy

Yeah, using a sniffer is a good idea. When I had the problem with my ISP, I made a data tap with a managed switch.

@tzvia said in WAN DHCP6 gets addresses, but no connectivity:

@jackthesmack said in WAN DHCP6 gets addresses, but no connectivity:

@tzvia said in WAN DHCP6 gets addresses, but no connectivity:

@jackthesmack Do IPV6 IPs show in your INTERFACES on the dashboard now, because your post showing your INTERFACES only lists IPV4 addresses.

No they don't, despite the IPv6 addresses showing in the Status / Interfaces page.

In your screenshot I only see the link local and gateway which looks to be an FE80. I don't see an IPV6 address assigned, that's why I am asking. You would think that if your router was getting functional IPV6 from the ISP and was set correctly and was assigned, you would have IPs assigned from the ISP, not just a link local address.
a9377e67-27bf-48f5-ab46-0a18e80ca677-image.png

Well this seems like an ISP issue now, because I plugged in my PC directly into the modem and now IPV6 doesn't work anymore.

6735661e-e88a-408a-a8ab-d548b473e5b3-image.png

03291491-d272-465a-abe3-3935b888ecd4-image.png

@jknott

One thing I forgot to mention. You'll need to create a DNS Access List entry to cover the range of ULA addresses used. This can be done individually for each interface or block of ULA used on your network. I used a /56 block to cover any ULA on my network.

2a109afe-1f55-4731-94c2-d022a8604f95-image.png

@gertjan I've figure out the issue.

I have a modem (Netgear CM1150V) that allows LAGG/LACP connections. It was broken until they released a firmware update, which I noticed shortly after the ping issue with Comcast. Once Comcast fixed my line, I decided to set that up. I had it set up with a prior modem, but never this one due to the firmware bug.

So I undid the LAGG/LACP connection, and just made it failover, and suddenly the HE tunnel came back up! I do not know why it was not working. I'm not sure if the modem has a bug with sending back reply packets - but given that IPv4 works fine otherwise and the tunnel runs over IPv4 I think the issue is in pfSense.

Where do I submit a bug report over this?

(This was driving me crazy because it made no sense, but now it totally does!)

@jim-bob-the-grand I am with you, but it seems to be complicated. And also pfSense doesn't care about MAC-Addresses, but this probably would be a requirement to get full control back like we used to. 😀

@tomsparklabs said in [Solved] Unable to ping pfSense's LAN interface on IPv6:

rebooted the router

Hmm, thanks from the future...I set up an HE tunnel tonight and though the router could get out over IPv6, and PCs got IPv6 addresses, I found the PCs could not ping the router, dig to pfSense DNS over IPv6 to the LAN IPv6 was blocked by the default block firewall rule despite already having a LAN IPv6 to any rule, and new rules I added for DNS.

Restarting pfSense (2.5.1) got IPv6 working fine from the PCs.

Oddly https://test-ipv6.com/ worked...I guess over IPv4? But it showed IPv6 working, 10/10.

@bob-dig

I agree it should be easier to find. As for the name alias, that was even the case with IPv4, before there was IPv6. I assume it's because you have more than one address an interface can use, which is not typical. Also, with IPv6, you have not just mulitple addresses, you have multiple prefixes. Even if you don't have an alias, with SLAAC you can have up to 8 addresses, then there's link local too. By the time you've added a 2nd prefix, you're up to 17 addresses on a single interface.

I can use the IPV6 that are assigned on the USG DHCP to address computers from the internet. It just won't say "Internet" on Network and Sharing Center, or pass any IPv6 tests.

Ping (as well as traceroutes) from local computers to google.com are fine even though it says "No Internet Access".

The traceroutes go from the USG to the pfSense LAN IPv6 out to the internet, even though I have the link-local gateway address of Cox specified in the next-hop on the USG.

I found the problem.

I had IPv6 enabled in pfBLocker-devel 3.0.16 DNSBL:

IPv6 DNSBL
Enable Enable DNSBL for IPv6 DNS Resolution filtering. Default IPv6 Webserver address [ ::10.10.10.1 ] and ports [80/443]

radvd was choking on the ::10.10.10.1 RDNSS line of the config file.

Just in case someone finds this hack useful, the following is the patch I used on 2.5.0. It will only do what is intended (hardcode advertised MTU to 1480) if "Use same settings as DHCPv6 server" is unchecked under the Router Advertisements configuration settings.

src/etc/inc/services.inc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/etc/inc/services.inc b/src/etc/inc/services.inc index a3203aaaf7..1c63272ca1 100644 --- a/src/etc/inc/services.inc +++ b/src/etc/inc/services.inc @@ -130,7 +130,8 @@ function services_radvd_configure($blacklist = array()) { $radvdconf .= "\tAdvDefaultLifetime {$dhcpv6ifconf['raadvdefaultlifetime']};\n"; } - $mtu = get_interface_mtu($realif); + /*$mtu = get_interface_mtu($realif);*/ + $mtu = 1480; if (is_numeric($mtu)) { $radvdconf .= "\tAdvLinkMTU {$mtu};\n"; } else {

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

@starcodesystems said in IPV6 ULA LAN to WAN ISP Public IPV4 internet possible?:

you have to know how to do these things

Huh? Why would you need to know how do stuff that makes no sense to do?

Do you have a use case example where anyone would want/need to do such a thing? Where it wouldn't make more sense to just give the device rfc1918 that you nat to your public IPv4..

I don't think its really anything to do with the AP firmware.. So I don't think they will be able to fix it.. From what a few were saying has to do with the different auth that wpa3 uses..

Not sure - have not dug that deep into yet. I was really hoping to just have guest be limited to wpa3.. But I will live with this compromise.. Just thought give you a heads up if you were doing the same thing.. And you had friends come over - and you get hey this qr code thing isn't working ;)

@gertjan

Yep. He was one of my favourite things in that magazine. Incidentally, I have every paper issue of the magazine on my shelves here, going back to Vol 1, #1, Sept 1975. I bought the first three issues in person from the original publisher, Wayne Greene, at an amateur radio convention in Ottawa in 1975. He put the magazine in his wife's name for tax reasons. He then lost it when they divorced.

@fabrizior I didn’t know it was a thing :) Thanks for the information.

@codster SLAAC addresses are not random. Some are based on MAC address (ie they will not change unless you MAC changes), and others (the windows default) are randomly generated at install time so they will remain persistent across reboots until you change configuration or reinstall the os. The last 64bits of the address will also remain static if your prefix changes or you connect the device to a completely separate physical network.

On the other hand, "privacy extensions" create random addresses, but these are only used for outbound connections - your device should still have a permanent SLAAC address which it can use for inbound.

Not sure about rules for a dynamically delegated prefix, can you just use the last 64 bits of the address as is done with the dhcpv6 configuration (eg :🔡1234🔡1234)

@jknott I didn't say reboot. I said save WAN again. Your workflow might be triggering a dhcp6c refresh, but, in general, when you make changes to inside interfaces set to "track interface" you have to save WAN again to pick them up. The dhcp6c client is the mechanism that sets all of the interface addresses. That happens when dhcp6c receives the PD. That happens on WAN. pfSense itself does not do any of that work.

Since this is the forum for IPv6 and not the forum for the Development 2.5.1-RC snapshots, you may want to re-post this over there, where the developers would be more likely to see it.

https://forum.netgate.com/category/83/21-02-2-2-5-1-snapshots

I have a similar use case, namely building tenants with their own routers. Can this method (firewall rules) be used to control prefix delegation, or at least restrict access to allowed tenants?

We're doing this (denying) now with IPv4, where we tell them to plug in, see the IPv4 lease request to create a static lease, after which we can create a firewall rule allowing it. Can't get the old Comcast router to give more than a /64 so I was thinking of using Hurricane to get IPv6 for the tenants.

@ttmcmurry thank you so much for your work on this! One of my biggest irritations with AT&T was the inability to pull more than one /64, while on Spectrum I can get a /56 PD with no issues at all. I have this working on 2.5 -- I had some issues at first and then discovered it was because things do not behave well with IPv6 enabled on multiple WAN interfaces at the same time (I still have the Spectrum modem connected until service cancels out at the end of the month).

I am on VDSL and therefore am unable to attempt bypassing the gateway.

@derelict Of course, it was one of the DHCPv6 messages. That makes a lot of sense. (I thought this was RA-related since as discussed before, the DHCPv6 mode is the only way aside from SLAAC to make pfSense pick the gateway from the RA message.) So we're back to not receiving the DHCPv6 messages at all. I added similar rules for DHCPv6 messages, and we just don't see them at all. But that's not an issue for this thread.

@bob-dig

That's nonsense. First off, we shouldn't avoid IPv6, as that's what the world is moving to and the sooner the better. Also, I gave some suggestions that may help @MrGlasspoole with his problem.

@foo said in Configuring multiple routable IPv6 subnets with multiple routers:

How should I have the router A, LAN A and LAN B interfaces configured to connect to router B and C? Should I use DHCPv6 or RA?

Think about how you'd do it in IPv4. You set up routes to say those addresses go there. Same thing with IPv6. This is basic stuff for anyone setting up networks, whether IPv4 or IPv6.

@jimp said in RA (and therefore SLAAC) not working after updating to 2.5.0:

It still looks like a settings issue.

If your ISP is sending you a /56 then set the delegation size on the WAN settings to match, /56.

It should slice that up into /64 chunks automatically.

Holy cow, really simple to fix, if you just know what to do ;)
Thank you so much, this solved the issue!

Why stop there.. While they are at - let me put a /32 on the interface.. That is the min sized prefix you get from arin ;) so you might as well let me put it on my interface - I might want to route it <rolleyes>

And clearly the only way to route anything is put it on an interface..

Just like you have rule #2 preventing access to the private IPv4 range, create a rule that prevents access to your IPv6 prefix range. I'm assuming that your IPv6 prefix is static (I certainly hope it is if you have 40 VLANs).

For example, if your prefix is 2001:aaaa:bbbb:cd00::/56, create a rule that prevents access to that entire address range. Now your various VLANs won't be able to communicate with each other via IPv4 or IPv6. Of course, if you use pfSense for DNS, NTP, etc., I hope you've allowed those through other rules, because that block would also prevent communication with pfSense.

If you want to allow communication between two VLANs, create a single rule for both IPv4/v6, and use the "[interface] Network" selection for the destination... that will include both the IPv4 and IPv6 subnets for the VLAN that you select.

Well, with apologies for the noise level, I found a "fix" - I enabled "Do not wait for a RA" on the WAN interface, rebooted the modem and now recovery is complete without having to toggle the interface.

I am stumped why this makes any difference as the modem clearly is sending out RAs after its reboot.

I can see from the System logs that dhcp6 client is started without RA mode - consistent with how its now configured! :-) and sends a solicit and gets an advertise back - which then kicks the PD process off.

Stu

Works here as well

Hi guys,

I've followed this conversation quite a while and run into the same issue.
For everyone who would like to have dynamic NPT address to solve this issue please find my repo here: https://github.com/gewuerzgurke84/pfSense-dynamicNptAddress
It's tested it with 1 NPT mapping and 1 "Tracking" Interface with pfSense 2.5.0 and it solves my issue so far. Nevertheless I'd prefer to have this feature as part of the distribution itsself as it is a requirement to get IPv6 running in a reasonable way (at least in Germany)...

Best Regards,
Alex

@yon-0 said in Thank you for the IPv6 NAT capabilities in 2.5:

how config ipv6 nat in pfsense 2.5

You do it exactly as with IPv4 (use ULAs "instead" of private IPs and don't forget outbound NAT).