6rd support added
-
Yes that is the issue.
Which version of pfSense is this ? -
2.2 RC Dec 17 snapshot.
Retried fresh install, removed carp, just in case it was messing up things, turned off backup pfsense box. running plain vanilla box now. wanstf still not passing traffic. all the config seems ok to me so I dont understand. The centurylink 6rd gateway does not respond to ping by their choice so there is no way to see if it is alive but I would be surprised if it is not (google search would have turned up at least some complaints and it has not).I then updated firmware of the dsl bridge just in case but still no go. The dsl modem is a bridge working below level 3 so it shouldn't matter anyway.Next step I guess it would be to set up a freebsd or linux vm with 2 interfaces and try to setup a link from the command line. Any suggestion before I do that?
-
OK new hardware, same problem.
I updated my firewall from a firebox x-core to a supermicro A1SRi-2758F (very very nice setup for pfsense). Now running AMD64 version full install.
I also upgraded my dsl to a bonded ADSL and centurylink gave me a new ADSL actiontec modem. Before bridging the modem I tested 6rd with the parameters I am using for pfsense and worked flawlessly.
I tried again with the pfsense new install after bridging the dsl modem and it is a no go. Same sets of errors I had with the firebox and nanobsd setup.
Is anybody else on centurylink having a problem or is it just me?As always, any help is appreciated.
-
Hi jjstecchino
I just tried to setup 6rd with centurylink on a spare DSL connection and ran into the the same problem you have. This was 2.2-RELEASE on embedded.
Just wanted to confirm its not just you.
If anyone has any suggestions, I'm willing to test as this is a mostly unused circuit.
Jan 24 07:59:27 gw-evergreen-dsl0 php-fpm[54847]: /interfaces.php: The command '/sbin/route change -inet6 default 2602:cdab:240::'' 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 2602:cdab:240:: fib 0: Network is unreachable'//b
-
That usually comes out since there is not subnet to match it with even though that subnet should be on the stf interface.
Can you please try to see why that route fails.
-
FYI since the Dec 31st build, IPv6 6rd has been working great! Updated a week ago to a newer build and it still works.
-
For me its not entirely clear how this should work, however when playing around I managed to get IPv6 packets flowing by means of a copy and paste error.
For starters, Centurylink says 2602::/24 with CE mask length of 0 for 6rd.
As previously mentioned, the problem seems to be with setting the default gateway. Here's how things look after a reboot. LAN interface IPv6 is set to Track WAN with the Prefix ID set to ff <–- this seems to matter.
wan_stf: flags=4001 <up,link2>metric 0 mtu 1280 inet6 2602:48:a010:5c00:: prefixlen 24 nd6 options=1 <performnud>v4net 72.160.16.92/32 -> tv4br 205.171.2.64 vr0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500 options=8280b <rxcsum,txcsum,vlan_mtu,wol_ucast,wol_magic,linkstate>ether 00:0d:b9:23:f0:d4 inet 172.18.128.1 netmask 0xfffffe00 broadcast 172.18.129.255 inet6 fe80::1:1%vr0 prefixlen 64 scopeid 0x1 inet6 2602:48:a010:5cff::1 prefixlen 64 nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (100baseTX <full-duplex>) status: active Internet6: Destination Gateway Flags Netif Expire ::1 link#7 UH lo0 2602::/24 link#9 U wan_stf 2602:48:a010:5c00:: link#9 UHS lo0 2602:48:a010:5cff::/64 link#1 U vr0 2602:48:a010:5cff::1 link#1 UHS lo0 fe80::%vr0/64 link#1 U vr0 fe80::1:1%vr0 link#1 UHS lo0 fe80::%vr1/64 link#2 U vr1 fe80::20d:b9ff:fe23:f0d5%vr1 link#2 UHS lo0 fe80::%lo0/64 link#7 U lo0 fe80::1%lo0 link#7 UHS lo0 fe80::%pppoe1/64 link#8 U pppoe1 fe80::20d:b9ff:fe23:f0d4%pppoe1 link#8 UHS lo0 fe80::%ovpnc1/64 link#10 U ovpnc1 fe80::2%ovpnc1 link#10 UHS lo0 fe80::20d:b9ff:fe23:f0d4%ovpnc1 link#10 UHS lo0 ff01::%vr0/32 fe80::1:1%vr0 U vr0 ff01::%vr1/32 fe80::20d:b9ff:fe23:f0d5%vr1 U vr1 ff01::%lo0/32 ::1 U lo0 ff01::%pppoe1/32 fe80::20d:b9ff:fe23:f0d4%pppoe1 U pppoe1 ff01::%ovpnc1/32 fe80::20d:b9ff:fe23:f0d4%ovpnc1 U ovpnc1 ff02::%vr0/32 fe80::1:1%vr0 U vr0 ff02::%vr1/32 fe80::20d:b9ff:fe23:f0d5%vr1 U vr1 ff02::%lo0/32 ::1 U lo0 ff02::%pppoe1/32 fe80::20d:b9ff:fe23:f0d4%pppoe1 U pppoe1 ff02::%ovpnc1/32 fe80::20d:b9ff:fe23:f0d4%ovpnc1 U ovpnc1</full-duplex></performnud,auto_linklocal></rxcsum,txcsum,vlan_mtu,wol_ucast,wol_magic,linkstate></up,broadcast,running,simplex,multicast></performnud></up,link2>The error reported on boot points to an attempt to add 2602:cdab:240:: as the default route. When I attempt to run this manually, I get the same error:
[2.2-RELEASE][admin@gw-evergreen-dsl0.internal.avioc.org]/root: /sbin/route change -inet6 default '2602:cdab:240::' route: writing to routing socket: No such process route: writing to routing socket: Network is unreachable change net default: gateway 2602:cdab:240:: fib 0: Network is unreachableOk, that seems to be a correct error I think, that GW seems to fall outside the 2602::/24 subnet, I'm not sure how the GW is calculated or provided in 6rd.
Now, When playing with adding the route, on accident I set the default GW to be the IPv6 address on the wan_stf interface:
[2.2-RELEASE][admin@gw-evergreen-dsl0.internal.avioc.org]/root: /sbin/route change -inet6 default 2602:48:a010:5c00:: route: writing to routing socket: No such process change net default: gateway 2602:48:a010:5c00::And much to my surprise, IPv6 packets are now flowing…
[2.2-RELEASE][admin@gw-evergreen-dsl0.internal.avioc.org]/root: ping6 -c3 www.pfsense.org PING6(56=40+8+8 bytes) 2602:48:a010:5c00:: --> 2610:160:11:11::69 16 bytes from 2610:160:11:11::69, icmp_seq=0 hlim=57 time=93.191 ms 16 bytes from 2610:160:11:11::69, icmp_seq=1 hlim=57 time=91.931 ms 16 bytes from 2610:160:11:11::69, icmp_seq=2 hlim=57 time=93.228 ms --- www.pfsense.org ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 91.931/92.783/93.228/0.603 msI guess if nothing else this proves that the underlying IPv6/6RD is working, just need to figure out how to get the default route/gw set correctly.
-
For the case of Centurylink, it appears the default gateway is not correct. pfSense is trying to set it to 2602:cdab:240:: but it should be 2602
ab02:4000:: based on this blog post: http://blog.switchedbits.net/2014/05/ipv6-6rd-tunnel-with-centurylink/As seen below, the route change works with this new value:
[2.2-RELEASE][admin@gw-evergreen-dsl0.internal.avioc.org]/root: /sbin/route change -inet6 default 2602:cdab:240:: route: writing to routing socket: Network is unreachable route: writing to routing socket: Network is unreachable change net default: gateway 2602:cdab:240:: fib 0: Network is unreachable [2.2-RELEASE][admin@gw-evergreen-dsl0.internal.avioc.org]/root: /sbin/route change -inet6 default 2602:cd:ab02:4000:: change net default: gateway 2602:cd:ab02:4000:: [2.2-RELEASE][admin@gw-evergreen-dsl0.internal.avioc.org]/root:And IPv6 works. So it seems the default route is being incorrectly computed?
Hope this helps.
-
If you put you subnet as 2602:00:/24 does it work?
-
Can you also try this patch and let me know if it works?
diff --git a/etc/inc/interfaces.inc b/etc/inc/interfaces.inc index 76d2921..f7fb1a3 100644 --- a/etc/inc/interfaces.inc +++ b/etc/inc/interfaces.inc @@ -3296,7 +3296,11 @@ function interface_6rd_configure($interface = "wan", $wancfg) { $rd6prefix = explode("/", $wancfg['prefix-6rd']); $rd6prefixlen = $rd6prefix[1]; $brgw = explode('.', $wancfg['gateway-6rd']); - $rd6brgw = rtrim($rd6prefix[0], ':') . ':' . dechex($brgw[0]) . dechex($brgw[1]) . ':' . dechex($brgw[2]) . dechex($brgw[3]) . '::'; + $rd6brgw = substr(Net_IPv6::_ip2Bin($rd6prefix[0]), 0, $rd6prefixlen); + $rd6brgw .= decbin($brgw[0]) . decbin($brgw[1]) . decbin($brgw[2]) . decbin($brgw[3]); + if (strlen($rd6brgw) < 128) + $rd6brgw = str_pad($rd6brgw, 128, '0', STR_PAD_RIGHT); + $rd6brgw = Net_IPv6::compress(Net_IPv6::_bin2Ip($rd6brgw)); unset($brgw); $rd6prefix = Net_IPv6::uncompress($rd6prefix[0]); -
Hi ermal,
Thanks for looking into this.
Trying to set it to 2602:00:/24 didn't work, it resulted in a GW of 2602:00:cdab:240:: before applying the patch.
I hand applied the patch and set it back to 2602::/24 and it resulted in the following gateway: 2602
aba0:: and it is working and passing traffic for me. Without this patch, the default gateway would not be set.Internet6: Destination Gateway Flags Netif Expire default 2602:cd:aba0:: UGS wan_stfThis contradicts the GW from the above blog post of 2602
ab02:4000:: … so I'm not sure which is right, or if both are, but it is passing traffic. -
I am glad to see I was not crazy. I tried everything within my capability to solve this until I didn't know what else to do so I gave up.
Thanks Ermal. I applied the patch and now it works and pfsense is passing ipv6 traffic.
Thanks bw for bringing this up. Before you did it looked like I was the only one with the problem.
-
Should we mark this long thread [SOLVED] ?
-
Hi jjstecchino,
Glad this is working for you. I think before this is solved we need to confirm if the default gateway is being set correctly. Was your default gateway calculated the same as mine? I believe it should instead be 2602:CD:AB02:4000::
Based on this: http://ccie.markciecior.com/?p=146
Border router IPv4 address: 205.171.2.64 Border router equivalent 6rd address: CD:AB:02:40 Prepending CenturyLink’s IPv6 6rd prefix (2602::/24) to the border router’s 6rd address leaves us with 2602:00CD:AB02:4000::. I also appended eight zeros (0x00 in hex) to the end to make the address 64 bits long. -
Yes it was calculated the same as yours. It passes ipv6 traffic ok. The only thing I had to do after applying the patch and saving the 6rd info was to go to routing and set the wan_6rd gateway as default.
using the ip calculator at http://silmor.de/ipaddrcalc.html#ip46 the correct gateway address should be 2602:CD:AB02:4000::. I don't know why the address 2602
aba0:: calculated by pfsense after the patch work and why the address calculated before the patch (2602:cdab:240) didn't as they are both different from what it should be. But again I am vey ignorant on this topic and just learning ipv6. -
The only thing I can think is that:
the gateway ip of 205.171.2.64 is hex CD AB 02 40
if the prefix were 2602:: /16 the calculated ipv6 for the gateway would be 2602:CDAB:240 which is what pfsense was originally calculating before the patch, however we were specifying a prefix of 2602::/24 that should result in the ipv6 address 2602:00CD:AB02:4000::. I dont know where 2602:00cd:aba0:: comes from and why it does work. I can only speculate that it is in the same 2602:00CD:AB subnet and maybe thats what the centurylink gateway is routing. Take this with a grain of salt because I am a noob with all this, however I believe my calculations of IPv6 based on the given prefix are correct. -
Ok I found the problem.
in /etc/inc/interfaces.inc in the line:
```
$rd6brgw .= decbin($brgw[0]) . decbin($brgw[1]) . decbin($brgw[2]) . decbin($brgw[3]);where it is building the binary string representing the gateway ipv6 there is a problem with 0 padding on the left. The decbin function does not returns a fixed number of bits i.e. decbin(2) = 10 and not 00000010 which is needed to properly construct the binary ip. Replacing that line with: ``` $rd6brgw .= str_pad(decbin($brgw[0]), 8, '0', STR_PAD_LEFT) . str_pad(decbin($brgw[1]), 8, '0', STR_PAD_LEFT) . str_pad(decbin($brgw[2]), 8, '0', STR_PAD_LEFT) . str_pad(decbin($brgw[3]), 8, '0', STR_PAD_LEFT);will solve the problem and return the correct value for the gateway and pfsense ipv6 still up.
As a note for Ermal, if the strategy to convert to binary and back to hex is used somewhere else to create an ipv6 from an ipv4 or MAC address, the same bug may be at play.
-
This is the diff from the stock pfsense /etc/inc/interfaces.inc
--- interfaces.inc.orig 2015-01-31 21:37:54.000000000 -0500 +++ interfaces.inc 2015-02-02 08:51:33.000000000 -0500 @@ -3290,7 +3290,11 @@ $rd6prefix = explode("/", $wancfg['prefix-6rd']); $rd6prefixlen = $rd6prefix[1]; $brgw = explode('.', $wancfg['gateway-6rd']); - $rd6brgw = rtrim($rd6prefix[0], ':') . ':' . dechex($brgw[0]) . dechex($brgw[1]) . ':' . dechex($brgw[2]) . dechex($brgw[3]) . '::'; + $rd6brgw = substr(Net_IPv6::_ip2Bin($rd6prefix[0]), 0, $rd6prefixlen); + $rd6brgw .= str_pad(decbin($brgw[0]), 8, '0', STR_PAD_LEFT) . str_pad(decbin($brgw[1]), 8, '0', STR_PAD_LEFT) . str_pad(decbin($brgw[2]), 8, '0', STR_PAD_LEFT) . str_pad(decbin($brgw[3]), 8, '0', STR_PAD_LEFT); + if (strlen($rd6brgw) < 128) + $rd6brgw = str_pad($rd6brgw, 128, '0', STR_PAD_RIGHT); + $rd6brgw = Net_IPv6::compress(Net_IPv6::_bin2Ip($rd6brgw)); unset($brgw); $rd6prefix = Net_IPv6::uncompress($rd6prefix[0]);which returns the correct gateway ipv6 based on the prefix length.
-
Patch merged and will be in 2.2.1
Thank you for hte feedback. -
Thanks jjstecchino and ermal !
Applied the new patch and its working as expected.
bw