@xianic said in ipv6: can ping GUA address in different VLAN, but not ULA.:
I was writing a post asking for help with the same think but I thing though I might have solved it. The setup I have is:
GUAs on the VLAN interface are statically assigned, tracked should work just as well and would probably be less work for me.
A /64 ULA prefix for each VLAN on the RA page, e.g fdxx:xxxx:xxxx:a::/64 on VLAN10 and fdxx:xxxx:xxxx:b::/64 on VLAN11
fdxx:xxxx:xxxx:a::1 and fdxx:xxxx:xxxx:b::1 virtual addresses assigned to each interface
A firewall rule on VLAN10 interface to allow all traffic from fdxx:xxxx:xxxx:a::/64 to a specific host on VLAN11
That doesn't work for me, as - like I more or less suspected - the GUA disappears from the interface after a reboot, and the Virtual IP is assigned to the interface instead.
The net result is that the clients now only get ULA addresses and no longer a GUA.
Hence: no internet access.
In your case, maybe the GUA stays in place because you have defined them as static rather than track interface?
I can confirm that it's possible to get IPV6 on the LB1120 in bridge mode with AT&T working in PFsense, but it's a VERY non-optimal configuration.
It appears that I get a single /64 via SLAAC (as mentioned above). The default route for internet isn't fe80::1 It appears to be randomly generated and locally advertised. Here's where things get weird - although I can see the router adverts, the router won't actually pass the packets if I boot it connected to PFsense.
Here's what did work:
Hook the LB1120 (unpowered) up to a computer running windows.
Turn on the LB1120 and let it boot
Query the ethernet port in windows with 'ipconfig'. Record the IP address received by windows, the GW address assigned, and the ethernet address of the windows machine's ethernet port.
Unplug the LB1120 from the win10 computer (don't power it off).
Configure PFsense to spoof the win10 computer's HW address, set static IPV6 using the assigned address (though you can actually change it slightly, too). I'm also assigning it as a /126 (/128 might be possible), and set a static gw recorded above.
The mac spoof is necessary to get both a DHCPv4 IP and working IPV6. Yes, this is incredibly hackish. Ideally, I'd like to figure out what magic is happening with windows that isn't happening with PFsense, so I can set this thing to autoconfig.
So far, I see only 2 differences in the packet captures:
Windows uses an AT&T-advertised nameserver on a private local address:
I tried hard-coding that nameserver in the config, but it did not help.
Windows sends a bunch of broadcasts on ff02::16. This is multicast listener discovery. I'm not sure how to make PFsense send these, and only a few search hits for mld with pfsense. Any ideas?
Now, I'm having some trouble getting ipv6 packets to pass the wireless WAN link when the router is set to prefer the wired IPV6. But that's a multi-WAN issue, so I'll probably start a new thread on that.
@isaacfl said in IPv6 Router Advertisements - Router Mode - Stateless DHCP:
From my own testing today. "Stateless DHCP" seems to be the same as assisted but with the "Management" flag not set. My PC's seemed to not mind, but my Apple products work better with "Assisted".
Which is exactly what the dropdown says?
I would think you'd still get a /128 global address for the WAN interface itself, but maybe I'm wrong... regardless, if you're using DHCPv6 to get a prefix, you need to have a LAN or other interface that is tracking WAN in order for the prefix to actually be obtained. Maybe that also applies to the WAN global address.
BTW, you don't need to delete the DUID file anymore. You can actually adjust the DUID setting in System > Advanced > Networking, assuming you're running a newer version of pfSense. Just increase the time value a few seconds to create a different DUID and Comcast's servers will respond accordingly. The old DUID will eventually expire out of their systems after a week. In fact, pfSense might just re-create the DUID file with the same DUID if you don't change the setting.
@xero9 I'm in a similar boat. In most cases, I've just applied the changes through the webGUI. Sometimes, I'll release and renew the DHCP through the webGUI. On occasion, I've taken disabled and re-enabled the interface in the GUI to ensure that I've forced a reset (though this is probably overkill). I haven't had to reboot the machine.
Are you able to consistently get an address on your WAN? Something starting with 2600:, probably? It will always have an address starting with fe80:
@theserverguy Only after I enter the ::1 address specifically in the monitoring field. Just enabling the 6to4 config isn't enough for the gateway monitoring.
If I leave it blank IPv6 still works but the monitor says it's down. So it seems to be cosmetic but affects the uptime stats.
So I suspect the 6to4 code simply missing a step when it creates the dynamic gateway for monitoring.
@jknott said in sub-delegation of WAN PD for DHCPv6 server:
@jimp said in sub-delegation of WAN PD for DHCPv6 server:
“Prefix” doesn’t mean /64, it means “IPv6 subnet”
"PD" means prefix delegation, part of the process that creates addresses for devices. The prefix, with PD, is 64 bits and the other 64 bits are determined by some other means such as SLAAC or DHCPv6.
PD does mean prefix delegation, but I think you might be confusing a couple terms. Normal DHCPv6 doesn't involve PD. If a client just wants an address it requests one from the interface which is inside the /64 subnet. If that client also happens to be a router, then it kicks in PD to request a delegation. This is an additional block of addresses that get routed to the client.
PD is not locked to /64. You can delegate whatever size blocks you want depending on what you have available. PD is frequently larger than /64, that's how an ISP will assign multiple /64's to a single customer, by delegating them a /60, /56, or whatever they choose.
The firewall will take individual /64 networks out of that block and assign them locally. When you set an interface in pfSense to "Track Interface" for IPv6, you can then set an IPv6 Prefix ID which controls how it chooses a network to put on the interface.
If your ISP uses PD to delegate you a /60, then you can choose from 16 different IDs for /64 networks inside that block (id 0 through f), so you can delegate ID 0 to your LAN, 1 to a guest network, 2 to a DMZ, and so on.
In OPs scenario, they want to take some of that, say IDs 8-F, and use that to delegate to some other router. For example, ID 0 would be on LAN, a client gets an address in the 0 network, and then the firewall would route prefix ID 8 to that address.
Bear with me on this, I'm new to pfSense and this was so confusing and tricky but I was able to at least temporarily set things right with my issue...
I'm hoping someone might be able to correct me on what happened here because I'm not even sure if my work here is a solution to the problem or not, but I was able to finally get a v6 address assigned and I can ping ipv6.google.com.
What I did was this:
Commented out this line: send ia-pd 0; request prefix delegation
Issue command dhcp6c -c /var/etc/dhcp6c_wan.conf -d em0
Hopefully this is helpful, at least I can refer to it again once I have my forced appointment with a comcast technician to have gigabit Internet working and the problem happens again.
I've had the same prefix since that setting was added, about 2 years ago IIRC. That's stable enough for me. On IPv4, my host name is based on firewall & cable modem MAC addresses and so never changes unless I change hardware. This means that no matter what my IPv4 address is, I can still find my network. However, my IPv4 address is also stable, so long as I leave my firewall running, other than the rare occasion when my ISP makes network changes.
@johnpoz said in Working around AT&T's terrible native IPv6 implementation:
Because they are special assignment prefixes… 2001:db8::/32 is designed for documentation purpose use… Just like 192.0.2/24 in ipv4… There are others in ipv4 as well that do not route other than rfc1918…
2001:2::/48 is for benchmarking, and again not designed to route globally. There are others that might not route, they have caveats… Here…
Oh, that sort of thing. I wonder why they didn't use a ULA for that, instead of messing things up.
@deet Exactly what I've been through. :( In case I can't clear, my PD on LAN is now a /64. Before with WAN set to /59 and hinting I was getting the /63 on WAN.
I also turned off the firewall on the cable modem. Under firewall for IPv4 and 6 select Custom then at the bottom the last check box is were you can disable it. It's kind of hidden.
@satadru said in Netflix & HE.net tunnel fix using unbound python module revisited.:
Note that the last line restarts unbound, since I’ve discovered that with timing of the script running, it is best to force unbound to restart to make sure that the symlinking for python is done before unbound starts. (Otherwise it might not start.)
thanks for that, will check later on
@zer0t3ch said in Dual WAN IPv6:
Yes the LAN gets an IPv6 too. I think the problem is the Track Interface option. That is set wo WAN, so it can‘t use the WAN_VDSL. In my point of view Multi WAN is impossible with IPv6. Or can I set LAN to assign it‘s IPv6 by DHCP?
Multi-WAN is possible within the confines of what IPv6 is capable of, just not easily done with pfSense right now.
ULA + NPt seems to be about the only (mostly) reliable way to get Multi-WAN IPv6 working, with appropriate caveats.
@johnpoz said in avoid using IPv6 for host/domain:
Could you give an example site that does this?
That was one of my SIP providers, here is the message I see after login:
Sorry, your IP address is marked as high risk or you're accessing our web site through IP proxy or VPN. We can't provide a service to you.
I'll try the script suggested, thanks!
@jimp said in Firewall rules bug?:
Yeah it was a validation problem. GIGO. I added some frontend and backend validation.
Put those changes in by hand, and it does parse the above case correctly, throws a red
The following input errors were detected:
The specified source address is not a valid IPv6 prefix
@alankeny said in Static addresses for servers:
Thanks for confirming this. I started with how-to guides that kept referring to EUI-64 addresses based on the MAC with “ff:fe” in the middle. I couldn’t find any of these, since it doesn’t seem like they’re really used very much any more.
They are. They're default on Linux, but Windows defaults to a random number. However, it can be configured to use the MAC address instead.
@donzalmrol said in How to retrieve my IPv6 default gateway?:
I was in the understanding that I would have a IPv6 gateway in the same range (2a02:.../56) like I have with my public IP (18.104.22.168/19).
I believe the problem was my rental ASSUS cable-modem/router-wifi. It was not passing the prefix subnet information, only individual ipv6 ip addresses for the one /64 subnet that it was using for direct connections to its LAN side. It was not sharing the rest of the /60 block that was showing up on the WAN side.
When I swapped it out for a NETGEAR CM700 and plugged the pfsense firewall into the NETGEAR CM700 ethernet out, the pfsense fw picked up the proper IPv6 information to distribute IPv6 addresses on the LAN side. That's what I wanted. I am going to mark this as resolved.
I read the article and saw that - and what I am saying is BS.. Sure you can use up anything with bad management.. Sorry but they are not big enough to use it up if they would of planned correctly.
They do not have enough employees to justify all 17 plus million IPs being gone with proper planning.
OK, now you have to determine if traffic for 2001:818:d9d9:ba00::/56 is arriving on your interface. Set up a packet capture like this and start it.
The try to do stuff with it like ping6 2001:818:d9d9:ba01::1/56 from the outside, telnet to it from the outside, etc.
Then stop the capture and see what is there.
If you need someone to ping6 it from the outside holler.
Hmm. This is interesting:
@kjstech I think we've the same issues. Try a IPv6 ping. After heavy using IPv6 (Google maps, Youtube, Facebook) my IPv6 connection gets worse and worse. Reboot pfSense oder restart the WAN interface helps and the connection is fine for some moments again.