No connections with IPv6 over OpenWRT-Router

Hi,
I have set OpenWrt 21.02.0 with LuCI openwrt-21.02 and IPv6. My Linux clients (all Debian 12) are also assigned IPv6 addresses. Internally they can log in, but they cannot access the Internet via the OpenWrt router. Ping with IPv6 from the OpenWRT router to the Internet is possible.

ping6 -c6 www.google.com
PING www.google.com (2a00:1450:4016:80a::2004): 56 bytes of data
64 bytes from 2a00:1450:4016:80a::2004: seq=0 ttl=114 time=28.384 ms
64 bytes from 2a00:1450:4016:80a::2004: seq=1 ttl=114 time=28,461 ms
64 bytes from 2a00:1450:4016:80a::2004: seq=2 ttl=114 time=28,464 ms
64 bytes from 2a00:1450:4016:80a::2004: seq=3 ttl=114 time=28.644 ms
64 bytes from 2a00:1450:4016:80a::2004: seq=4 ttl=114 time=28,653 ms
64 bytes of 2a00:1450:4016:80a::2004: seq=5 ttl=114 time=27.967 ms

I get this message from customers:

ping6 -c2 www.google.com
PING www.google.com(muc11s22-in-x04.1e100.net (2a00:1450:4016:80a::2004)) 56 bytes of data
From p200300e59702f8010000000000000001.dip0.t-ipconnect.de (2003:e5:9702:f801::1) icmp_seq=1 Destination not reachable: Port not reachable
From p200300e59702f8010000000000000001.dip0.t-ipconnect.de (2003:e5:9702:f801::1) icmp_seq=2 Target not reachable: Port not reachable

Do you have an idea to solve this?

Many thanks
BrotherJay

Can you provide more details on what this statement means.

Do you mean the Debian 12 clients connected to the router - or something else?

In order to assist you - please identify this host/IP.

As I showed by the outputs of the ping command, it doesn't find the route.
Yes, the Debian 12 clients access the Internet via this router. Usually using IPv4.

What exactly do you want to know about the host/IP? This is the IP address from the ISP.

I'll ask again with different wording:

  • Were you showing output from the Debian 12 machine?
  • Does the word "customer" actually mean "Debian clients"?
  • Your statement isn't accurate - the [OpenWrt's IPv6] route is clearly found, as the ISP router received the traffic

Why -

Your ISP seems to send reply traffic back to you. Additionally:

Your router successfully routed. This is the issue:

You need to ask your ISP the following question: "Why is your device with IP 2003:e5:9702:f801::1 blocking [ICMP Echo] requests to Google"?

If you feel that this is related to the OpenWrt config instead, please provide the output of:

cat /etc/config/network

I'm assuming that 2003:e5:9702:f801::1 is the LAN IPv6 of the OpenWrt router from the prefix delegation. I could be wrong.

1 Like

With a Global DNS PTR record?

It's possible.

Edit:

A traceroute6 from the client would be helpful.

Is the lack of IPv6 universal or does some clients gets connection and others don't? Because to me it sounds like this issue:

Yes, the domain dip0.t-ipconnect.de is used by Telekom here in Germany for dynamically assigned customer IP addresses. Both IPv4 and IPv6 addresses have auto-generated PTR records like that.

1 Like

Does your ISP offer routed prefixes or only a single /64 IP?

A single /64 is industry standard with LTE. In this case you will need to use relay mode. In relay mode the router LAN interface does not hold a GUA IPv6. "Pinging the router" consists of pinging its link-local IP. The router's link-local IP is the default route for endpoints (clients) on the LAN.

Your LAN clients should hold unique IPs with a GUA prefix that is the same /64. These can be assigned by RA/SLAAC and/or DHCPv6. When a client comes on-line, OpenWrt installs a /128 route for it via the lan interface. However the whole /64's route remains the wan interface. This is how relay works instead of prefix-based forwarding.

Thank you for your many responses.

Finding that out will be a Sisyphean task. Everyone here knows the Telekom call center guys. They know everything and nothing about their speed ports etc. but nothing about IPv6. They don't even know that this could exist.

The config of /etc/config/network:


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

