6rd support added
-
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
-
If you want to update the initial post:
Italy: FastWeb –-- 2001:b07::/32 = delegated /64
-
I just installed 2.2.6 and am having this exact issue with Centurylink 6rd. The brgw calculation in /etc/inc/interfaces.inc is the same as is in the patch, but the gateway ip is coming up as cdab:240:: Also, the interface I'm tracking as subnet 43 comes up as 6d00:43::1 which I'm pretty sure is incorrect as well. No default route is getting created for the same reason as above, I'm sure.
Any help would be very appreciated, please let me know anything I can do to help.
Thanks,
-ian -
I just upgraded to 2.3 from the latest on 2.2.x and suddenly my IPv6 support (via 6RD on the WAN side) is gone. From the server console I can ping6 IPv6-only hosts such as ipv6.google.com. But whatever I try for my LAN-setting (I have tried SLAAC and Track Interface), I can't ping -6 anything (Windows client). I used to have SLAAC on the LAN side and everything was ok. When I try ping -6 ipv6.google.com from a client, it does get the IPv6 IP to ping (i.e. not a DNS issue). The results are sometimes Destination host unreachable and sometimes Request timed out. Any ideas on what I should try?
Edit: also, Status | Gateways shows WAN_6RD as Offline, even though it works from the server console.
-
@databeestje Confirmed working from Helsinki, Finland with operator Telia, but had to edit WAN-interface's DHCP-client to request option-212 and run a packet capture for relay and prefix details.
6RD Prefix:2001: 2003:f400::/38
6RD Border relay: 84.251.255.254
6RD IPv4 Prefix length: 14From what I've heard, in Finland especially Telia is really behind in native IPv6 -deployment and 6RD is extensively in use. Only the first 32 bits of the prefix are static and to add insult to injury the border relay IPs sometimes change.
Would it be possible to add a checkbox in the 6RD config GUI for the automatic update of the 6RD parameters via option-212?Keep up the good work!