OpenWrt Forum Archive

Topic: IPv6 on Chaos Calmer...

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

Anaerin wrote:

Now I have:

root@Router:~# cat /etc/config/dhcp
...
config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option ra 'server'
        option dhcpv6 'server'
        option ra_management '1'
        option ra_default '1'
...
config dhcp 'wan6'
        option ra 'relay'
        option dhcpv6 'relay'
        option ndp 'relay'
        option master '1'
...

You still have that relaying thing set for some interface?  :-(

You should remove that, as you are not "relaying" any address information. You set a fixed address for the tunnel interface and you provide a fixed prefix for the LAN side.

LAN clients should not have any address from the tunnel interface prefix. If they do, you are giving them wrong info. To me it looks like you are now saying that "please use this tunnel endpoint interface prefix as the master address and pass that downstream to LAN." That might explain, why the Windows host has an address from the tunnel endpoint prefix 2001:470:1f16:174.  LAN clients may try sending packets with the wrong sender address. LAN clients should only have addresses from the routed LAN prefix (ip6prefix) 2001:470:3074:: .

I would remove the whole dhcp wan6 section from the config.

The "ra_default 1" also looks strange.

To my knowledge, also the ip6hint option that was discussed earlier, is unnecessary. It only tells which /64 prefix of the /48 space should be preferably used.


Anaerin wrote:

I was going off the "Default configuration for Chaos Calmer" on the ipv6 wiki page.

I edited the ipv6 wiki page a bit, as that relaying example was confusing. Like it would be a default config for CC15.05. It isn't suitable for a tunnel config.

(Last edited by hnyman on 16 Mar 2016, 09:53)

Anaerin wrote:
   IPv6 Address. . . . . . . . . . . : 2001:470:1f16:174:747b:52e9:a206:ca3b(Preferred)
   IPv6 Address. . . . . . . . . . . : 2001:470:3074:0:747b:52e9:a206:ca3b(Preferred)
   IPv6 Address. . . . . . . . . . . : fd56:da3:9c31:0:747b:52e9:a206:ca3b(Preferred)

Having here 2001:470:1f16:174  is not good.
It should not be here.
2001:470:1f16:174::2 is supposed to be local ipv6 endpoint address with prefix /128 - only one address, not /64. he.net will not route 2001:470:1f16:174::/64.
Usually it routes /64 subnet with 3rd part of ipv6 address increased by 1.
2001:470:1f17:174::/64 in your case. Anyway its not required if you preferred /48  subnet. However you dont need /48, /64 would do if you dont plan internal routed subnets.

your mistake is
ip6addr '2001:470:1f16:174::2/64'
change to
ip6addr '2001:470:1f16:174::2'
and restart

(Last edited by bolvan on 16 Mar 2016, 10:38)

cmsigler wrote:

cvmiller is of course right.  Thank you smile  On the tunnelbroker.net website, what are your tunnel values for:

Server IPv6 Address:
Client IPv6 Address:

Routed /64:
Routed /48:

You might want to change them a bit to protect the innocent IPv6 subnets wink

They are:

IPv6 Tunnel Endpoints
Server IPv6 Address:2001:470:1f16:174::1/64
Client IPv6 Address:2001:470:1f16:174::2/64
Routed /64:2001:470:1f17:174::/64
Routed /48:2001:470:3074::/48
cmsigler wrote:

Sorry this is dragging on so.  For me, it's really hard to identify these problems when you're not sitting in front of the systems in question.

I do understand. Being a programmer myself (albeit for Windows generally) I understand how difficult and frustrating it can be to identify problems like these.

Hi,

Please check what hnyman and bolvan point out.  They are right.  I'm sorry I didn't pick up on these....

I hope that might get you working.  The relay being on will definitely cause problems.  And if ip6addr is wrong the low-level network config will get confused.  HTH.

Clemmitt

Relay is off and the ip6addr doesn't have the suffix (hasn't had in a while now).
Configs are:

root@Router:~# cat /etc/config/network

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config interface 'lan'
        option ifname 'eth0'
        option type 'bridge'
        option proto 'static'
        option ipaddr '192.168.0.1'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ip6hint '0'