config globals 'globals'
        option ula_prefix 'fd49:8bd1:464e::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan1'
        list ports 'lan2'
        list ports 'lan3'
        list ports 'lan4'

config bridge-vlan
        option device 'br-lan'
        option vlan '1'
        list ports 'lan1'
        list ports 'lan2'

config bridge-vlan
        option device 'br-lan'
        option vlan '2'
        list ports 'lan3'
        list ports 'lan4'

config interface 'office'
        option device 'br-lan.1'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '64'
        option ipaddr '192.168.0.1'
        list dns '217.237.151.161'
        list dns '8.8.8.8'
        list dns '8.8.4.4'
        option ifname ' tap0 tap0'

config interface 'home'
        option device 'br-lan.2'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '64'
        option ipaddr '192.168.1.1'

config device
        option name 'wan'
        option macaddr 'c6:41:1e:33:b4:3b'

config interface 'wan'
        option device 'wan'
        option type 'bridge'
        option proto 'pppoe'
        option username '________________________@t-online.de'
        option password 'XXXXXXX'
        option ipv6 'auto'
        option peerdns '0'
        list dns '8.8.8.8'
        list dns '8.8.4.4'
        list dns '217.237.151.161'

config interface 'wan6'
        option device 'wan'
        option proto 'dhcpv6'
        option type 'bridge'
        option peerdns '0'
        list dns '2001:4860:4860::8888'
        list dns '2001:4860:4860::8844'
        option reqaddress 'try'
        option reqprefix 'auto'
        list ip6class 'wan_6'
        option ip6assign '64'

config route
        option target '192.168.1.155'
        option gateway '192.168.1.1'
        option interface 'home'

config interface 'vpn0'
        option proto 'none'
        option device 'tun0

It only comes as far as the router interface:

traceroute6 www.google.com
traceroute to www.google.com (2a00:1450:4016:808::2004), 30 hops max, 80 byte packets
 1  p200300e597114c010000000000000001.dip0.t-ipconnect.de (2003:e5:9711:4c01::1)  0.248 ms  0.268 ms  0.285 ms
 2  p200300e597114c010000000000000001.dip0.t-ipconnect.de (2003:e5:9711:4c01::1)  0.320 ms  0.345 ms  0.372 ms

For comparison with IPv4

traceroute www.google.com
traceroute to www.google.com (142.251.36.164), 30 hops max, 60 byte packets
 1  OpenWrt-21_02.lan (192.168.0.1)  0.219 ms  0.206 ms  0.214 ms
 2  p3e9bf564.dip0.t-ipconnect.de (62.155.245.100)  8.574 ms  8.566 ms  8.557 ms
 3  m-ef1-i.M.DE.NET.DTAG.DE (217.0.193.234)  14.023 ms  14.024 ms  13.993 ms
 4  m-ef1-i.M.DE.NET.DTAG.DE (217.0.193.234)  13.739 ms  13.719 ms  13.731 ms
 5  80.157.129.174 (80.157.129.174)  13.046 ms  13.037 ms  13.428 ms
 6  * * *
 7  142.251.68.118 (142.251.68.118)  12.287 ms muc12s11-in-f4.1e100.net (142.251.36.164)  12.875 ms  12.832 ms

Maybe I gave wrong information in Luci. Could be?

The under 1 ms response time indicates that those two traceroute echoes were only from an address held inside your router, not anything down the line.

That gets obscured by having it resolve to names instead of numbers. Use the -n option to keep all IPs in numeric form.

This means of course that some sort of v6 Internet access is possible, but it isn't being routed from the lan. The lan clients must hold a routable IP, and the firewall allow lan to wan forwarding (which is the default, as long as whatever interface is the router wan is in the wan firewall zone). Also check the routing table that the route back to a lan client IP and/or prefix is via the lan interface.

1 Like

This only works via an interface on the router.

traceroute6 -n www.google.com
traceroute to www.google.com (2a00:1450:4016:80a::2004), 30 hops max, 80 byte packets
 1  2003:e5:9726:e601::1  0.244 ms  0.248 ms  0.264 ms
 2  2003:e5:9726:e601::1  0.297 ms  0.320 ms  0.339 ms

The IPv6 address on the client should be routable

