IPv6 sanity check
-
Connection-specific DNS Suffix . : localdomain
IPv6 Address. . . . . . . . . . . : 2001:xxxx:xxxx:6900:806a:e655:2a58:123
IPv6 Address. . . . . . . . . . . : 2001:xxxx:xxxx:6900:ffff::7966
Temporary IPv6 Address. . . . . . : 2001:xxxx:xxxx:6900:bccd:35e8:9436:f0f2
Link-local IPv6 Address . . . . . : fe80::806a:e655:2a58:123%10
IPv4 Address. . . . . . . . . . . : 192.168.1.101
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : fe80::2e0:b6ff:fe13:6ea2%10
192.168.1.1 -
Those addresses should be xxxx:6900:1:*
Sorry, it Looks like it might be my typo in an earlier message.
It should read from 2001:xxxx:xxxx:6900:1::2 to 2001:xxxx:xxxx:6900:1:ffff:ffff
DHCPv6 addresses on the LAN need to be in the same 64 range as the LAN address.
Once that's done then disable and re-enable the LAN port on the PC, then ipconfig and check the address is in the right 64.
Use this address to check your IPv6 with a browser.
http://ipv6-test.com/
-
Are you sure that range is correct? It's giving me a "valid range must be specified" error.
-
I changed it to: 2001:xxxx:xxxx:6900:1::2 to 2001:xxxx:xxxx:6900:1::ffff
That should work correct?
-
Yes it should, can't see instantly why it complained. I'll fire it up on my test unit as soon as I get the chance and see whats wrong.
-
No.
2001:xxxx:xxxx:6900:1::2
That will still be on the WAN subnet.
Set your WAN IPv6 address to 2001:xxxx:xxxx:6900::2/64
Set the default IPv6 gateway on that interface to: 2001:xxxx:xxxx:6900::1
That leaves 255 /64 networks to assign to inside interfaces:
2001:xxxx:xxxx:6901::/64 through 2001:xxxx:xxxx:69ff::/64
-
thanks Derelict, not enough sleep and too many work hours the last couple of weeks, silly mistakes are creeping in!
-
I have the WAN set as 2001:xxxx:xxxx:6900::2/64 and the LAN IP set as 2001:xxxx:xxxx:6901::1/64.
On the DHCPv6 page, I have the range set to 2001:xxxx:xxxx:6901::2 - 2001:xxxx:xxxx:6901::ffff.
From the Diagnostics screen, I can now ping ipv6.google.com but I still can not ping either the BBC IP listed above nor ipv6.google.com from a client machine. What am I missing?
-
What IP are you getting on the machine inside the LAN?
Check IP and default gateway. -
On the DHCPv6 page, I have the range set to 2001:xxxx:xxxx:6901::2 - 201:xxxx:xxxx:6901:ffff.
When trying to solicit help from someone remote, specific details and accuracy are important.
-
Ethernet adapter Ethernet:
Connection-specific DNS Suffix . : localdomain
IPv6 Address. . . . . . . . . . . : 2001:xxxx:xxxx:6901::f966
IPv6 Address. . . . . . . . . . . : 2001:xxxx:xxxx:6901:806a:e655:2a58:123
Temporary IPv6 Address. . . . . . : 2001:xxxx:xxxx:6901:e023:5e95:6d44:5c7b
Link-local IPv6 Address . . . . . : fe80::806a:e655:2a58:123%10
IPv4 Address. . . . . . . . . . . : 192.168.1.101
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : fe80::2e0:b6ff:fe13:6ea2%10
192.168.1.1This is what a client is getting. Thank you all very much for your help.
-
2 things:
-
Verify that the fe80::2e0:b6ff:fe13:6ea2 address you see actually belongs to the LAN interface on your pfSense.
-
Check DNS settings, does nslookup return the expected results?
eg:
Non-authoritative answer:
Name: ipv6.l.google.com
Address: 2607:f8b0:400b:809::200e
Aliases: ipv6.google.comLastly tracert -d ipv6.google.com, see how far it gets before stopping.
-
-
On the DHCPv6 page, I have the range set to 2001:xxxx:xxxx:6901::2 - 201:xxxx:xxxx:6901:ffff.
When trying to solicit help from someone remote, specific details and accuracy are important.
A said in my first reply to the OP that he cannot use 6901, see message 2 of this thread. His ISP is assigning him the following:
ISP: AT&T
IP Block: 2001:xxxx:xxxx:6900::/56
First usable: 2001:xxxx:xxxx:6900::2/56
Gateway: 2001:xxxx:xxxx:6900::1/56I have given up!
-
Of course he can use 6901.
You do not use a /56 on an interface, ever.
Split it into /64s however you want.
ISP: AT&T
IP Block: 2001:xxxx:xxxx:6900::/56
First usable: 2001:xxxx:xxxx:6900::2/56
Gateway: 2001:xxxx:xxxx:6900::1/56That is, essentially, nonsense from AT&T. But it should work.
-
There is a piece of the puzzle missing…Its kinda technical, so please bear with me while I attempt to explain it.
In a static IPv6 WAN configuration, if the provider is expecting /56 and you set /64 on the WAN interface (others have said setting /56 on the WAN interface is ridiculous; they are correct), the ISP assumes that 2001:xxxx:xxxx:6901:: is on the same L2 subnet, but it isn't because the subnets sizes don't match.
If and only if the provider were to have routed the remainder of the addresses 2001:xxxx:xxxx:6901 thru 2001:xxxx:xxxx:69ff to the 2001:xxxx:xxxx:6900::2 address would it actually work, and unless they told you to use 2001:xxxx:xxxx:6900::2 on your side, they have no clue what IP is your gateway, and wouldn't know where to route it to.In your case, if you ping google from a LAN side PC @ 2001:xxxx:xxxx:6901::2, the packet most likely gets to the intended destination, but the issue is with the return traffic. It has no way to figure out how to get back beyond the ISP.
The provider will send "ICMP6 neighbor solicitation who has 2001:xxxx:xxxx:6901::2" packets to ff02::1:ff00:2 on the WAN interface, but these are ignored.
The actual address used is ff02::1:ffxx:xxxx where xx:xxxx are the least significant 24 bits of the target IP, or 00:0002. If the LAN side PC was at 2001:xxxx:xxxx:6901:1234, then the "neighbor solicitation who has" packets would be going to ff02::1:ffcd:1234. Neighbor solicitation packets function similarly to ARP who-has, but are sent as multicast packets instead of broadcast to limit their spread. Nevertheless their functionality is similar; that is to map a MAC address to an IPv6 address. pfSense supports proxy ARP via Virtual IPs, but this support does not extend to IPv6.To put your issue into perspective from an IPv4 point of view, it would be the equivalent of the ISP allocating 100.64.96.0/20 to a client and having 100.64.96.1/20 on the ISP side and 100.64.96.2/24 on the client side (note the differing netmasks). The provider will send ARP who-has packets to try and figure out how to reach other hosts on the /20 subnet, but anything outside of the first /24 subnet (eg: 100.64.97.1) would be ignored by the firewall, unless it was told to proxy ARP for those IPs.
Dynamic WAN configuration would make much more sense, the ISP uses DHCP6 to give out a dynamic IPv6 address (it could also be a static IPv6 via DUID) to which a "statically" assigned IPv6 netblock is routed. At the ISP once the link is up, and the DHCP6 has run its course, a route is automatically added to their routing table for the /56 netblock VIA the assigned IPv6 address.
In a static only config there is just not enough info exchanged for the ISP to know where to send the traffic.
Talk to them and see what other types of config they support, because what you've got right now is kinda useless. -
In a static IPv6 WAN configuration, if the provider is expecting /56 and you set /64 on the WAN interface (others have said setting /56 on the WAN interface is ridiculous; they are correct), the ISP assumes that 2001:xxxx:xxxx:6901:: is on the same L2 subnet, but it isn't because the subnets sizes don't match.
Think of the /56 as 256 /64s. PfSense can pick select /64 for each LAN or VLAN interface.