Ipv6 with Charter's 6RD service
I was just wondering if anyone has been able to get pfSense 2.1 to work with Charter's 6RD service?
I'm still running a 2.1 beta from way back in January 2013 and 6RD works great, but sometime after what I'm running something changed that made 6RD not work anymore. I have a ticket open here:
for the issue, but it's not due to be fixed until 2.2 ships.
Anyway, like I said I was just wondering if anyone else has some insight into what's wrong and had maybe found a way to get 6RD working.
Are you trying anything different with any different results? I've tried pretty much everything I can think of. Let's compare and see where we're both at, and figure out discrepancies.
-Can ping6 WAN and LAN interfaces
-Can ping internal devices on the LAN
-Cannot ping external devices on the WAN, (but CAN resolve DNS addresses like ipv6.google.com)
–EDIT: Can ping and access external IPv6 sites (ipv6.google.com) when WAN is set to "6to4 Tunnel"
-Has DNS manually set to Charter's IPv6 and Googles IPv4
-Can ping own IPv6 address AND link-local address
-Can ping pfSense LAN IPv6 interface address
-Can ping other LAN devices
-Cannot ping anything outside of the WAN, (but CAN resolve DNS addresses like ipv6.google.com)
-Have a Default Gateway set to a fe80::1:1%11 address
-Have DNS automagically set to LAN IPv6 address 2602xxxx:xxxx::1
My configuration on Charter Business with static IPv4 (Settings are per Charter's recommendations where applicable)
Interfaces - WAN
IPv6 Configuration Type = 6rd Tunnel
6rd Prefix = 2602:/32
Border Relay Address = 184.108.40.206
6RD IPv4 Prefix length = 0 bits
Interfaces - LAN
IPv6 Configuration Type = Track Interface
IPv6 Interface = WAN
IPv6 Prefix ID = 0
[ ]Block private networks
[ ]Block bogon networks
System - Advanced - Networking
Firewall - Rules
Proto src port dst prt gw
UDP6 * 547 * 546 *
ICMP6 * * * * *
IPv6 LAN * * * WAN_6RD
ICMP6 * * * * WAN_6RD
System - General Setup
220.127.116.11 WANGW 24.ipv4.ipv4.ipv4
18.104.22.168 WANGW 24.ipv4.ipv4.ipv4
2607:f428:1::5353:1 WAN_6RD - WAN - 2602XXXX:XXXX::68:114:165:1
2607:f428:2::5353:1 WAN_6RD - WAN - 2602XXXX:XXXX::68:114:165:1
Traceroute with 6rd (fails)
[2.1.2-RELEASE][email@example.com]/root(48): traceroute6 ipv6.google.com traceroute6 to ipv6.l.google.com (2607:f8b0:4009:807::1006) from 2602:100:18d5:134a::1, 64 hops max, 12 byte packets 1 * 2602:100:18d5:134a::1 562.991 ms !A *
Traceroute with 6-to-4 Tunnel (works)
[2.1.2-RELEASE][firstname.lastname@example.org]/root(30): traceroute6 ipv6.google.com traceroute6 to ipv6.l.google.com (2607:f8b0:4009:807::1002) from 2002:18d5:134a::, 64 hops max, 12 byte packets 1 * * * 2 infotech-gr-01-gi-1-0-4.northernlights.gigapop.net 28.968 ms 29.524 ms 26.496 ms 3 mtc-gr-01-te-2-1.northernlights.gigapop.net 28.968 ms 29.661 ms 27.961 ms 4 AS6939.micemn.net 44.963 ms 37.817 ms 33.714 ms 5 100ge7-1.core1.chi1.he.net 30.954 ms 30.415 ms 32.220 ms 6 google-as15169.10gigabitethernet7.switch2.chi1.he.net 27.344 ms 33.289 ms 29.971 ms 7 2001:4860::1:0:92e 32.221 ms 30.413 ms 39.961 ms 8 2001:4860:0:1::7c1 31.232 ms 34.349 ms 33.006 ms 9 2607:f8b0:8000:40::b 47.569 ms 2607:f8b0:4009:807::7 39.381 ms 2607:f8b0:8000:40::a 37.890 ms
So I can visit ipv6.google.com in a web browser via a client on the LAN after I switched from 6rd to 6-to-4 Tunnel under WAN, with no other changes (except LAN Firewall Gateway from WAN_6rd to WAN_6to4). Everything pings, everything works.
I think that's it. Let me know if I'm missing anything else that might be important.
No, I'm not tryinag anything different really. I have 6RD working like a champ on an old 2.1 build from January 2013 and I'm using the same settings that I've always been using. I have been running ipv6 through Charter for 2+ years with the setup described on the Charter 6RD page and was able to update through months of 2.1 builds before something changed and ipv6 never worked for me with any build after sometime in February 2013.
I've posted a number of times here in the forums with my observations since ipv6 stopped working and every once in a while a dev will replay with tidbit of information about whats going on but I've never really gotten a solid lead on how to solve this problem. I've been told it's an ipv6 fragmentation problem (which doesn't explain why it seems to work perfectly fine for me right now), that I have a "configuration error" (but never got a hint as to what might not be configured correctly) and most recently I was told all I have to do is change my default gateway to reside on wan_stf & that changing that should solve all my problems, but I don't see anywhere obvious in the GUI to make that change. Unfortunately the dev never returned to the thread and I have no idea where I would actually make that change.
That said, what you have looks right to me….honestly it was all of about 5 minutes worth of work to get 6RD working when I set it up initially & it's worked great on every build I tried till it got broken.
After perusing many other ipv6 threads, I've seen your posts time and time again. I'll keep pushing for this fix as well. I'll also keep tinkering when I have time to see if I can't find a place to make some of these changes via the CLI.
What is the build date & time that 6rd has been stable and working for you? I might compare changelogs, install that and the next available build that breaks 6rd and run some generalized diagnostics to check for anomalies.
Maybe we can get this narrowed down a bit and help the Devs help us.
2.1-BETA1 (amd64) built on Fri Jan 18 04:21:30 EST 2013
I was updating more or less every week on Friday so it shouldn't be more than 2 weeks after Jan 18th that it broke.
Personally I think it has to do with the switch to "wan_stf"…..if I could figure out where this mysterious gateway interface is I'd gladly change it over & see!
jjstecchino last edited by
I believe on the working 2.1 beta the 6rd gateway interface was <stf>after it was changed to <wan_stf>, 6rd was broken</wan_stf></stf>
6RD + Charter is confirmed working in 2.2.1-Release!
Thanks to Ermal, Chris & Will for following through with this
Feel free to read about the process: https://redmine.pfsense.org/issues/2882