ip -6 r
2003:e5:971f:4601::/64 dev enp3s0 proto kernel metric 256 expires 81979sec pref medium
2003:e5:9726:e601::/64 dev enp3s0 proto kernel metric 256 expires 86360sec pref medium
fd49:8bd1:464e:1::/64 dev enp3s0 proto kernel metric 256 pref medium
fe80::/64 dev enp3s0 proto kernel metric 256 pref medium
default via fe80::c641:1eff:fe33:b43b dev enp3s0 proto ra metric 1024 expires 1778sec mtu 1492 hoplimit 64 pref medium

However, I cannot ping my router from outside (external server on the web):

ping6 -c3 2003:e5:9726:e601::1
PING 2003:e5:9726:e601::1(2003:e5:9726:e601::1) 56 data bytes

--- 2003:e5:9726:e601::1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2047ms

The IPv6 had already worked with the same OpenWRT router. At that time I had the problem that he was looking for the dynm. Address changes could not be reliably passed on to the clients. This works now, but I upgraded the OpenWRT two weeks ago.
I hadn't changed anything on the firewall. That's why I don't understand why it doesn't route to the LAN.

After a system upgrade to OpenWrt 23.05 the whole thing works as expected!

Telekom Germany DSL Magenta foobar gives you a /56 since years. Btw afaik it is the only German provider with functional IPv6.

Functional IPv6 isn't that much of a problem with ISPs in Germany anymore, functional (as in globally routable, instead of only cgNAT) however is an issue with all of the newer ISPs (but obviously not with DTAG).

What do you then suggest as a solution to your statement?

Apart from the system upgrade on the OpenWRT router as a solution, I have just found another solution.
Because I have re-established an OpenVPN tunnel to an external server for NFS shares (backup options) on the OpenWRT router.
So if the OpenVPN instance is now active, the IPv6 routing between WAN and LAN interfaces will immediately stop working. If I deactivate OpenVPN again, IPv6 works again on the connected clients. Weird acting.

The obvious thing would be to check the v6 routing table to see if OpenVPN has altered it. I don't think it is supposed to if no v6 options are configured in OpenVPN.

Here with OpenVPN:

default from 2003:e5:9742:c00::/56 via fe80::ee13:dbff:fe7b:c882 dev pppoe-wan  metric 512 
default from 2003:e5:97ff:4259::/64 via fe80::ee13:dbff:fe7b:c882 dev pppoe-wan  metric 512 
2003:e5:9742:c00::/64 dev br-lan.2  metric 1024 
2003:e5:9742:c01::/64 dev br-lan.1  metric 1024 
2003:e5:9742:c02::/64 dev wan  metric 1024 
unreachable 2003:e5:9742:c00::/56 dev lo  metric 2147483647 
unreachable 2003:e5:97ff:4259::/64 dev lo  metric 2147483647 
2000::/3 dev tun0  metric 1024 
fd42:42:42:42::/112 dev tun0  metric 256 
fd49:8bd1:464e::/64 dev br-lan.2  metric 1024 
fd49:8bd1:464e:1::/64 dev br-lan.1  metric 1024 
unreachable fd49:8bd1:464e::/48 dev lo  metric 2147483647 
fe80::700d:4e03:e2e9:ab05 dev pppoe-wan  metric 256 
fe80::ee13:dbff:fe7b:c882 dev pppoe-wan  metric 256 
fe80::/64 dev eth0  metric 256 
fe80::/64 dev br-lan  metric 256 
fe80::/64 dev br-lan.1  metric 256 
fe80::/64 dev br-lan.2  metric 256 
fe80::/64 dev wan  metric 256 
fe80::/64 dev phy1-ap0  metric 256 
fe80::/64 dev phy0-ap0  metric 256 
fe80::/64 dev tun0  metric 256 
anycast 2003:e5:9742:c00:: dev br-lan.2  metric 0 
anycast 2003:e5:9742:c01:: dev br-lan.1  metric 0 
anycast 2003:e5:9742:c02:: dev wan  metric 0 
anycast 2003:e5:97ff:4259:: dev pppoe-wan  metric 0 
anycast fd42:42:42:42:: dev tun0  metric 0 
anycast fd49:8bd1:464e:: dev br-lan.2  metric 0 
anycast fd49:8bd1:464e:1:: dev br-lan.1  metric 0 
anycast fe80:: dev eth0  metric 0 
anycast fe80:: dev br-lan.2  metric 0 
anycast fe80:: dev br-lan  metric 0 
anycast fe80:: dev br-lan.1  metric 0 
anycast fe80:: dev wan  metric 0 
anycast fe80:: dev phy1-ap0  metric 0 
anycast fe80:: dev phy0-ap0  metric 0 
anycast fe80:: dev tun0  metric 0 
multicast ff00::/8 dev eth0  metric 256 
multicast ff00::/8 dev br-lan.1  metric 256 
multicast ff00::/8 dev br-lan.2  metric 256 
multicast ff00::/8 dev br-lan  metric 256 
multicast ff00::/8 dev wan  metric 256 
multicast ff00::/8 dev pppoe-wan  metric 256 
multicast ff00::/8 dev phy1-ap0  metric 256 
multicast ff00::/8 dev phy0-ap0  metric 256 
multicast ff00::/8 dev tun0  metric 256

