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
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.
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.
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.
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
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.
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):
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.
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).
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.
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
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.