Topic: [SOLVED] IPv6 6RD problem

The content of this topic has been archived on 27 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Page 1 of 1

Post #1

hvdkamer

23 Apr 2015, 20:04

I'm new to OpenWRT and trying to figure out how to use the 6RD my provider uses. It worked on a Fritz!Box without any special configuration. The examples found in the manual and on this forum suggest that I must know some parameters. However my providers sends them through DHCPv4. After much trial and error I've the following changes (* at beginning of line) in /etc/config/network

config interface 'lan'
        option ifname 'eth0.1'
        option force_link '1'
        option type 'bridge'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
*       option ip6assign '64'
*       option ip6hint '13'

config interface 'wan'
        option ifname 'eth0.2'
        option proto 'dhcp'
*       option iface6rd 'wan6'

config interface 'wan6'
        option ifname '@wan'
*       option proto '6rd'

And in /etc/config/dhcp the follwoing:

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
*       option dhcpv6 'disabled'
*       option ra 'server'

With that I get the correct IPv6 addresses -- as checked with the last part of the IPv4 -- and all machines on my network get an IPv6 address. The can ping6 each other as can the router. However none can reach the outside world. The output from ifconfig:

6rd-wan6  Link encap:IPv6-in-IPv4
          inet6 addr: 2001:838:ad45:5300::1/40 Scope:Global
          inet6 addr: ::77.174.69.83/128 Scope:Compat
          UP RUNNING NOARP  MTU:1280  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:114 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:11600 (11.3 KiB)

br-lan    Link encap:Ethernet  HWaddr 30:B5:C2:74:CC:15
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: 2001:838:ad45:5313::1/64 Scope:Global
          inet6 addr: fd7b:9067:127d:13::1/64 Scope:Global
          inet6 addr: fe80::32b5:c2ff:fe74:cc15/64 Scope:Link
...

The eth0, eth0.1, etho.2, lo and wlan0 only have local IPv6 adresses. As said the above is the only changes from an out of the box flashed image. Alle xemaples found in this forum or manuals don't result in anything that gives an IPv6 address range from my provider or gives out addresses on my network.

If more output or tests are needed for answering, please say so. I'm out of ideas .

(Last edited by hvdkamer on 28 Apr 2015, 15:10)

Post #2

CyrusFF

23 Apr 2015, 20:28

