OK, well then next time you get a chance, try it. If we don't get better info on how it broke, it will never get solved.

Did clean install with today's snapshot 1/29. Seems to be working fine now. Not sure what was the problem with 1/28 snapshot.

It could be possible in the future if we discover some sort of "proxy NDP" type daemon for FreeBSD that would arbitrarily respond to NDP requests for an entire prefix.

IPv6 really doesn't like NAT though. The intent was to route everything as much as possible and do no NAT.

It has been requested, and there is a chance we may do it for 2.2, but it won't be in 2.1.
http://redmine.pfsense.org/issues/2358

Ah, yeah I see.

Well when you do ping6 with -I it does that, but not with -S.

If you use -S (ip) then it will send it the right way, but the error is usually a bit different.

: ping6 -I em0 www.google.com  PING6(56=40+8+8 bytes) 2001:xxxx:xxxx:xxxx::1 --> 2607:f8b0:4003:c01::69 ping6: sendmsg: No route to host ping6: wrote www.google.com 16 chars, ret=-1 ping6: sendmsg: No route to host ping6: wrote www.google.com 16 chars, ret=-1 : ping6 -S 2001:xxxx:xxxx:xxxx::1 www.google.com    PING6(56=40+8+8 bytes) 2001:xxxx:xxxx:xxxx::1 --> 2607:f8b0:4003:c01::69 16 bytes from 2607:f8b0:4003:c01::69, icmp_seq=0 hlim=57 time=69.442 ms 16 bytes from 2607:f8b0:4003:c01::69, icmp_seq=1 hlim=57 time=66.597 ms

IPV6 definitely works for a single endpoint and has worked now for over a year with a directly connected Linux boxes that doesn't have a firewall between it and the ISP.  Works fine on a windows XP box as well.

It is time to go find someone at the ISP to talk to.

Thanks again for all of your replies.

Just to make this clear, you can do this, but you will lose SLAAC. And thus computers will no longer auto configure a IPv6 address.

Ofcourse setting up RA combined with a DHCP6 server will make this work, provided that all clients support static addressing (yes) or DHCP6 (no).

Don't expect your phone to whizz into IPv6 action.

Awesome thanks! I'll upgrade asap.

We just checked in a fix for this, get a snapshot dated january 6th or later please.
We changed the DHCP6 client back to the WIDE client which should work better.

Figured out the cause.  Had a firewall rule with IPv6 specified.

http://redmine.pfsense.org/issues/2129

So there is some more info

Clearly its not protocol NONE Like the firewall log is saying, I captured some packets

Protocols in frame: eth:ipv6:icmpv6

My question is really what would be the best type of rule to not log this sort of traffic.  It's noise in the log.  And why is the protocol not listed correctly?  BTW running

2.1-BETA1 (i386)
built on Fri Dec 28 20:54:16 EST 2012
FreeBSD 8.3-RELEASE-p5

captureblocked.png
captureblocked.png_thumb
whyblocked.png
whyblocked.png_thumb

I tried pinging opendns servers using their ipv6 address from both the clients and pfSense (WAN interface) but got nothing back. When pinging from the clients I can see it go through (I enabled logging on the LAN rule for ipv6 traffic), but then I see traffic from the opendns ipv6 being blocked on the WAN.

i did all the upgrades till now , no fix yet , i'll guess we'll have to be pacient.

Hi darkcrucible,

Does the LAN interface on your pfsense box have an IPv6 address or is it just the WAN?

Both my WAN and LAN have IPv6 addresses - http://i.imgur.com/I75bC.png

What does Status->Services show?

Everything seems to be running unless a service is missing - http://i.imgur.com/o7rBS.png

Thanks!

Edit:

darkcrucible – I have to say thanks! Looking at the services page made me wonder if snort was causing me issues. Disabling it allowed my devices to start working on IPv6 and passing the IPv6 test. I'm still rocking the 2001: address however.

Edit Again:

I take back the last part, it looks like snort was entirely to blame. Everything is back to normal with a /64 now.

Turns out there is a device or two on the network here that wont work with ipv6, so I've had to turn off the ipv6 stuff for now :(

Mainly the FetchTV box and the printer, the moment both IPV4 & IPV6 are being advertised, those 2 devices stop working

All good, without ipv6 running now, the network is running rather nicely

Im rather liking the uptime :D

Screenshot.png
Screenshot.png_thumb

Client has not been replaced yet. I have not managed to put in the time yet.

Yes the subnets have to be the same length - but since most ISPs will be handing you a /64 it probably won't be an issue.

Not sure if there will be NAT for IPv6. It would have to be added into pf, I don't think it's currently supported there. It's really not necessary in most cases. People who have thought they needed it, really turned out to have an ISP deploying a broken/non-compliant setup and it was the ISP that needed fixing, not the client…

So far the only interesting use-case I've seen for it is the possibility of doing transparent proxying, since that requires a port forward to function.