6rd support added
-
It still works, no need to gitsync. Make sure your 6rd gateway is marked as default for v6 under System>Routing.
-
WAN_6RD gateway already marked as default in system->routing, however I do not see any gateway marked as default in the routing table. Still I have still no traffic routed after a fresh reinstall. I used centurylink/quest 6RD with 2602::/24 prefix, 205.171.2.64 border relay and 0 prefix length as per centurylink docs (this worked previously). LAN is set to track wan. Clients on the network get IPV6 addresses in the 2602:47:3004:c800:: range, can ping6 LAN ipv6 address, can't ping anything past pfsense an address. WAN_6RD shows offline (setup to ping google ipv6 dns). From pfsense shell can ping a plan client, cannot ping google dns -> no route to host. Do you see anything abnormal in my routing table? I did not add or remove any routes. Have 2 pfsense boxes with carp both with same problem.
-
As additional info, I do not see a ::0 route or a default gateway in the routing table.
Looking at the logs I found this:
php-fpm[71649]: /system_gateways.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'So my box is unable to add a default route for IPV6.
I double checked my 6RD configuration and it appears correct for Centurylink/quest which is my isp
Any suggestion or any further test I can do?
-
Can you provide an ifconfig output?
Also your config.xml for this WAN configuration? -
Here you go…. and thank you for looking at it.
/root: ifconfig msk0: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500 options=c011a <txcsum,vlan_mtu,vlan_hwtagging,tso4,vlan_hwtso,linkstate>ether 00:90:7f:3c:52:c1 nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect msk1: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500 options=c011a <txcsum,vlan_mtu,vlan_hwtagging,tso4,vlan_hwtso,linkstate>ether 00:90:7f:3c:52:c0 nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect msk2: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500 options=c011a <txcsum,vlan_mtu,vlan_hwtagging,tso4,vlan_hwtso,linkstate>ether 00:90:7f:3c:52:bf nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect msk3: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500 options=c011a <txcsum,vlan_mtu,vlan_hwtagging,tso4,vlan_hwtso,linkstate>ether 00:90:7f:3c:52:be nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect sk0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500 options=8000b <rxcsum,txcsum,vlan_mtu,linkstate>ether 00:90:7f:3c:52:bd inet6 fe80::290:7fff:fe3c:52bd%sk0 prefixlen 64 scopeid 0x5 inet 71.48.4.200 netmask 0xfffff800 broadcast 71.48.7.255 nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (1000baseT <full-duplex>) status: active sk1: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500 options=8000b <rxcsum,txcsum,vlan_mtu,linkstate>ether 00:90:7f:3c:52:bc inet 192.168.100.252 netmask 0xffffff00 broadcast 192.168.100.255 inet 192.168.100.250 netmask 0xffffff00 broadcast 192.168.100.255 vhid 1 inet6 fe80::1:1%sk1 prefixlen 64 duplicated scopeid 0x6 inet6 2602:47:3004:c800::1 prefixlen 64 nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (1000baseT <full-duplex>) status: active carp: BACKUP vhid 1 advbase 1 advskew 100 sk2: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500 options=80009 <rxcsum,vlan_mtu,linkstate>ether 00:90:7f:3c:52:bb nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (none) status: no carrier sk3: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500 options=8000b <rxcsum,txcsum,vlan_mtu,linkstate>ether 00:90:7f:3c:52:ba inet 10.10.10.2 netmask 0xffffff00 broadcast 10.10.10.255 inet6 fe80::290:7fff:fe3c:52ba%sk3 prefixlen 64 scopeid 0x8 nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (1000baseT <full-duplex>) status: active pflog0: flags=100 <promisc>metric 0 mtu 33172 pfsync0: flags=41 <up,running>metric 0 mtu 1500 pfsync: syncdev: sk3 syncpeer: 224.0.0.240 maxupd: 128 defer: on syncok: 1 lo0: flags=8049 <up,loopback,running,multicast>metric 0 mtu 16384 options=600003 <rxcsum,txcsum,rxcsum_ipv6,txcsum_ipv6>inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0xb nd6 options=21 <performnud,auto_linklocal>enc0: flags=0<> metric 0 mtu 1536 nd6 options=21 <performnud,auto_linklocal>ovpns1: flags=8051 <up,pointopoint,running,multicast>metric 0 mtu 1500 options=80000 <linkstate>inet6 fe80::290:7fff:fe3c:52c1%ovpns1 prefixlen 64 scopeid 0xe inet 192.168.200.1 --> 192.168.200.2 netmask 0xffffffff nd6 options=21 <performnud,auto_linklocal>Opened by PID 91717 ovpns2: flags=8051 <up,pointopoint,running,multicast>metric 0 mtu 1500 options=80000 <linkstate>inet6 fe80::290:7fff:fe3c:52c1%ovpns2 prefixlen 64 scopeid 0xf inet 192.168.150.1 --> 192.168.150.2 netmask 0xffffffff nd6 options=21 <performnud,auto_linklocal>Opened by PID 93991 wan_stf: flags=4001 <up,link2>metric 0 mtu 1280 inet6 2602:47:3004:c800:: prefixlen 24 nd6 options=1 <performnud>v4net 71.48.4.200/32 -> tv4br 205.171.2.64</performnud></up,link2></performnud,auto_linklocal></linkstate></up,pointopoint,running,multicast></performnud,auto_linklocal></linkstate></up,pointopoint,running,multicast></performnud,auto_linklocal></performnud,auto_linklocal></rxcsum,txcsum,rxcsum_ipv6,txcsum_ipv6></up,loopback,running,multicast></up,running></promisc></full-duplex></performnud,auto_linklocal></rxcsum,txcsum,vlan_mtu,linkstate></up,broadcast,running,simplex,multicast></performnud,auto_linklocal></rxcsum,vlan_mtu,linkstate></broadcast,simplex,multicast></full-duplex></performnud,auto_linklocal></rxcsum,txcsum,vlan_mtu,linkstate></up,broadcast,running,promisc,simplex,multicast></full-duplex></performnud,auto_linklocal></rxcsum,txcsum,vlan_mtu,linkstate></up,broadcast,running,simplex,multicast></performnud,auto_linklocal></txcsum,vlan_mtu,vlan_hwtagging,tso4,vlan_hwtso,linkstate></broadcast,simplex,multicast></performnud,auto_linklocal></txcsum,vlan_mtu,vlan_hwtagging,tso4,vlan_hwtso,linkstate></broadcast,simplex,multicast></performnud,auto_linklocal></txcsum,vlan_mtu,vlan_hwtagging,tso4,vlan_hwtso,linkstate></broadcast,simplex,multicast></performnud,auto_linklocal></txcsum,vlan_mtu,vlan_hwtagging,tso4,vlan_hwtso,linkstate></broadcast,simplex,multicast><wan><enable><if>sk0</if> <blockpriv><blockbogons><alias-address><alias-subnet>32</alias-subnet> <spoofmac><ipaddr>dhcp</ipaddr> <dhcphostname><dhcprejectfrom><adv_dhcp_pt_timeout><adv_dhcp_pt_retry><adv_dhcp_pt_select_timeout><adv_dhcp_pt_reboot><adv_dhcp_pt_backoff_cutoff><adv_dhcp_pt_initial_interval><adv_dhcp_pt_values>SavedCfg</adv_dhcp_pt_values> <adv_dhcp_send_options><adv_dhcp_request_options><adv_dhcp_required_options><adv_dhcp_option_modifiers><adv_dhcp_config_advanced></adv_dhcp_config_advanced> <adv_dhcp_config_file_override></adv_dhcp_config_file_override> <adv_dhcp_config_file_override_path><ipaddrv6>6rd</ipaddrv6> <prefix-6rd>2602::/24</prefix-6rd> <prefix-6rd-v4plen>0</prefix-6rd-v4plen> <gateway-6rd>205.171.2.64</gateway-6rd></adv_dhcp_config_file_override_path></adv_dhcp_option_modifiers></adv_dhcp_required_options></adv_dhcp_request_options></adv_dhcp_send_options></adv_dhcp_pt_initial_interval></adv_dhcp_pt_backoff_cutoff></adv_dhcp_pt_reboot></adv_dhcp_pt_select_timeout></adv_dhcp_pt_retry></adv_dhcp_pt_timeout></dhcprejectfrom></dhcphostname></spoofmac></alias-address></blockbogons></blockpriv></enable></wan> -
Anybody willing to lend a helping hand?
-
This seems ok.
Probably something else wrong in your config. -
Ermal, could you try to point me toward the right direction?
This was a fresh install to a watchguard firebox x-750-e.
I see this in the System log if I save and apply changes on Wan interface:php-fpm[63614]: /rc.newwanip: rc.newwanip: Info: starting on sk0. Dec 17 09:56:00 php-fpm[63614]: /rc.newwanip: rc.newwanip: on (IP address: 71.51.251.64) (interface: WAN[wan]) (real interface: sk0). Dec 17 09:56:01 php-fpm[63614]: /rc.newwanip: rd6 lan with ipv6 address 2602:47:33fb:4000::1 based on wan ipv4 71.51.251.64 Dec 17 09:56:01 kernel: stf0: changing name to 'wan_stf' Dec 17 09:56:01 php-fpm[60185]: /rc.filter_synchronize: Filter sync successfully completed with http://10.10.10.2:80. Dec 17 09:56:01 php-fpm[63209]: /interfaces.php: ROUTING: setting default route to 71.51.248.1 Dec 17 09:56:01 php-fpm[63209]: /interfaces.php: ROUTING: setting IPv6 default route to 2602:cdab:240:: Dec 17 09:56:01 php-fpm[63209]: /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' Dec 17 09:56:03 php-fpm[63614]: /rc.newwanip: ROUTING: setting default route to 71.51.248.1 Dec 17 09:56:03 php-fpm[63614]: /rc.newwanip: ROUTING: setting IPv6 default route to 2602:cdab:240:: Dec 17 09:56:03 php-fpm[63614]: /rc.newwanip: 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'Is that the route creation fails because wan_stf is not passing ipv6 traffic?
How can I troubleshoot wan_stf?
Thanks for looking at this
-
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.