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.
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
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.
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.
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.
I find it out. I put in the wrong WAN Prefix on the WAN Interface. Now I can reach the Internet with IPv6. ;) ;) ;) ;)
The LAN Adapter is for internal uses.
The OPT1 is now for testing. :) I have a vCloud Director installation behind.
Every machine in the Cloud need one IPv4 and one IPv6. Webserver or something like that will be only v6 reachable. But the machines must also reach the Internet with IPv4.
Because of this reason I have such a big range on the OPT1.
My bad!
I noticed an IPv6 rule that did not allow undefined address access to the fw.
After I explicitly created a rule for this case, pfSense responds with RA after the RS mentioned above.
A am using get as well, and I am considering to upgrade my main FW to 2.1 as well, but in the mean time I have it installed on a test box with tunneling to NetAssist where I get a /48 network and a static ip on WAN.
With get.no, I've read that you get a /60 prefix, and DHCP allocated IP. With the "Track Interface" setting, are you able to set a /64 network on the LAN side and enable SLAAC? How does that work?
I don't think it sounded strange :-) Just found it interesting that they are now starting a push and saying the norm now should be IPv6 and IPv4 is just and option. The logic is clear enough, the problem has always been when they would do something like this.
2.0.1 does not have IPv6 support, never has. 2.1 does.
There used to be some old gitsync instructions that would turn a 2.0.1 box into a 2.1 box but those haven't been valid for at least the last 5-6 months or so.
Wow yeah, that's one heck of a path. Judging by the latency, I suspect that is accurate. I'm in Austin at the moment and I have basically the exact same connectivity and latency to that .42 host as you have, about 50 ms, +/- 5 ms. I'm going ATX > DAL > LA > PHX > DAL. Terrible path…
One of our developers is about 40 miles outside of Chicago, to get to the Chicago HE.net endpoint, his traffic goes to NYC and back. At home I'm about 300 miles away from Chicago using the same one, and my latency is about the same if not a little better than his. Not always the best routing in the world on those, unfortunately...
