Print

[balomiri]

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?

[tomkep]

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

[balomiri]

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

[tomkep]

I don't know who filters it (you, HE or someone else) but someone definitely is:

triss:~> 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.

[balomiri]

IMHO the issue is that the IPv6 LAN is not fully exposed to internet. This is due to dd-wrt implementation of IPv6!?

proof:

Code: [Select]

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

[balomiri]

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:

Code: [Select]

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

[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.