Router Model: Asus RT-AC68U C1
Firmware Version:DD-WRT v3.0-r47695 std (11/29/21)
Kernel Version: Linux 4.4.293 #4478 SMP
=====
HE Tunnel works outbound ok (aka from a LAN host to an internet destination host
# traceroute6 google.com
traceroute to google.com (2a00:1450:4014:800::200e), 30 hops max, 64 byte packets
1 tunnel679637.tunnel.tserv27.prg1.ipv6.he.net (2001:470:6e:2af::1) 72.119 ms 155.621 ms 134.423 ms
2 10ge2-1.core1.prg1.he.net (2001:470:0:221::1) 111.130 ms 139.036 ms 120.566 ms
3 nixcz-v6.net.google.com (2001:7f8:14::1d:1) 116.550 ms 641.548 ms 490.298 ms
4 2001:4860:0:101a::1 (2001:4860:0:101a::1) 150.192 ms 151.816 ms 2001:4860:0:1019::1 (2001:4860:0:1019::1) 163.484 ms
5 2001:4860:0:1::1dfd (2001:4860:0:1::1dfd) 142.201 ms 2001:4860:0:1::1c83 (2001:4860:0:1::1c83) 160.391 ms 276.248 ms
6 prg03s01-in-x0e.1e100.net (2a00:1450:4014:800::200e) 372.200 ms 275.421 ms 560.619 ms
======
but
HE Tunnel does not reach destination inbound (from internet to LAN host)
#traceroute6 x.y.net
traceroute to x.y.net (2001:470:1f0a:813::2), 30 hops max, 64 byte packets
1 tunnel679637.tunnel.tserv27.prg1.ipv6.he.net (2001:470:6e:2af::1) 34.887 ms 35.994 ms 28.516 ms
2 10ge2-1.core1.prg1.he.net (2001:470:0:221::1) 20.314 ms 15.542 ms 25.843 ms
3 100ge16-1.core1.fra1.he.net (2001:470:0:213::1) 35.004 ms 46.489 ms 38.700 ms
4 tserv1.fra1.he.net (2001:470:0:69::2) 40.583 ms 35.104 ms 36.302 ms
5 * * *
6
=======
but
ping works well on same target host
ping6 x.y.net
PING x.y.net (2001:470:1f0a:813::2): 56 data bytes
64 bytes from 2001:470:1f0a:813::2: seq=0 ttl=60 time=157.343 ms
64 bytes from 2001:470:1f0a:813::2: seq=1 ttl=60 time=723.237 ms
What is missing?
Traceroute by default uses UDP packets to port 53 (DNS). If you filtered it - it is obviously not responding.
You can try traceroute6 with -I option (capital i) for ICMPv6 tracerouting. This requires root priviliges however:
triss:~> sudo traceroute6 -I 2001:470:1f0a:813::2
traceroute to 2001:470:1f0a:813::2 (2001:470:1f0a:813::2), 30 hops max, 80 byte packets
1 boholt.jot23.net (2a0e:b107:c01:11::1) 0.282 ms 0.289 ms 0.326 ms
2 as212888.r1-haa-nl.node.freetransit.ch (2a01:20e:1002:123::1) 57.793 ms 57.814 ms 57.811 ms
3 * * *
4 port-channel6.core2.ams2.he.net (2001:470:0:61c::2) 59.781 ms 59.790 ms 59.820 ms
5 100ge10-2.core1.fra2.he.net (2001:470:0:4b7::1) 73.479 ms 73.481 ms 111.027 ms
6 100ge16-2.core1.fra1.he.net (2001:470:0:404::1) 111.037 ms 109.145 ms 109.120 ms
7 tserv1.fra1.he.net (2001:470:0:69::2) 109.110 ms 78.213 ms 80.034 ms
8 tunnel571285-pt.tunnel.tserv6.fra1.ipv6.he.net (2001:470:1f0a:813::2) 110.547 ms 106.206 ms 106.171 ms
Great, many thanks. (This explains btw why windows/tracert finds the route)
BUT the issue is deeper.
https://[2001:470:1f0b:815:5e49:79ff:fe42:3742]:41457 (example) does not work
The same IPv6 addr shows both
# ping6 2001:470:1f0b:815:5e49:79ff:fe42:3742 -c4
PING6(56=40+8+8 bytes) 2001:470:6f:2af:f09d:34ab:32d4:7d1f --> 2001:470:1f0b:815:5e49:79ff:fe42:3742
16 bytes from 2001:470:1f0b:815:5e49:79ff:fe42:3742, icmp_seq=0 hlim=58 time=56.203 ms
16 bytes from 2001:470:1f0b:815:5e49:79ff:fe42:3742, icmp_seq=1 hlim=58 time=645.630 ms
16 bytes from 2001:470:1f0b:815:5e49:79ff:fe42:3742, icmp_seq=2 hlim=58 time=49.874 ms
16 bytes from 2001:470:1f0b:815:5e49:79ff:fe42:3742, icmp_seq=3 hlim=58 time=71.052 ms
and
traceroute6 -I 2001:470:1f0b:815:5e49:79ff:fe42:3742
traceroute6 to 2001:470:1f0b:815:5e49:79ff:fe42:3742 (2001:470:1f0b:815:5e49:79ff:fe42:3742) from 2001:470:6f:2af:f09d:34ab:32d4:7d1f, 64 hops max, 16 byte packets
1 bubuasus 1.475 ms 1.463 ms 2.748 ms
2 tunnel679637.tunnel.tserv27.prg1.ipv6.he.net 18.597 ms 26.606 ms 20.439 ms
3 10ge2-1.core1.prg1.he.net 20.473 ms 24.037 ms 16.330 ms
4 100ge16-1.core1.fra1.he.net 25.660 ms 26.684 ms 44.987 ms
5 tserv1.fra1.he.net 29.863 ms 29.386 ms *
6 tunnel571285-pt.tunnel.tserv6.fra1.ipv6.he.net 62.612 ms * 46.743 ms
7 2001:470:1f0b:815:5e49:79ff:fe42:3742 51.810 ms 65.744 ms 95.876 ms
I'm not aware filtering anything...
Some hint? Thanks in advance....
I don't know who filters it (you, HE or someone else) but someone definitely is:
Quotetriss:~> nmap -6 -Pn 2001:470:1f0b:815:5e49:79ff:fe42:3742
Starting Nmap 7.70 ( https://nmap.org ) at 2021-12-01 10:28 CET
Nmap scan report for 2001:470:1f0b:815:5e49:79ff:fe42:3742
Host is up (0.077s latency).
Not shown: 993 filtered ports
PORT STATE SERVICE
25/tcp closed smtp
6666/tcp closed irc
6667/tcp closed irc
6668/tcp closed irc
6669/tcp closed irc
7000/tcp closed afs3-fileserver
9999/tcp closed abyss
Nmap done: 1 IP address (1 host up) scanned in 28.12 seconds
All the ports reported as closed above are rejected by HE as they by default don't allow them and doing tcp-reset / icmp-port-unreachable facilitates fast failure here.
As for filtered ports - I have no clue. But I would check firewall on both your router and end-node.
IMHO the issue is that the IPv6 LAN is not fully exposed to internet. This is due to dd-wrt implementation of IPv6!?
proof:
map done: 1 IP address (1 host up) scanned in 152.12 seconds
jupan@macaz ~ % nmap -6 -Pn 2001:470:1f0b:815:5e49:79ff:fe42:3742 -p 41455
Starting Nmap 7.92 ( https://nmap.org ) at 2021-12-01 12:35 CET
Nmap scan report for 2001:470:1f0b:815:5e49:79ff:fe42:3742
Host is up.
PORT STATE SERVICE
41455/tcp filtered unknown
Nmap done: 1 IP address (1 host up) scanned in 2.61 seconds
expected is that the IPv6 host is completely exposed if not explicitly port-wise closed.
Contingency plan: will give a try to ASUSWRT-MERLIN
Solved!
the analysis suggested by you TomKep brought me to the ideea that there is an IPv6 Firewall (not really visible on WEBGUI of dd-wrt) which caused the drop of WAN->LAN access.
So I flushed, for testing, all ip6tables and now the LAN is "naked" in Intenet.
proof:
nmap -6 -Pn vicsfritze.balomiri.net -p 41457
Starting Nmap 7.92 ( https://nmap.org ) at 2021-12-01 13:59 CET
Nmap scan report for vicsfritze.balomiri.net (2001:470:1f0b:815:5e49:79ff:fe42:3742)
Host is up (0.052s latency).
Other addresses for vicsfritze.balomiri.net (not scanned): 192.168.237.3
PORT STATE SERVICE
41457/tcp open unknown
Nmap done: 1 IP address (1 host up) scanned in 0.36 seconds
Thanks again for your impulses TomKep
This actually might be expected, depending on what firewall management software DD-WRT uses... I stick with plain iptables/nftables, any layer above that makes firewall rules incomprehensible. But if you use it you should invest some time in understanding exactly how it works.