pfSense

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

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

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.

This was seen in log after reboot:

Jun 13 13:29:23 radvd⁴⁹⁴³⁶: resuming normal operation
Jun 13 13:29:23 radvd⁴⁹⁴³⁶: attempting to reread config file
Jun 13 13:29:12 radvd⁴⁹¹⁶⁵: IPv6 forwarding seems to be disabled, but continuing anyway.
Jun 13 13:29:12 radvd⁴⁹¹⁶⁵: IPv6 forwarding setting is: 0, should be 1
Jun 13 13:29:12 radvd⁴⁹¹⁶⁵: version 1.9.1 started
Jun 13 12:59:30 radvd²¹⁴²⁹: resuming normal operation
Jun 13 12:59:30 radvd²¹⁴²⁹: attempting to reread config file
Jun 13 12:59:24 radvd²¹²⁶⁸: version 1.9.1 started

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?

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

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! :)

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.

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

Hi ermal,

Here is the requested command output:

http://pastebin.com/e7QrYfzG

And here are the config.xml sections:

http://pastebin.com/bqAFJjKW

-Will

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

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

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

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.

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

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

I have only seen that on misconfigurations of pfSense

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

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

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

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

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

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

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

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

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.

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

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.

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.

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

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

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.

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

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

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?

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

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

yeah that's not new enough

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

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

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

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

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?

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.

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

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.

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