And here without OpenVPN:

default from 2003:e5:9742:c00::/56 via fe80::ee13:dbff:fe7b:c882 dev pppoe-wan  metric 512 
default from 2003:e5:97ff:4259::/64 via fe80::ee13:dbff:fe7b:c882 dev pppoe-wan  metric 512 
2003:e5:9742:c00::/64 dev br-lan.2  metric 1024 
2003:e5:9742:c01::/64 dev br-lan.1  metric 1024 
2003:e5:9742:c02::/64 dev wan  metric 1024 
unreachable 2003:e5:9742:c00::/56 dev lo  metric 2147483647 
unreachable 2003:e5:97ff:4259::/64 dev lo  metric 2147483647 
fd49:8bd1:464e::/64 dev br-lan.2  metric 1024 
fd49:8bd1:464e:1::/64 dev br-lan.1  metric 1024 
unreachable fd49:8bd1:464e::/48 dev lo  metric 2147483647 
fe80::700d:4e03:e2e9:ab05 dev pppoe-wan  metric 256 
fe80::ee13:dbff:fe7b:c882 dev pppoe-wan  metric 256 
fe80::/64 dev eth0  metric 256 
fe80::/64 dev br-lan  metric 256 
fe80::/64 dev br-lan.1  metric 256 
fe80::/64 dev br-lan.2  metric 256 
fe80::/64 dev wan  metric 256 
fe80::/64 dev phy1-ap0  metric 256 
fe80::/64 dev phy0-ap0  metric 256 
anycast 2003:e5:9742:c00:: dev br-lan.2  metric 0 
anycast 2003:e5:9742:c01:: dev br-lan.1  metric 0 
anycast 2003:e5:9742:c02:: dev wan  metric 0 
anycast 2003:e5:97ff:4259:: dev pppoe-wan  metric 0 
anycast fd49:8bd1:464e:: dev br-lan.2  metric 0 
anycast fd49:8bd1:464e:1:: dev br-lan.1  metric 0 
anycast fe80:: dev eth0  metric 0 
anycast fe80:: dev br-lan.2  metric 0 
anycast fe80:: dev br-lan  metric 0 
anycast fe80:: dev br-lan.1  metric 0 
anycast fe80:: dev wan  metric 0 
anycast fe80:: dev phy1-ap0  metric 0 
anycast fe80:: dev phy0-ap0  metric 0 
multicast ff00::/8 dev eth0  metric 256 
multicast ff00::/8 dev br-lan.1  metric 256 
multicast ff00::/8 dev br-lan.2  metric 256 
multicast ff00::/8 dev br-lan  metric 256 
multicast ff00::/8 dev wan  metric 256 
multicast ff00::/8 dev pppoe-wan  metric 256 
multicast ff00::/8 dev phy1-ap0  metric 256 
multicast ff00::/8 dev phy0-ap0  metric 256

Six additional routes have been added

This is a big deal, it will send general requests to any public GUA Internet address (which all start with 2 or 3) to the tunnel. It works like a default route. The OpenVpn server needs to be able to route to the v6 Internet.