Project

General

Profile

Bug #2882

6RD not working in latest snapshots

Added by Will Wainwright over 6 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
Normal
Category:
Interfaces
Target version:
Start date:
03/14/2013
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.1-IPv6
Affected Architecture:

Description

Hi guys,

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.

-Will

Associated revisions

Revision 7b83f723 (diff)
Added by Ermal Luçi over 4 years ago

Correct gateway for Ticket #2882 to the proper value as reported by: cmb

History

#1 Updated by Renato Botelho over 6 years ago

  • Category set to Interfaces
  • Target version set to 2.1
  • Affected Version set to 2.1-IPv6

#2 Updated by Chris Buechler about 6 years ago

  • Status changed from New to Feedback

should work with tomorrow's snapshot.

#3 Updated by Chris Buechler about 6 years ago

confirmed working for me again on the latest snapshot. Will leave this as is for feedback from others for now.

#4 Updated by Will Wainwright about 6 years ago

Hi Chris,

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.

-Will

#5 Updated by Captain Haddock about 6 years ago

I just tried this out on:

2.1-RC0 (amd64)
built on Wed Jun 12 18:24:47 EDT 2013
FreeBSD 8.3-RELEASE-p8

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 about 6 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

#7 Updated by Ermal Luçi about 6 years ago

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?

#8 Updated by Ermal Luçi about 6 years ago

Will Wainwright wrote:

Hi Chris,

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.

-Will

Can you please show an ifconfig of stf and the output of netstat -rn

#9 Updated by Captain Haddock about 6 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! :)

#10 Updated by Captain Haddock about 6 years ago

And that seemed to have been a user error on my part.

My IPv6 firewall rule on LAN had default (ipv4 dhcp) gateway set, changing this to WAN_6RD gateway solved my problems.

#11 Updated by Will Wainwright about 6 years ago

Hi Ermal

Here is the output of the 2 commands you asked me to run on my Jan 18th build where 6RD works:

http://pastebin.com/6t3g5uY0

and here is the output using the June 12th build:

http://pastebin.com/3TfjneUb

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.

-Will

#12 Updated by Will Wainwright about 6 years ago

Hi ermal,

Here is the requested command output:

http://pastebin.com/e7QrYfzG

And here are the config.xml sections:

http://pastebin.com/bqAFJjKW

-Will

#13 Updated by Ermal Luçi about 6 years ago

I think you should set your prefix to /64 in your wan configuration hence the problems.

Also the netstat command is netstat -r -n not m :)

#14 Updated by Will Wainwright about 6 years ago

Hi ermal,

Charter specifies the following setting for their 6RD service:

6rd Prefix = 2602:100::/32
Border Relay Address = 68.114.165.1
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.

-Will

#15 Updated by Will Wainwright about 6 years ago

Hi ermal,

I fired up my July 12th pfsense vm and "6RD IPv4 Prefix length" only goes from 0 to 31 bits.

netstat -r -n returns this:

http://pastebin.com/R6TZ9FUv

-Will

#16 Updated by Captain Haddock almost 6 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 68.114.165.1
6RD IPv4 Prefix length 0 bits.

There isn't any higher prefix in IPv4 than 32 bits.

#17 Updated by Will Wainwright almost 6 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.

-Will

#18 Updated by Will Wainwright almost 6 years ago

Hi guys,

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.

-Will

#19 Updated by Ermal Luçi almost 6 years ago

I have only seen that on misconfigurations of pfSense

#20 Updated by Will Wainwright almost 6 years ago

Hi Ermal,

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.

-Will

#21 Updated by Will Wainwright almost 6 years ago

Hi guys,

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".

#22 Updated by Will Wainwright almost 6 years ago

Hi guys,

I just updated my pfsense test vm to the Thu Aug 15 build and now I don't even get an ipv6 address on my outside interface.

-Will

#23 Updated by Phillip Davis almost 6 years ago

The first build on Thu Aug 15 had issues. The later build that day should be better:
2.1-RC1 (i386)
built on Thu Aug 15 16:30:19 EDT 2013
FreeBSD 8.3-RELEASE-p9

#24 Updated by Will Wainwright almost 6 years ago

Hello,

I assume the second build just fixes the new problem with the WAN interface not getting an address at all?

Any chance I could get some advice on how to go about fixing the problem originally detailed in this PR?

-Will

#25 Updated by Christopher Blake almost 6 years ago

Hello,

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:

2.1-RC1 (amd64)
built on Thu Aug 29 16:33:36 EDT 2013
FreeBSD 8.3-RELEASE-p10

#26 Updated by Renato Botelho almost 6 years ago

  • Status changed from Feedback to New

#27 Updated by Vince Maroun almost 6 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 = 205.171.2.64, 6RD IPv4 Prefix length = 0

