Comcast 6to4 how-to?
-
I'm going to admit ignorance at this point, especially since I don't use 6to4 myself. I will point out that RFC 2893, which is mentioned in the UI, is a document on IPv6 transition mechanisms in general. I always thought that 6to4 was (is) RFC 3056. So color me confused!
Bruce.
-
6RD is something that some ISPs are rolling out and some time is spent on that.
Actual dual stack is the way forward and Comcast will be rolling that out. You can activate the DHCP6 client on your WAN if your area already supports this. I'm not sure how far the deployment on the Comcast side is.
Considered 6to4, never attempted it yet. Not tried to see what that field does either, I really should. It's not for 6to4 though.
-
Just a quick update, Comcast 6to4 now works after support was added to pfSense on April 1st. Using the instructions here: http://forum.pfsense.org/index.php/topic,47872.0.html
Comcast dual-stack is still only available in a few markets and mine (Portland, OR) is not one of them. Info here: http://www.comcast6.net/
FWIW, don't expect any blazing speeds from Comcast 6to4. Speed is much lower and latency is much higher than IPv4. See attached screenshots.
-
Thanks for the positive report on the 6to4 support!
Glad it works for you.
-
I was also trying to set this up on comcast, and I've had a bit of trouble. The Status -> Gateway screen shows the connection is online, and I can ping the gateway IPv6 address from pfSense. None of my PCs are able to ping any IPv6 address, though it looks like IPv6 name resolution is working. At least, when I ping ipv6.google.com, the address is resolved with either no reply or destination unreachable. That may be cached on the computer, because I can't ping the same address from pfSense. I setup my connection with these instructions from another thread:
Select IPv6 configuration type "6to4" on the WAN.
Select IPv6 configuration type "Track interface" on the LAN.
Select the WAN interface here and a number instead of "none"I had previously setup a SixXS tunnel, but I've deleted all those settings, just in case. I'm running the April 10th snapshot. This might be unrelated, but on a reboot, I get this crash log.
Crash report begins. Anonymous machine information: i386 8.3-RELEASE FreeBSD 8.3-RELEASE #1: Tue Apr 10 21:11:25 EDT 2012 root@FreeBSD_8.3_pfSense_2.1.snaps.pfsense.org:/usr/obj./usr/pfSensesrc/src/sys/pfSense_SMP.8 Crash report details: PHP Errors: [11-Apr-2012 16:27:14 UTC] PHP Parse error: syntax error, unexpected '=' in - on line 42
I have a firewall rule set to allow all IPv6 traffic from the LAN. I'm really not sure where to look from here. Any ideas?
EDIT: I can now ping the Gateway IP of the IPv6 interface. I haven't changed anything. I'm not sure why that started working, but I still get Destination Unreachable for anything else. DNS appears to be resolving, but no other traffic is passed.
EDIT2: I figured out how to fix the problem. Turns out, the default route for IPv6 is never created. I can manually execute "/sbin/route -n add -inet6 default [Gateway IP]" and it starts working. Any idea why this is happening, or what I can do to stop it? This might be a clue:
php: : The command '/sbin/route change -inet6 default '2001:1938:80:1fb::1'' returned exit code '1', the output was 'route: writing to routing socket: No such process route: writing to routing socket: Network is unreachable change net default: gateway 2001:1938:80:1fb::1: Network is unreachable'
Also, for some reason the IPv4 gateway has disappeared from the webgui. I can still see it with netstat, and IPv4 still works. It's just not in the webgui under System -> Routing or Status -> Gateways.
-
sorry for not reporting earlier:
I tested with the April 9th snapshot and Comcast 6to4 was broken there as well (vs. April 2nd snapshot where it worked OK). Same issues as mrhanman.Reverted back to April 2nd snapshot for now, since I see a lot of commits still happening to IPv6 handling code.
databeestje: I can flip back and forth between slices (April 2nd known-good vs. April 9th or later) if you need any data collected. Please let me know how I can help.
-
Thank you. I will check on this later.
-
The default gateways for IPv6 referenced above is not the standard 6to4 relay address.
Are you confused with 6rd?
The php error on line 42 from std input and not even a file makes this really weird.I think the snap you have is broken. Just not sure what exactly.
-
OK, I'll try today's snapshot and let you know what is/isn't working.
-
Using the latest Snapshot: 2.1-DEVELOPMENT (i386) built on Fri Apr 13 00:07:05 EDT 2012
I can ping the IPv6 Gateway, but nothing beyond it.
[2.1-DEVELOPMENT][root@fw.popovetsky.com]/root(1): ping6 2002:c058:6301::1 PING6(56=40+8+8 bytes) 2002:1815:7e8a:: --> 2002:c058:6301::1 16 bytes from 2002:c058:6301::1, icmp_seq=0 hlim=64 time=28.143 ms 16 bytes from 2002:c058:6301::1, icmp_seq=1 hlim=64 time=29.553 ms 16 bytes from 2002:c058:6301::1, icmp_seq=2 hlim=64 time=29.808 ms 16 bytes from 2002:c058:6301::1, icmp_seq=3 hlim=64 time=29.654 ms 16 bytes from 2002:c058:6301::1, icmp_seq=4 hlim=64 time=30.774 ms ^C --- 2002:c058:6301::1 ping6 statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 28.143/29.586/30.774/0.842 ms [2.1-DEVELOPMENT][root@fw.popovetsky.com]/root(2): ping6 ipv6.google.com ping6: UDP connect: No route to host
Netstat shows no IPv6 default gateway
Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UH lo0 2002::/16 link#10 U stf0 2002:1815:7e8a:: link#10 UHS lo0 => 2002:1815:7e8a::/64 link#1 U vr0 2002:1815:7e8a::1 link#1 UHS lo0 fe80::%vr0/64 link#1 U vr0 fe80::20d:b9ff:fe24:7288%vr0 link#1 UHS lo0 fe80::%vr1/64 link#2 U vr1 fe80::20d:b9ff:fe24:7289%vr1 link#2 UHS lo0 fe80::%vr2/64 link#3 U vr2 fe80::20d:b9ff:fe24:728a%vr2 link#3 UHS lo0 fe80::%lo0/64 link#7 U lo0 fe80::1%lo0 link#7 UHS lo0 fe80::%ovpns1/64 link#12 U ovpns1 fe80::2bd:f9ff:fe0a:1%ovpns1 link#12 UHS lo0 ff01::%vr0/32 fe80::20d:b9ff:fe24:7288%vr0 U vr0 ff01::%vr1/32 fe80::20d:b9ff:fe24:7289%vr1 U vr1 ff01::%vr2/32 fe80::20d:b9ff:fe24:728a%vr2 U vr2 ff01::%lo0/32 ::1 U lo0 ff01::%ovpns1/32 fe80::2bd:f9ff:fe0a:1%ovpns1 U ovpns1 ff02::%vr0/32 fe80::20d:b9ff:fe24:7288%vr0 U vr0 ff02::%vr1/32 fe80::20d:b9ff:fe24:7289%vr1 U vr1 ff02::%vr2/32 fe80::20d:b9ff:fe24:728a%vr2 U vr2 ff02::%lo0/32 ::1 U lo0 ff02::%ovpns1/32 fe80::2bd:f9ff:fe0a:1%ovpns1 U ovpns1
Manually adding inet6 default gateway fixes it
[2.1-DEVELOPMENT][root@fw.popovetsky.com]/root(9): route add -inet6 default 2002:c058:6301::1 add net default: gateway 2002:c058:6301::1 [2.1-DEVELOPMENT][root@fw.popovetsky.com]/root(10): ping6 ipv6.google.com PING6(56=40+8+8 bytes) 2002:1815:7e8a:: --> 2001:4860:8005::93 16 bytes from 2001:4860:8005::93, icmp_seq=0 hlim=56 time=39.839 ms 16 bytes from 2001:4860:8005::93, icmp_seq=1 hlim=56 time=38.709 ms 16 bytes from 2001:4860:8005::93, icmp_seq=2 hlim=56 time=38.661 ms 16 bytes from 2001:4860:8005::93, icmp_seq=3 hlim=56 time=39.027 ms 16 bytes from 2001:4860:8005::93, icmp_seq=4 hlim=56 time=38.721 ms ^C --- ipv6.l.google.com ping6 statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 38.661/38.991/39.839/0.443 ms
-
I can corroborate irvingpop's results with the Apr 13th snapshot.
-
I have not yet found the time to debug this yet, it should be adding a new default route. But it isn't
-
Can not replicate on a static IPv4 wan, need to try dhcp later. It does add the static route for me, and the gateways also still exist.
-
OK, I've got a strange new problem. I updated to today's snaphot, added the ipv6 gateway as default ipv6 route manually, and now my computers can ONLY browse by ipv6 - ipv4 isn't working at all. I can ping either ipv6 or ipv4 addresses from pfSense. It looks like the DHCP server on pfSense may not be handing out the default gateway for ipv4 networks. Once I added the ipv4 default route manually on my windows box, ipv4 worked fine. ::)
EDIT: Looks like I can't connect to the webConfigurator, now. Not sure what's up with that, unless it's not listening on ipv4.
-
I just updated 2 installs with the latest snapshot and i'm not seeing anything like your issues.
May I suggest that your install is hosed? I can't even resemble anything close to your issues.
I did just commit a change that would disable the IPv4 gateway in the DHCP4 server but that is a very specific change that would only bite you if you had no ipv4 gateways at all. Dynamic or otherwise.
-
I managed to get a install online on a public IP with dhcp and I managed to replicate your issue. Seems like a timing issue.
-
Easily fixed?
-
I think it is now, I changed the default gateway address, as well as configuring the interface before trying to configure routing is generally a good idea.
fixed rc.newwanip and function interface_6to4_configure();
-
configuring the interface before trying to configure routing is generally a good idea.
;)
So, just a gitsync, and off to the races?
-
yep, no binary changes required