config interface 'wan'
        option ifname 'eth1'
        option proto 'dhcp'
        option delegate '0'

config interface 'wan6'
        option _orig_ifname 'eth1'
        option _orig_bridge 'false'
        option proto '6in4'
        option peeraddr '184.105.255.26'
        option ip6addr '2001:470:1f16:174::2'
        option ip6prefix '2001:470:3074::/48'
        option tunnelid '325727'
        option username '<REMOVED>'
        option updatekey '<THIS ONE TOO>'

config globals 'globals'
        option ula_prefix 'fd56:0da3:9c31::/48'

root@Router:~# cat /etc/config/dhcp

config dnsmasq
        option domainneeded '1'
        option boguspriv '1'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.auto'
        option localservice '1'
        option filterwin2k '1'
        option nonegcache '1'

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option ra 'server'
        option ra_maxinterval '30'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'

config host
        option name 'Anaerin-PC'
        option mac '74:d0:2b:96:1a:8b'
        option ip '192.168.0.10'

Hi,

I guess if after all of this checking and revision the IPv6 pings are still being blocked, it would help one more time to see these outputs from the OpenWRT router:

# ip -6 addr

# ip -6 route

# ip6tables -nvL --line-numbers

I'm not sure I will see the problem, but perhaps someone else will.

I'm going back a few posts now.  Like cvmiller pointed out, no IPv6 packets were being forwarded by/through your firewall.  I hope the above 'ip6tables' command might look very different now.  And we can also get a check on the IPv6 addressing/subnetting on the router.  TIA.

Clemmitt

