6RD not working in latest snapshots
I use Charter's 6RD service to get ipv6 connectivity. I'm currently running the Jan 18th snapshot and my ipv6 connectivity is working fine. I usually update my pfsense version about once a week so when I updated near the end of January the 6RD connection didn't work so I rolled back the snapshot (running pfsense in an ESXi VM) and the 6RD connection started working again.
I just updated to the today's (Feb 27th) (also tried the March 12th) snapshot and it's still not working. It appears that I get an address from Charter on the WAN interface...I can see it listed in the console and in the GUI but my monitored gateway in the dashboard shows off-line and connectivity tests to test-ipv6.com and to ipv6.google.com both show ipv6 isn't working.
Here are some threads from the forum detailing some users having this issue:
http://forum.pfsense.org/index.php/topic,59461.0.html (Charter 6RD connection not working in latest snaps)
http://forum.pfsense.org/index.php/topic,58393.0.html (6RD not working)
http://forum.pfsense.org/index.php/topic,58965.0.html (6rd tunnel setup on Rogers)
that all seem to be describing the same thing.
I'm not exactly sure what information you need to help correct this....to be honest setting up the 6RD connection to Charter took all of 5 minutes and has "just worked" since then, but I'm happy to update my system and provide the results of whatever commands you need me to run or to provide remote access tot he firewall for some testing.
#5 Updated by Captain Haddock over 7 years ago
I just tried this out on:
built on Wed Jun 12 18:24:47 EDT 2013
After initially setting up 6RD it all went up fine.
Then I tried to reboot the system and after reboot the 6RD didn't come up.
So some progress has been made but I think there are some minor issues left to sort out.
Keep up the good work.
#6 Updated by Captain Haddock over 7 years ago
This was seen in log after reboot:
Jun 13 13:29:23 radvd49436: resuming normal operation
Jun 13 13:29:23 radvd49436: attempting to reread config file
Jun 13 13:29:12 radvd49165: IPv6 forwarding seems to be disabled, but continuing anyway.
Jun 13 13:29:12 radvd49165: IPv6 forwarding setting is: 0, should be 1
Jun 13 13:29:12 radvd49165: version 1.9.1 started
Jun 13 12:59:30 radvd21429: resuming normal operation
Jun 13 12:59:30 radvd21429: attempting to reread config file
Jun 13 12:59:24 radvd21268: version 1.9.1 started
#8 Updated by Ermal Luçi over 7 years ago
Will Wainwright wrote:
I'm sorry to report that it has not fixed the issue for me.
As always, please let me know if there's anything I can do or any information I can provide to help fix this.
Can you please show an ifconfig of stf and the output of netstat -rn
#9 Updated by Captain Haddock over 7 years ago
Ermal Luçi wrote:
You are talking about tracking interfaces or 6rd tunnel here?
radvd has nothing to do with 6rd in this ticket.
This is about plain 6rd connectivity, can you please clarify?
Well, I was talking about both actually. Sorry for the confusion.
As you said this bug is about plain 6RD and as such I would say it has been fixed.
I can reach ipv6.google.com using WAN as source address but not from LAN so I guess that belongs in a track interface bug instead.
Nice fix on 6RD though! :)
#11 Updated by Will Wainwright over 7 years ago
Here is the output of the 2 commands you asked me to run on my Jan 18th build where 6RD works:
and here is the output using the June 12th build:
The one interesting thing is the June 12th setup doesn't have an stf0 interface, it has a wan_stf instead.
This is a straight upgrade using the auto-update feature from Jan 18th to June 12th.
#14 Updated by Will Wainwright over 7 years ago
Charter specifies the following setting for their 6RD service:
6rd Prefix = 2602:100::/32
Border Relay Address = 18.104.22.168
6rd prefix length = 32
IPv4 mask length = 0
I'll give the /64 prefix a shot and let you know how it goes, I'll also post the correct output of netstat.
#16 Updated by Captain Haddock over 7 years ago
Wel, Will. It seems as if you misunderstand the configuration options.
If Charter say IPv4 mask length = 0 that equals to the "6RD IPv4 Prefix length" settings in pfSense, and you should set it at 0.
The other options I guess would be set as such:
6RD prefix: 2602:100::/32
6RD Border Relay 22.214.171.124
6RD IPv4 Prefix length 0 bits.
There isn't any higher prefix in IPv4 than 32 bits.
#17 Updated by Will Wainwright over 7 years ago
Hi Wet Willy,
I was only trying something ermal suggested.
Really the only thing I can say is that the firewall works great with 6rd configured per the Charter docs with pfesense 2.1 prior to ~mid January. Using that same config on anything after that has not worked for me.
#18 Updated by Will Wainwright over 7 years ago
For grins I opdated to the Sat Jul 27 build, ssh'ed into the firewall and and fired up "tcpdump -i vmx3f0 -vv ip6" (my outside interface) then went to http://test-ipv6.com/ and ran a test. Tcpdump reported nothing. Doing the same on vmx3f1 (my inside interface) produced all sorts of chatter. I still got a 0/10 on the test, but it sure looks like pfsense isn't passing the packets through to the outside.
Am I just doing something stupid like not including some default pass rule? I'm using the same config that works great with 6rd on my mid-January build which has a very simple ruleset.
#20 Updated by Will Wainwright over 7 years ago
I don't quite understand your response.
I assume you mean that I have a mis-configured ruleset? If so, could you maybe give me a hint about what rule I might be missing? Keep in mind that I'm still rocking along with my mid-January build & it works great, but if I install a current snap and upload the same config 6rd doesn't work.
#21 Updated by Will Wainwright over 7 years ago
I spun up my "current" pfsense vm the other day, grabbed the output of "pftop -w 150 -a -b -v rules" via the /status.php page on both my January (working) vm & the latest release as of last Saturday. I took the output from each and stuffed them into notepad++, edited out all the traffic counters & diffed them. There are 3 extra rules in the "current" rules that aren't in my January ruleset:
100 Pass In Q vmx3f1 K 0 0 0 inet from 10.56.56.0/24 to any flags S/SA
101 Pass In Q vmx3f1 K 0 0 0 inet6 from 2602:XXXX:XXXX:XXXX::/64 to any flags S/SA
102 Pass In Q vmx3f1 udp K 0 0 0 inet6 from fe80::/64 to ff02::1:3/128 port = 5355
Maybe that's where the problem is, maybe it's not....I have no idea. All the other rules seem to differ only in the change between "wan_st" & "stf0".
#25 Updated by Christopher Blake over 7 years ago
Having the same issue here. I also have Charter for my carrier. I am able to get a IPv6 IP, but am unable to ping, or visit any IPv6 website.
Currently running the following build:
built on Thu Aug 29 16:33:36 EDT 2013
#27 Updated by Vince Maroun over 7 years ago
Same issue here.
Using CenturyLink for 6RD so not limited to Charter. Upgraded from an August 2012 build to Sun Jul 28 13:41:21 EDT 2013 via auto-update method. Haven't upgraded beyond since I've been following forum thread: http://forum.pfsense.org/index.php/topic,58393.15.html
CenturyLink's setup: 6RD prefix = 2602::/24, 6RD Border Relay = 126.96.36.199, 6RD IPv4 Prefix length = 0
#29 Updated by Will Wainwright over 7 years ago
Well that's quite the disappointing news.
Any chance you could just roll back whatever changes were made back in January when 6RD was working?
How about a timeline for when we might see a build of 2.2 that features a working 6RD implementation?
Are we looking at months or years before something that supports 6RD that works is available?
What changed back in January that made these problems occur anyway?
#31 Updated by Will Wainwright about 7 years ago
I don't read Chris' response as a problem with the ISP, I think it's a problem with pfSense that wasn't able to be sorted before 2.1 was released. I can tell you my pfSense install from way back in January is still working like a champ with my Charter connection, while builds since then simply don't so if there was a problem with the ISP I suspect 6RD wouldn't have ever worked.
That said, I'm dying for this to get fixed before Charter actually rolls out proper ipv6 support and makes working 6RD support redundant.
#34 Updated by Will Wainwright over 6 years ago
I'd be thrilled to spin up a vm and let yo take a look.
Please tell me what you want (2.1.3, 2.2, something else) and I'll set it up. You can contact me via PM (just message survive) on the pfSense forums & we can work out a time so you can do what you need to do.
#49 Updated by Chris Buechler about 6 years ago
That did mostly fix it, it's missing adding the default gateway though. I manually added it to Will's system and everything seems fine now, the problem it had before is definitely gone. Need to fix that default gateway issue.
Will, does your internal network seem to be able to get out on v6 now?
#50 Updated by Chris Buechler about 6 years ago
Will, I gitsynced your system and rebooted to confirm it's correct now. Looks to work fine now, it came up on its own no problem after the last gateway issue was fixed. I also now see hosts on your internal network communicating out via v6 to some locations and judging by the states, they're successful.
Leaving to feedback for now, but pretty sure this is all good.
#52 Updated by Will Wainwright about 6 years ago
I can confirm that my ipv6 connection appears to be working!
I am seeing one thing new. There is a message repeating on the console that says:
Wrong decoded address abe5cf18/550e6b18!!!!
at the rate of tens per hour with one user doing some web browsing.
#54 Updated by Jarom Hatch almost 6 years ago
I've been trying to get this working for a week now with no success. I have the latest (as of tonight) snapshot installed and still no joy. My machines on the LAN get an ipv6 address that matches what the router has assigned to it (I am currently on Centurylink). I can ping the router from my laptop and vise-versa, but I cannot ping the gateway address (2602:cdab:240::) and thus, nothing beyond my network (though I can resolve names).
$ ping6 -c1 2602:cdab:240::
ping6: UDP connect: No route to host
$ ping6 -c1 ipv6.google.com
ping6: UDP connect: No route to host
From my laptop:
$ ping6 -c1 2602:cdab:240::
PING 2602:cdab:240::(2602:cdab:240::) 56 data bytes
From 2602:XX:XXXX:XX00::1 icmp_seq=1 Destination unreachable: No route
$ ping6 -c1 ipv6.google.com
PING ipv6.google.com(pe-in-x65.1e100.net) 56 data bytes
From pe-in-x65.1e100.net icmp_seq=1 Destination unreachable: No route
$ dig AAAA +short ipv6.google.com
Here's my ipv6 routing table (minus the link-local stuff)
$ netstat -rnf inet6
Destination Gateway Flags Netif Expire
::1 link#5 UH lo0
2602::/24 link#10 U wan_stf
2602:XX:XXXX:XX00:: link#10 UHS lo0
2602:XX:XXXX:XX00::/64 link#1 U re0
2602:XX:XXXX:XX00::1 link#1 UHS lo0