Why does this seem like spam to me.. Why does someone join a site just to advertise some site - other than just spam!!!
I wouldn't hit that site with your ____ if you know what I mean!
There is one thing if you have user X that has been here in the community, and then there is a thread that says hey where do you test Y.. suggesting a site, and then there is accounts that join, and same instant suggest go X.. I should just delete and ban this account.. But its not from IN, so will give the benefit of doubt... For now.
@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.
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?
@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.
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.
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.
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. 😀
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.
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.
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.
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 ;)
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.
@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.
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.
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.
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)...
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 to sign up for future newsletters and to read past announcements.