#28 Updated by Chris Buechler almost 6 years ago

  • Target version changed from 2.1 to 2.2

6rd works in general, but there are issues due to the lack of proper v6 frag handling that makes it not functional in many practical uses. Have to push this one off for that reason.

#29 Updated by Will Wainwright almost 6 years ago

Hi Chris,

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?

-Will

#30 Updated by Christopher Blake almost 6 years ago

Kind of disappointing to see this get pushed out of the way for 2.1. You say this is due to the ISP having "lack of proper v6 frage handling".

Can you please elaborate on this? I would be glad to report this to my ISP to get this issue figured out.

#31 Updated by Will Wainwright almost 6 years ago

Hi Christopher,

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.

-Will

#32 Updated by Christopher Blake almost 6 years ago

Hi Will,
Thanks for the explanation. Really wish there was more information abut this, feels like we are being somewhat left in the dark by the developers, but I understand they have their plates full.

#33 Updated by Ermal Luçi about 5 years ago

Can anyone provide environment/VM with 6rd connectivity so i can debug/fix this?

Please do not forget to share even configuration information for this.

#34 Updated by Will Wainwright about 5 years ago

Hi Ermal,

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.

-Will

#35 Updated by Chris Buechler about 5 years ago

my test/dev system with 6rd is still up as well Ermal. Look up cmbhome-devfw1 in Lastpass.

#36 Updated by Wouter van Rooy about 5 years ago

I am also running in to this issue using the Dutch fiber ISP 'OnsBrabantnet'. If there is anything I can do or provide to help you fix this, please drop me a line.

#37 Updated by Jim Thompson about 5 years ago

  • Assignee set to Ermal Luçi

#38 Updated by Rune Darrud about 5 years ago

I've put up a bounty for this issue to be fixed in the near future (3 months of I dont update the post): https://forum.pfsense.org/index.php?topic=78216.0

#39 Updated by Will Wainwright almost 5 years ago

Hi guys,

I just gave the latest (built on Thu Aug 14 10:06:14) snap a try and it looks like 6RD still isn't working.

Is it expected that this will be fixed before 2.2 rolls?

-Will

#40 Updated by Hondo Eriksson over 4 years ago

I'm using the latest snapshot (amd64 built on Tue Oct 21 22:27:38 CDT 2014) and it seems like 6rd still isn't working.

I am also wondering if 6rd will be fixed until final release of 2.2?

#41 Updated by Chris Buechler over 4 years ago

  • Status changed from New to Confirmed
  • Assignee changed from Ermal Luçi to Chris Buechler
  • Affected Documentation 0 added

the kernel portion of this seems to be working fine in 2.2. There is an issue with the delegated prefix handling that I'm looking into.

#42 Updated by Chris Buechler over 4 years ago

Got a good deal of info gathered from OP's system, both from 2.2, and from a 2012 2.1 snapshot where 6rd works fine. I need to discuss with Ermal

#43 Updated by Ermal Luçi over 4 years ago

  • Status changed from Confirmed to Feedback

To be tested with new snapshots.

#44 Updated by Will Wainwright over 4 years ago

Hi guys,

No joy with 2.2-BETA (amd64) built on Tue Nov 18 14:41:54 CST 2014.

I guess I need to wait a little longer for the next build?

-Will

#45 Updated by Chris Buechler over 4 years ago

yeah that's not new enough

#46 Updated by Will Wainwright over 4 years ago

Hi guys,

Just tried with 2.2-BETA (amd64) built on Tue Nov 18 23:43:52 CST 2014 & the gateway monitor indicator is down & I'm failing all the tests at test-ipv6.com.

-Will

#47 Updated by Ermal Luçi over 4 years ago

Can you show ifconfig, nestat -rnf inet6 output and system logs ?

Or give me access to a test system with 6rd connectivity.

#48 Updated by Will Wainwright over 4 years ago

Hi Ermal,

The box is up right now. CMB knows how to get to it...he was poking around in it last Friday.

Feel free to take a look around....the box is a vm & I can easily revert it back.

-Will

#49 Updated by Chris Buechler over 4 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 over 4 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.

#51 Updated by Chris Buechler over 4 years ago

  • Status changed from Feedback to Resolved

others have also confirmed fixed

#52 Updated by Will Wainwright over 4 years ago

Hi Chris,

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.

-Will

#53 Updated by Ermal Luçi over 4 years ago

Will, i disabled the message it was a leftover from development times.
Thanks for reporting that.
You just need to updated to the next coming snapshots to have the log removed.

#54 Updated by Jarom Hatch over 4 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).

From pfsense:
$ 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
ipv6.l.google.com.
2607:f8b0:4009:80a::2000

Here's my ipv6 routing table (minus the link-local stuff)
$ netstat -rnf inet6
Routing tables

Internet6:
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

Also available in: Atom PDF