As requested (and after a reboot of the router, just to make sure everything's working as per config files posted last time)

root@Router:~# ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
11: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 5
    inet6 fe80::21d:7dff:fed0:b993/64 scope link
       valid_lft forever preferred_lft forever
12: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
    inet6 2001:470:3074::1/60 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 fd56:da3:9c31::1/60 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 fe80::c6e9:84ff:fe05:4110/64 scope link
       valid_lft forever preferred_lft forever
13: ifb0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qlen 5
    inet6 fe80::83b:b7ff:fedb:4bbf/64 scope link
       valid_lft forever preferred_lft forever
14: 6in4-wan6@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1280
    inet6 2001:470:1f16:174::2/128 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::4711:a0fc/64 scope link
       valid_lft forever preferred_lft forever
root@Router:~# ip -6 route
default from 2001:470:1f16:174::2 dev 6in4-wan6  proto static  metric 1024
default from 2001:470:3074::/48 dev 6in4-wan6  proto static  metric 1024
2001:470:1f16:174::2 dev 6in4-wan6  proto kernel  metric 256
2001:470:3074::/64 dev br-lan  proto static  metric 1024
unreachable 2001:470:3074::/48 dev lo  proto static  metric 2147483647  error -101
fd56:da3:9c31::/64 dev br-lan  proto static  metric 1024
unreachable fd56:da3:9c31::/48 dev lo  proto static  metric 2147483647  error -101
fe80::/64 dev ifb0  proto kernel  metric 256
fe80::/64 dev br-lan  proto kernel  metric 256
fe80::/64 dev eth1  proto kernel  metric 256
fe80::/64 dev 6in4-wan6  proto kernel  metric 256
root@Router:~# ip6tables -nvL --line-numbers
Chain INPUT (policy ACCEPT 48 packets, 5310 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     5999  581K delegate_input  all      *      *       ::/0                 ::/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1      149 14684 delegate_forward  all      *      *       ::/0                 ::/0

Chain OUTPUT (policy ACCEPT 45 packets, 5554 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1    28901   12M delegate_output  all      *      *       ::/0                 ::/0

Chain MINIUPNPD (0 references)
num   pkts bytes target     prot opt in     out     source               destination

Chain delegate_forward (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1      149 14684 forwarding_rule  all      *      *       ::/0                 ::/0                 /* user chain for forwarding */
2        0     0 ACCEPT     all      *      *       ::/0                 ::/0                 ctstate RELATED,ESTABLISHED
3      149 14684 zone_lan_forward  all      br-lan *       ::/0                 ::/0
4      149 14684 reject     all      *      *       ::/0                 ::/0

Chain delegate_input (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1       28  6860 ACCEPT     all      lo     *       ::/0                 ::/0
2     5971  574K input_rule  all      *      *       ::/0                 ::/0                 /* user chain for input */
3      159 16408 ACCEPT     all      *      *       ::/0                 ::/0                 ctstate RELATED,ESTABLISHED
4       13   936 syn_flood  tcp      *      *       ::/0                 ::/0                 tcp flags:0x17/0x02
5     5764  552K zone_lan_input  all      br-lan *       ::/0                 ::/0

Chain delegate_output (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1       28  6860 ACCEPT     all      *      lo      ::/0                 ::/0
2    28873   12M output_rule  all      *      *       ::/0                 ::/0                 /* user chain for output */
3     4710  816K ACCEPT     all      *      *       ::/0                 ::/0                 ctstate RELATED,ESTABLISHED
4    24118   11M zone_lan_output  all      *      br-lan  ::/0                 ::/0

Chain forwarding_lan_rule (1 references)
num   pkts bytes target     prot opt in     out     source               destination

Chain forwarding_rule (1 references)
num   pkts bytes target     prot opt in     out     source               destination

Chain input_lan_rule (1 references)
num   pkts bytes target     prot opt in     out     source               destination

Chain input_rule (1 references)
num   pkts bytes target     prot opt in     out     source               destination

Chain output_lan_rule (1 references)
num   pkts bytes target     prot opt in     out     source               destination

Chain output_rule (1 references)
num   pkts bytes target     prot opt in     out     source               destination

Chain reject (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1      139 11120 REJECT     tcp      *      *       ::/0                 ::/0                 reject-with tcp-reset
2       10  3564 REJECT     all      *      *       ::/0                 ::/0                 reject-with icmp6-port-unreachable

Chain syn_flood (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1       13   936 RETURN     tcp      *      *       ::/0                 ::/0                 tcp flags:0x17/0x02 limit: avg 25/sec burst 50
2        0     0 DROP       all      *      *       ::/0                 ::/0

Chain zone_lan_dest_ACCEPT (2 references)
num   pkts bytes target     prot opt in     out     source               destination
1    24118   11M ACCEPT     all      *      br-lan  ::/0                 ::/0

Chain zone_lan_forward (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1      149 14684 forwarding_lan_rule  all      *      *       ::/0                 ::/0                 /* user chain for forwarding */
2      149 14684 zone_lan_dest_ACCEPT  all      *      *       ::/0                 ::/0

Chain zone_lan_input (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1     5764  552K input_lan_rule  all      *      *       ::/0                 ::/0                 /* user chain for input */
2     5764  552K zone_lan_src_ACCEPT  all      *      *       ::/0                 ::/0

Chain zone_lan_output (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1    24118   11M output_lan_rule  all      *      *       ::/0                 ::/0                 /* user chain for output */
2    24118   11M zone_lan_dest_ACCEPT  all      *      *       ::/0                 ::/0

Chain zone_lan_src_ACCEPT (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1     5764  552K ACCEPT     all      br-lan *       ::/0                 ::/0

Things are different on the PC, too, it seems:

C:\WINDOWS\system32>ipconfig /all
Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : lan
   Description . . . . . . . . . . . : Realtek PCIe GBE Family Controller
   Physical Address. . . . . . . . . : 74-D0-2B-96-1A-8B
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : 2001:470:3074:0:747b:52e9:a206:ca3b(Preferred)
   IPv6 Address. . . . . . . . . . . : fd56:da3:9c31:0:747b:52e9:a206:ca3b(Preferred)
   Temporary IPv6 Address. . . . . . : 2001:470:3074:0:45c6:a6b6:6662:dd32(Preferred)
   Temporary IPv6 Address. . . . . . : fd56:da3:9c31:0:45c6:a6b6:6662:dd32(Preferred)
   Link-local IPv6 Address . . . . . : fe80::747b:52e9:a206:ca3b%13(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.0.10(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : March 8, 2016 4:05:49 PM
   Lease Expires . . . . . . . . . . : March 16, 2016 6:37:21 PM
   Default Gateway . . . . . . . . . : fe80::c6e9:84ff:fe05:4110%13
                                       192.168.0.1
   DHCP Server . . . . . . . . . . . : 192.168.0.1
   DHCPv6 IAID . . . . . . . . . . . : 57987115
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1A-F9-7C-41-74-D0-2B-96-1A-8B
   DNS Servers . . . . . . . . . . . : 192.168.0.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

C:\WINDOWS\system32>tracert -6 ipv6.google.com

Tracing route to ipv6.l.google.com [2607:f8b0:400f:803::200e]
over a maximum of 30 hops:

  1     3 ms    <1 ms    <1 ms  2001:470:3074::1
  2  Destination protocol unreachable.

Trace complete.

So... progress?

Hi Anaerin,

When I look at your dump of /etc/config/network, and compare to the very helpful IPv6 networking page [https://wiki.openwrt.org/doc/uci/network6](https://wiki.openwrt.org/doc/uci/network6) I see that you have not reduced your MTU.

        option 'mtu' '1424'                          # the IPv6 tunnel MTU (optional)

Although this will not cause your current lack-of-forwarding problem, it will cause problems in the future when your windows machine tries to push a 1500 byte packet through your tunnel, and it is silently dropped (Routers don't fragment in IPv6).

Looking forward to seeing the command outputs Clemmitt mentioned.

cvmiller wrote:

Hi Anaerin,

When I look at your dump of /etc/config/network, and compare to the very helpful IPv6 networking page [https://wiki.openwrt.org/doc/uci/network6](https://wiki.openwrt.org/doc/uci/network6) I see that you have not reduced your MTU.

        option 'mtu' '1424'                          # the IPv6 tunnel MTU (optional)

Although this will not cause your current lack-of-forwarding problem, it will cause problems in the future when your windows machine tries to push a 1500 byte packet through your tunnel, and it is silently dropped (Routers don't fragment in IPv6).

Well, for one thing, it states that is "Optional", and for another the Router Advertisements I'm getting have the MTU specified as 1200:

Frame 56: 254 bytes on wire (2032 bits), 254 bytes captured (2032 bits) on interface 0
Ethernet II, Src: Tp-LinkT_05:41:10 (c4:e9:84:05:41:10), Dst: IPv6mcast_01 (33:33:00:00:00:01)
Internet Protocol Version 6, Src: fe80::c6e9:84ff:fe05:4110, Dst: ff02::1
Internet Control Message Protocol v6
    Type: Router Advertisement (134)
    Code: 0
    Checksum: 0x5924 [correct]
    Cur hop limit: 64
    Flags: 0xc0
    Router lifetime (s): 1800
    Reachable time (ms): 0
    Retrans timer (ms): 0
    ICMPv6 Option (Source link-layer address : c4:e9:84:05:41:10)
    ICMPv6 Option (MTU : 1280)
    ICMPv6 Option (Prefix information : 2001:470:3074::/64)
    ICMPv6 Option (Prefix information : fd56:da3:9c31::/64)
    ICMPv6 Option (Route Information : Medium 2001:470:3074::/48)
    ICMPv6 Option (Route Information : Medium fd56:da3:9c31::/48)
    ICMPv6 Option (Recursive DNS Server 2001:470:3074::1)
    ICMPv6 Option (DNS Search List Option lan)
    ICMPv6 Option (Advertisement Interval : 600000)

So it looks like it's handling that part itself, right?

The data Clemmitt asked for is in my previous post (I think we simulposted)

(Last edited by Anaerin on 16 Mar 2016, 16:44)

OK, here goes.  On the bright side, your Windows client IPv6 addresses look correct to me now smile

I see packets going through your forwarding firewall rules now, which is good.  But I think there's something wrong with your firewall rules.  Here's the chain as I trace it by eye based on your ip6tables output:

- Packets with dest addresses requiring forwarding upstream from br-lan to 6in4-wan6 arrive from br-lan.
- They go to chain FORWARD and are chained to delegate_forward.
- They go to delegate_forward and are chained to forwarding_rule.
- forwarding_rule is empty so they jump back to delegate_forward
- They don't match RELATED or ESTABLISHED so aren't ACCEPTed.
- They are then chained to zone_lan_forward.
- zone_lan_forward chains them to forwarding_lan_rule.
- forwarding_lan_rule is empty so they jump back to zone_lan_forward.
- zone_lan_forward chains them to zone_lan_dest_ACCEPT.
- zone_lan_dest_ACCEPT doesn't match the packets because they're not going out on the lan interface/zone.  If would ACCEPT them if the out was 6in4-wan6 instead of br-lan.  The packets jump back to zone_lan_forward but reach the end so they jump back to delegate_forward.
- delegate_foward sends them to chain reject which rejects them (and you can see this because all packets increment the counters of these rules).  I guess this is why the firewall blocks your IPv6 traffic sad

So I'm pretty sure the firewall configuration is wrong.  Have you configured firewalling using LuCI under Network -> Firewall -> General Settings?  Is your wan6 interface a part of zone wan (Network -> Interfaces -> WAN6 -> Firewall Settings)?  Do you have everything set to "accept" for zone lan => zone wan?  How are your interfaces named and organized into zones?  I probably don't understand this.  I'm confused about the names LuCI uses versus the command line interface names.

There needs to be a rule somewhere in ip6tables (called something like zone_wan_dest_ACCEPT) which has target ACCEPT matching out = 6in4-wan6 packets.

This probably doesn't help you fix things right away but I think it's clearer why packets aren't being forwarded upstream by the firewall.

Clemmitt

Its easy to test if firewall causes trouble.

ip6tables -F
ip6tables -F -t mangle
ip6tables -P FORWARD ACCEPT

To return back : fw3 reload

cmsigler wrote:

So I'm pretty sure the firewall configuration is wrong.

Probably. I've not touched it from the defaults.

cmsigler wrote:

Have you configured firewalling using LuCI under Network -> Firewall -> General Settings?

Not beyond what is already set.

cmsigler wrote:

Is your wan6 interface a part of zone wan (Network -> Interfaces -> WAN6 -> Firewall Settings)?

Yes.

cmsigler wrote:

Do you have everything set to "accept" for zone lan => zone wan?

Yes.

cmsigler wrote:

How are your interfaces named and organized into zones?

AIUI, there are 2 zones. lan (that contains the interface "lan") and wan (that contains the interfaces "wan" and "wan6").
Zone "lan" forwards to Zone "wan" (input, output and forward all set to "Accept").
Zone "wan" is set to forward to nothing ("Reject") if I'm reading this right (input and forward set to "Reject", output set to "Accept").

cmsigler wrote:

I probably don't understand this.  I'm confused about the names LuCI uses versus the command line interface names.

There needs to be a rule somewhere in ip6tables (called something like zone_wan_dest_ACCEPT) which has target ACCEPT matching out = 6in4-wan6 packets.

This probably doesn't help you fix things right away but I think it's clearer why packets aren't being forwarded upstream by the firewall.

Clemmitt

My firewall config looks like this

root@Router:~# cat /etc/config/firewall

config defaults
        option syn_flood '1'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'

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

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

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

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

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config include
        option path '/etc/firewall.user'

config rule
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

config include 'miniupnpd'
        option type 'script'
        option path '/usr/share/miniupnpd/firewall.include'
        option family 'any'
        option reload '1'

config redirect
        option target 'DNAT'
        option src 'wan'
        option dest 'lan'
        option proto 'udp'
        option src_dport '25565'
        option dest_ip '192.168.0.10'
        option dest_port '25565'
        option name 'Chroma 1'

config redirect
        option target 'DNAT'
        option src 'wan'
        option dest 'lan'
        option proto 'udp'
        option src_dport '9989'
        option dest_ip '192.168.0.10'
        option dest_port '9989'
        option name 'Chroma 2'

config redirect
        option target 'DNAT'
        option src 'wan'
        option dest 'lan'
        option proto 'tcp udp'
        option src_dport '27015'
        option dest_ip '192.168.0.10'
        option dest_port '27015'
        option name 'HL1'

config redirect
        option target 'DNAT'
        option src 'wan'
        option dest 'lan'
        option proto 'tcp udp'
        option src_dport '21212'
        option dest_ip '192.168.0.10'
        option dest_port '21212'
        option name 'FTP'

config redirect
        option target 'DNAT'
        option src 'wan'
        option dest 'lan'
        option src_dport '25590'
        option dest_ip '192.168.0.10'
        option dest_port '25590'
        option name 'Chroma Live'
        option proto 'tcp udp'

config forwarding
        option dest 'wan'
        option src 'lan'
bolvan wrote:

Its easy to test if firewall causes trouble.

ip6tables -F
ip6tables -F -t mangle
ip6tables -P FORWARD ACCEPT

Doing that leads to... DATA!

C:\WINDOWS\system32>tracert -6 ipv6.google.com

Tracing route to ipv6.l.google.com [2607:f8b0:400f:803::200e]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  2001:470:3074::1
  2    85 ms    86 ms    89 ms  anaerin-1.tunnel.tserv1.ywg1.ipv6.he.net [2001:470:1f16:174::1]
  3    91 ms    98 ms    84 ms  ge2-20.core1.ywg1.he.net [2001:470:0:2b8::1]
  4   108 ms    99 ms    98 ms  10ge1-6.core1.msp1.he.net [2001:470:0:2dd::1]
  5   102 ms   112 ms   102 ms  100ge7-1.core1.chi1.he.net [2001:470:0:18e::1]
  6   106 ms     *      103 ms  eqixchi-v6.google.com [2001:504:0:4:0:1:5169:1]
  7   104 ms   103 ms   104 ms  2001:4860::1:0:aa7a
  8   125 ms   124 ms   123 ms  2001:4860::8:0:9154
  9   122 ms   120 ms   129 ms  2001:4860::8:0:b2bb
 10   129 ms   125 ms   125 ms  2001:4860::8:0:79e6
 11   122 ms   123 ms   126 ms  2001:4860::1:0:8831
 12   123 ms   125 ms   127 ms  2001:4860:0:1::1221
 13   120 ms   123 ms   123 ms  den03s10-in-x0e.1e100.net [2607:f8b0:400f:803::200e]

Trace complete.
bolvan wrote:

To return back : fw3 reload

And the fw3 reload makes it broken again (boo!). But at least now we know it's the firewall config that's doing it.
For reference, the output of fw3 reload looks like this (interesting, I think):

root@Router:~# fw3 reload
Warning: Unable to locate ipset utility, disabling ipset support
 * Clearing IPv4 filter table
 * Clearing IPv4 nat table
 * Clearing IPv4 mangle table
 * Clearing IPv4 raw table
 * Populating IPv4 filter table
   * Zone 'lan'
   * Zone 'wan'
   * Rule 'Allow-DHCP-Renew'
   * Rule 'Allow-Ping'
   * Rule 'Allow-IGMP'
   * Rule #3
   * Rule #4
   * Redirect 'Chroma 1'
   * Redirect 'Chroma 2'
   * Redirect 'HL1'
   * Redirect 'FTP'
   * Redirect 'Chroma Live'
   * Forward 'lan' -> 'wan'
 * Populating IPv4 nat table
   * Zone 'lan'
   * Zone 'wan'
   * Redirect 'Chroma 1'
   * Redirect 'Chroma 2'
   * Redirect 'HL1'
   * Redirect 'FTP'
   * Redirect 'Chroma Live'
 * Populating IPv4 mangle table
   * Zone 'lan'
   * Zone 'wan'
 * Populating IPv4 raw table
   * Zone 'lan'
   * Zone 'wan'
 * Clearing IPv6 filter table
 * Clearing IPv6 nat table
 * Clearing IPv6 mangle table
 * Clearing IPv6 raw table
 * Populating IPv6 filter table
   * Zone 'lan'
   * Rule #3
     ! Skipping due to different family of zone
   * Rule #4
     ! Skipping due to different family of zone
   * Forward 'lan' -> 'wan'
     ! Skipping due to different family of zone
 * Populating IPv6 nat table
   * Zone 'lan'
Warning: fw3_ipt_rule_append(): Can't find target 'prerouting_lan_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'postrouting_lan_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'delegate_prerouting'
Warning: fw3_ipt_rule_append(): Can't find target 'delegate_postrouting'
Warning: fw3_ipt_rule_append(): Can't find target 'prerouting_rule'
Warning: fw3_ipt_rule_append(): Can't find target 'postrouting_rule'
 * Populating IPv6 mangle table
   * Zone 'lan'
 * Populating IPv6 raw table
   * Zone 'lan'
 * Set tcp_ecn to off
 * Set tcp_syncookies to on
 * Set tcp_window_scaling to on
 * Running script '/usr/share/miniupnpd/firewall.include'
ip6tables: No chain/target/match by that name.
ip6tables: No chain/target/match by that name.

(Last edited by Anaerin on 16 Mar 2016, 17:57)

Anaerin wrote:

But at least now we know it's the firewall config that's doing it.

Anaerin wrote:
root@Router:~# cat /etc/config/firewall
...
config zone
        option name 'wan'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'
        option family 'ipv4'
        option network 'wan wan6'

For some strange reason, you are setting the wan zone to be only ipv4...
No wonder that the ipv6 packets do not get forwarded there.

The option family 'ipv4' should likely be removed. That is not part of the standard config.

(Last edited by hnyman on 16 Mar 2016, 17:57)

hnyman wrote:
Anaerin wrote:

But at least now we know it's the firewall config that's doing it.

Anaerin wrote:
root@Router:~# cat /etc/config/firewall
...
config zone
        option name 'wan'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'
        option family 'ipv4'
        option network 'wan wan6'

For some strange reason, you are setting the wan zone to be only ipv4...
No wonder that the ipv6 packets do not get forwarded there.

The option family 'ipv4' should likely be removed. That is not part of the standard config.

And wouldn't you know it. Unsetting that makes everything Just Work.

Thank-you all so very much for all your hard work. I am very glad we've got this sorted.

Great that you got it working.
One final note: your last firewall config seemed to miss the default icmpv6 rules. You will need those.

(Last edited by hnyman on 16 Mar 2016, 18:03)

And one more note. Default firewall config prevent incoming connections. If you need them they must be enabled explicitly by fw rules

hnyman wrote:

For some strange reason, you are setting the wan zone to be only ipv4...
No wonder that the ipv6 packets do not get forwarded there.

Wow.  At what point did you change the firewall's wan zone to IPv4 only?  You didn't have it that way to begin with.  To make sure I went back and searched all your posts from the beginning of this thread... sad  Though some rules were option family ipv6 or ipv4, the zones were not that way.

This is why forum tech support is hard -- there are too many variables changing randomly all the time and there's no way for your support staff to guess what you are changing that you don't mention to us or understand.

Clemmitt

Anaerin wrote:

But at least now we know it's the firewall config that's doing it.

*sigh*  I'm sorry I couldn't explain myself more clearly.

This is precisely why I took the time to do a by-hand trace of the chains/tables in your IPv6 firewall rules.  I proved that the packets were being REJECTed by your then-existing firewall configuration.

Clemmitt

Glad you got it working. You may already know this, but IPv6 works differently from IPv6 in MAC address resolution. There is NO ARP. Instead it used ICMPv6 to resolve MAC addresses. This why you need to configure the firewall to allow certain ICMPv6 messages to get through.

I believe these are the standard (I don't remember changing them) for ICMPv6:

config rule                       
        option name 'Allow-ICMPv6-Input'
        option src 'wan'                
        option proto 'icmp'             
        list icmp_type 'echo-request'   
        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' 
        option limit '1000/sec'                 
        option family 'ipv6'                    
        option target 'ACCEPT'                  
 config rule                                     
        option name 'Allow-ICMPv6-Forward'      
        option src 'wan'                        
        option dest '*'                         
        option proto 'icmp'                     
        option limit '1000/sec'                 
        option family 'ipv6'                    
        option target 'ACCEPT'                  
        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'    

Enjoy surfing the IPv6 internet.

The discussion might have continued from here.