IPv6 doubts
-
@Derelict : Of course, as soon as I get home I'll post the relevant info.
-
@johnpoz apparently not, I have exactly zero clue as to why they'd give me a whole /56, only to deny it to me by giving me /64 addresses through SLAAC from their router, smh...
-
@derelict as per your request here's the requested snapshot
-
OK that's a /64 on WAN so that is what I would expect.
Is that statically-configured or is that what is on the interface when WAN is configured for SLAAC?
LAN looks good as well. I would:
(At least temporarily) Pass ICMPv6 (any) traffic on WAN from source any to destination 2001:818:d9d9:ba00::/56
ping6 2001:818:d9d9:ba01::fffe from the outside someplace.
See if you get a response. If so, you can start looking at why LAN isn't working. If not, verify you can ping6 to 2001:818:d9d9:ba00::fffe. If not your pings are probably not working. if so, packet capture on WAN for IPv6 traffic for 2001:818:d9d9:ba01::fffe and test the ping6 to that again. Stop the capture and see if you can see the echo requests coming in from the ISP. If so, you can proceed to figure out why there is no response. If not, you need to nail down the ISP as to exactly how they are provisioning this /56.
-
You've got a bridge interface set up with IP addresses on each interface and the bridge, thought you should only have IP addresses on the bridge interface.
https://doc.pfsense.org/index.php/Interface_Bridges
-
@derelict this is statically configured. I haven't tried using SLAAC, will attempt to do so now.
-
Not at all what I recommended you do but OK.
-
@nogbadthebad Yeah I haven't even started with the bridge yet. First thing is to see if this ISP is even sending the traffic.
@cmpsalvestrini Why are you complicating things that aren't working yet with things like interface bridges? Why do you feel the need to do that?
-
Pings to the WAN interface work.
mac-pro:~ andy$ ping6 2001:818:d9d9:ba00::fffe
PING6(56=40+8+8 bytes) 2a02:8010:XXXX:X::14 --> 2001:818:d9d9:ba00::fffe
16 bytes from 2001:818:d9d9:ba00::fffe, icmp_seq=0 hlim=252 time=50.847 ms
16 bytes from 2001:818:d9d9:ba00::fffe, icmp_seq=1 hlim=252 time=51.265 ms
16 bytes from 2001:818:d9d9:ba00::fffe, icmp_seq=2 hlim=252 time=50.797 ms
16 bytes from 2001:818:d9d9:ba00::fffe, icmp_seq=3 hlim=252 time=50.751 ms
16 bytes from 2001:818:d9d9:ba00::fffe, icmp_seq=4 hlim=252 time=51.085 ms -
@derelict I-m still on the static, I fiddled with the LAN side a bit and I have as follows:
Interfaces status:Firewall:
I know I was complicating things, I removed the bridge and I am trying to be a good boy and use a ULA and the (famous? infamous? nefarious?) NPt service. I get as follows in my client:
All dandy, until:
-
Right. the other doesn't but that could be rules.
-
You have a invert match rule on your wan interface.
-
OK now everything is completely different. I would request that you stop making wholesale changes and perform the requested steps.
It is not up to you to be good and use ULA. It is up to the ISP not to be bad to give you something usable.
-
And the destination is WAN net not the entire /56 so you won't be able to ping anything on the inside /64s. Please re-read my suggested actions above.
-
@derelict That's what happens when one starts thinking and having weird ideas. Let me fix that and I'll get back to you.
-
I just noticed the ! I know how much you like them :)
-
@Derelict Okay. Things have been fixed to the way they were before, eliminating the bridge (Bad, bad idea I had). I apologize for not following the procedure. I have been dealing with this for the past 2 months trying to get IPv6 working and, well, let's say frustration is a bad counselor. Anyhow, as requested:
Firewall rule:
-
Are you sure you've fully removed the bridge, I can still see the bridge line in the screenshot.
-
OK with those rules in place I should be able to ping 2001:818:d9d9:ba01::fffe but I cannot. So they are apparently not routing that to you like they said.
I would go back to them and ask how exactly this is provisioned.
What do I put on the WAN interface here?
How is the /56 routed to me?
Just ask for generic instructions for any router. It doesn't have to be pfSense-specific.
I would also packet capture for incoming ICMPv6 packets to that address and ping it from the outside and see if they show up.
If not I would packet capture for neighbor solicitations on WAN for that address and ping it again. If they are soliciting for a neighbor on two different /64s on WAN they are, as @johnpoz might say, borked.
-
The bridge should not matter for this test. There should be a 2001:818:d9d9:ba01::fffe/64 address on a localhost interface that should respond. The bridge should not matter here but should be cleaned up for sure.