Which version of OpenWrt are you using? With the latest snapshots or manually built images (https://downloads.openwrt.org/snapshots/trunk/) your setup should work with the default configuration (you only need to install the 6rd package if you use the precompiled images and then reboot).

Post #3

hvdkamer

23 Apr 2015, 20:41

I'm using Barrier Breaker (14.07, r42625) from the instructions for my router. Is that already too old?

Post #4

CyrusFF

23 Apr 2015, 20:45

With BB you should remove the section "config interface wan6", but leave the option iface6rd in the wan section.
Furthermore I would set option dhcpv6 to server in /etc/config/dhcp but it shouldn't make much of a difference.

Setup looks correct otherwise, you could post the output of "ifstatus wan6" and maybe mention what your ISP is.

Post #5

hvdkamer

23 Apr 2015, 21:14

Removed the section and the option dhcpv6 set to server. After a reboot I still get the IPv6 address and I can still ping6 all my machines. But still no IPv6 connection to the internet. Conclusion the new configuration gives the same result. But it looks simpler and thus better.

My provider is Telfort (Netherlands). The requested output:

{
        "up": true,
        "pending": false,
        "available": true,
        "autostart": true,
        "uptime": 536,
        "l3_device": "6rd-wan6",
        "proto": "6rd",
        "updated": [
                "addresses",
                "routes",
                "prefixes",
                "data"
        ],
        "metric": 0,
        "delegation": true,
        "ipv4-address": [

        ],
        "ipv6-address": [
                {
                        "address": "2001:838:ad45:5300::1",
                        "mask": 40
                }
        ],
        "ipv6-prefix": [
                {
                        "address": "2001:838:ad45:5300::",
                        "mask": 56,
                        "class": "wan6",
                        "assigned": {
                                "lan": {
                                        "address": "2001:838:ad45:5313::",
                                        "mask": 64
                                }
                        }
                }
        ],
        "ipv6-prefix-assignment": [

        ],
        "route": [
                {
                        "target": "::",
                        "mask": 0,
                        "nexthop": "::77.174.0.2",
                        "metric": 4096,
                        "source": "2001:838:ad45:5300::1\/40"
                },
                {
                        "target": "::",
                        "mask": 0,
                        "nexthop": "::77.174.0.2",
                        "metric": 4096,
                        "source": "2001:838:ad45:5300::\/56"
                },
                {
                        "target": "::",
                        "mask": 0,
                        "nexthop": "::77.174.0.2",
                        "metric": 4096,
                        "source": "::\/128"
                }
        ],
        "dns-server": [

        ],
        "dns-search": [

        ],
        "inactive": {
                "ipv4-address": [

                ],
                "ipv6-address": [

                ],
                "route": [

                ],
                "dns-server": [

                ],
                "dns-search": [

                ]
        },
        "data": {
                "zone": "wan"
        }
}

Post #6

kh_tsang

24 Apr 2015, 04:56

In your IPv4 traffic rules, allow protocol 41 input from any addresses.

At the same time, move the 6rd adapter to a dedicated firewall zone, and force connection tracking and allow forward from lan to that firewall zone.

Post #7

CyrusFF

24 Apr 2015, 05:31

The setup looks correct and the parameters look sane.
What do you get when you do: "ping6 ipv6.google.com" on the router?

Post #8

hvdkamer

24 Apr 2015, 07:45

CyrusFF wrote:

What do you get when you do: "ping6 ipv6.google.com" on the router?

root@tplink:~# ping6 ipv6.google.com
PING ipv6.google.com (2a00:1450:4005:800::1009): 56 data bytes
^C
--- ipv6.google.com ping statistics ---
18 packets transmitted, 0 packets received, 100% packet loss

kh_tsang wrote:

In your IPv4 traffic rules, allow protocol 41 input from any addresses.

I didn't change any firewall settings. It is a fresh flash. Are you suggesting that a default firmware doesn't allow this? If so, why is this not mentioned in the manual? Which must be updated because there it hard codes parameters for 6RD which are not easy to come by. The point of 6RD is that it must be automatic .

I've knowledge of iptables, but the setup of OpenWRT is for me very confusing and complex. I'm not sure I understand how and where I must change something. Please advise.

Post #9

CyrusFF

24 Apr 2015, 07:57

What kh_tsang mentions would be adding:

config rule
        option src      wan
        option proto    41
        option target   ACCEPT

to /etc/config/firewall but in fact that should not be necessary. I don't see anything obviously wrong with your setup though. It should work as is. I'm wondering what could be the issue or what the other router does differently or if your ISP has any specialties in this regard. Usually our 6rd setup works.

Post #10

hvdkamer

24 Apr 2015, 08:17

I don't think that my provider is doing something special. It is still a test, but it has worked the last 3,5 years on a Fritz!Box model 7390 and 7490. I work for a computer magazine and have done a test with multiple routers -- with IPv6 support according to the manufacturers -- to see if they can get an IPv6 connection. None have failed. I didn't test the default TP-Link firmware on this router because I bought it for OpenWRT.

If there is anything I can test, let me know. I will think about a procedure to test it further. Most probably a back-up of the current state and the a factory flash to see if the default firmware works. I've the WDR4300. I will also test a clean OpenWRT flash and then directly the above configuration. I can't completly rule out that some experiments might have done something stupid. I didn't touch any other files then dhcp and network, but maybe the webinterface did?

Post #11

hvdkamer

24 Apr 2015, 08:29

CyrusFF wrote:

What kh_tsang mentions would be adding:

Done this. I see it in the firewall overview. But as you say, it doesn't have any effect.

Post #12

kh_tsang

24 Apr 2015, 11:01

It seems that you forget to tell your router about the IP address of the 6rd server of your ISP/IPv6 provider.

Post #13

kh_tsang

24 Apr 2015, 11:06

config 'interface' 'wan6'
        option 'proto' '6rd'
        option peeraddr '192.0.2.1' # The 6rd IPv4-gateway
        option ip6prefix '2123::'   # Your ISP's IPv6-prefix
        option ip6prefixlen '16'    # Your ISP's IPv6-prefix length
        option ip4prefixlen '0'     # Your ISP's IPv4 prefix mask

You need to add the IPv4 address of the IPv6 gateway server by adding peeraddr option.

The sample code comes from http://wiki.openwrt.org/doc/uci/network6.

Post #14

kh_tsang

24 Apr 2015, 11:08

CyrusFF wrote:

What kh_tsang mentions would be adding:
config rule
        option src      wan
        option proto    41
        option target   ACCEPT
to /etc/config/firewall but in fact that should not be necessary. I don't see anything obviously wrong with your setup though. It should work as is. I'm wondering what could be the issue or what the other router does differently or if your ISP has any specialties in this regard. Usually our 6rd setup works.

It is not necessary if you are just using outbound connections as the packets will be allowed by connection tracking.
However, it is necessary if you need inbound connections. I tried that before. Some problems related to keep-alive.

(Last edited by kh_tsang on 24 Apr 2015, 11:14)

Post #15

CyrusFF

24 Apr 2015, 12:13

He did not forget about that it, he used the information received via DHCP. In his config dump you ca see: "77.174.69.83" is the peer address.
The config is correct, no idea what could be wrong. I usually assume I would get a bug report if stuff like 6rd would break but who knows who is still using it today.

Post #16

kh_tsang

24 Apr 2015, 13:11

CyrusFF wrote:

He did not forget about that it, he used the information received via DHCP. In his config dump you ca see: "77.174.69.83" is the peer address.
The config is correct, no idea what could be wrong. I usually assume I would get a bug report if stuff like 6rd would break but who knows who is still using it today.

In his ifconfig output, ::77.174.69.83 appears in 6rd-wan6. If I am correct, 77.174.69.83 is the WAN IP address. The next-hop information should be in the routing table, so I think looking at "ip -6 route show" would be a better idea.

In #5, I see the next hop is ::77.174.0.2, the remote peer should be 77.174.0.2.

Please tell me if I get wrong. Thanks.

If the peer is automatically obtained from DHCP, then the config should be correct.

(Last edited by kh_tsang on 24 Apr 2015, 13:21)

Post #17

hvdkamer

24 Apr 2015, 13:49

I ran a tcpdump on the ping6 to Google. That gave a strange result. I see answers from 2001:838:ad45:5300::1 but the ping6 utility never sees them? Then I installed the ip utility because in the past that gave me better result with IPv6. The first thing was indeed the route:

root@tplink:~# ip -6 route show
default from :: via ::77.174.0.2 dev 6rd-wan6  proto static  metric 4096
default from 2001:838:ad45:5300::/56 via ::77.174.0.2 dev 6rd-wan6  proto static  metric 4096
default from 2001:838:ad00::/40 via ::77.174.0.2 dev 6rd-wan6  proto static  metric 4096
::/96 dev 6rd-wan6  metric 256
2001:838:ad45:5313::/64 dev br-lan  proto static  metric 1024
unreachable 2001:838:ad45:5300::/56 dev lo  proto static  metric 2147483647  error -128
2001:838:ad00::/40 dev 6rd-wan6  proto kernel  metric 256
fd7b:9067:127d:13::/64 dev br-lan  proto static  metric 1024
unreachable fd7b:9067:127d::/48 dev lo  proto static  metric 2147483647  error -128
fe80::/64 dev eth0  proto kernel  metric 256
fe80::/64 dev eth0.2  proto kernel  metric 256
fe80::/64 dev br-lan  proto kernel  metric 256
fe80::/64 dev wlan0  proto kernel  metric 256

The last few hours I tried to figure out if this is correct or that the errors are indeed significant. I'm not that good in reading this things. And just now I saw your discussions about this. May be it helps...

CyrusFF wrote:

I usually assume I would get a bug report if stuff like 6rd would break but who knows who is still using it today.

A few years ago this was the trick for rapidly rolling out IPv6. At that time I saw a lot of providers testing it. Telfort is after 3,5 years still testing it I presume . It worked two years ago on five different routers which I tested at that time. Until the switch begin this week it worked on a Fritz!Box 7490. And as you see it looks like OpenWRT at least sees that it is present. May be one of the received options is wrong?

Post #18

kh_tsang

24 Apr 2015, 13:56

There is also nothing wrong in your routing table. Can you try ping6 again with this ip tool installed and post the result here?

At the same time, have you tried rebooting your router?

I also see that you get a strange reply from one of your delegated /56 addresses. Can you post your firewall config as well?

(Last edited by kh_tsang on 24 Apr 2015, 14:05)

Post #19

hvdkamer

24 Apr 2015, 14:11

kh_tsang wrote:

There is also nothing wrong in your routing table. Can you try ping6 again with this ip tool installed and post the result here.

I'm not sure what you mean with this ip tool installed? The ip package? DO I need to reboot to see if with that it works. Without a reboot but with the package installed:

root@tplink:~# ping6 ipv6.google.com
PING ipv6.google.com (2a00:1450:4005:800::1000): 56 data bytes
^C
--- ipv6.google.com ping statistics ---
19 packets transmitted, 0 packets received, 100% packet loss

So no luck. As said tcpdump sees replies. I've upload a screenshot here. Every ping gives to request, two answers -- one pair can be connected -- and the strange IPv4 line. The ping6 utility doesn't see the answers...

Post #20

hvdkamer

24 Apr 2015, 14:18

kh_tsang wrote:

At the same time, have you tried rebooting your router?

Not the last couple of hours, because nothing really changed. I've a Skype meeting, so give me an hour or so to do this after the call .

kh_tsang wrote:

I also see that you get a strange reply from one of your delegated /56 addresses. Can you post your firewall config as well?

This is as far as I know default with the above try commented out again because it didn't do anything after a reboot:

config defaults
        option syn_flood        1
        option input            ACCEPT
        option output           ACCEPT
        option forward          REJECT
# Uncomment this line to disable ipv6 rules
#       option disable_ipv6     1

config zone
        option name             lan
        list   network          'lan'
        option input            ACCEPT
        option output           ACCEPT
        option forward          ACCEPT

config zone
        option name             wan
        list   network          'wan'
        list   network          'wan6'
        option input            REJECT
        option output           ACCEPT
        option forward          REJECT
        option masq             1
        option mtu_fix          1

config forwarding
        option src              lan
        option dest             wan

# We need to accept udp packets on port 68,
# see https://dev.openwrt.org/ticket/4108
config rule
        option name             Allow-DHCP-Renew
        option src              wan
        option proto            udp
        option dest_port        68
        option target           ACCEPT
        option family           ipv4

# Allow IPv4 ping
config rule
        option name             Allow-Ping
        option src              wan
        option proto            icmp
        option icmp_type        echo-request
        option family           ipv4
        option target           ACCEPT

# Allow DHCPv6 replies
# see https://dev.openwrt.org/ticket/10381
config rule
        option name             Allow-DHCPv6
        option src              wan
        option proto            udp
        option src_ip           fe80::/10
        option src_port         547
        option dest_ip          fe80::/10
        option dest_port        546
        option family           ipv6
        option target           ACCEPT

# Allow essential incoming IPv6 ICMP traffic
config rule
        option name             Allow-ICMPv6-Input
        option src              wan
        option proto            icmp
        list icmp_type          echo-request
        list icmp_type          echo-reply
        list icmp_type          destination-unreachable
        list icmp_type          packet-too-big
        list icmp_type          time-exceeded
        list icmp_type          bad-header
        list icmp_type          unknown-header-type
        list icmp_type          router-solicitation
        list icmp_type          neighbour-solicitation
        list icmp_type          router-advertisement
        list icmp_type          neighbour-advertisement
        option limit            1000/sec
        option family           ipv6
        option target           ACCEPT

# Allow essential forwarded IPv6 ICMP traffic
config rule
        option name             Allow-ICMPv6-Forward
        option src              wan
        option dest             *
        option proto            icmp
        list icmp_type          echo-request
        list icmp_type          echo-reply
        list icmp_type          destination-unreachable
        list icmp_type          packet-too-big
        list icmp_type          time-exceeded
        list icmp_type          bad-header
        list icmp_type          unknown-header-type
        option limit            1000/sec
        option family           ipv6
        option target           ACCEPT

#config rule
#        option src      wan
#        option proto    41
#        option target   ACCEPT

# include a file with users custom iptables rules
config include
        option path /etc/firewall.user
...
(the rest is commented examples from the default install)

Post #21

kh_tsang

24 Apr 2015, 14:18

Can you tell which position does the wireshark computer is installed?

Post #22

kh_tsang

24 Apr 2015, 14:22

If I am not guessing wrongly, your wireshark is installed between you router and your ISP line. And I see your router rejecting some packets by sending ICMP destination unrecheable to the IPv6 gateway server. Can you try re-adding the allow protocol 41 input rule and see if it works?

(Last edited by kh_tsang on 24 Apr 2015, 14:36)

Post #23

kh_tsang

24 Apr 2015, 14:32

kh_tsang wrote:

If I am not guessing wrongly, your wireshark is installed between you router and your ISP line. And I see your router rejecting some packets by sending ICMP destination host unrecheable to the IPv6 gateway server. Can you try re-adding the allow protocol 41 input rule and see if it works?

After that, restart the firewall by using "/etc/init.d/firewall restart" to apply the rules. This process will break your current connection and you need to reconnect.

Post #24

kh_tsang

24 Apr 2015, 14:46

I can't think of any other way to solve your problem other than allowing protocol 41 input according to your wireshark packet log. The reject is likely coming from your firewall.

If you do not want to restart your firewall to break your connections, try the following command for testing purpose. It will lost after restarting the firewall or reboot.

iptables -A input_rule -p 41 -j ACCEPT

(Last edited by kh_tsang on 24 Apr 2015, 14:48)

Post #25

hvdkamer

24 Apr 2015, 15:01

kh_tsang wrote:

Can you tell which position does the wireshark computer is installed?

The router itself . From there:

root@tplink:~# tcpdump -ni any -s 1600 -w ipv6.cap

And then from a different connection the ping6 to Google also on the router itself. Afterwards the ipv6.cap is transfered to my computer because there it is much easier to analyse. The Windows interface is indeed confusing .

After uncommenting the four lines about proto 41 I rebooted. Just to be sure. No luck however:

root@tplink:~# ping6 ipv6.google.com
PING ipv6.google.com (2a00:1450:400c:c05::8b): 56 data bytes
^C
--- ipv6.google.com ping statistics ---
17 packets transmitted, 0 packets received, 100% packet loss

The discussion might have continued from here.

Page 1 of 1