IPv6 mit Netcat: Operation timed out

[Krull]

Hallo,

weiß jemand vielleicht wieso das hier funktioniert:

root:/root>nmap -6 2610:10:20:722:a800:ff:feda:470f 
Starting Nmap 7.91 ( https://nmap.org ) at 2022-01-06 13:17 CET
sendmsg: Permission denied
Nmap scan report for 2610:10:20:722:a800:ff:feda:470f
Host is up (0.17s latency).
Not shown: 849 closed ports, 145 filtered ports
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
443/tcp  open  https
873/tcp  open  rsync
3128/tcp open  squid-http
6667/tcp open  irc

Nmap done: 1 IP address (1 host up) scanned in 22.92 seconds

das aber nicht:

root:/root>nc -vz6 2610:10:20:722:a800:ff:feda:470f 80
nc: connect to 2610:10:20:722:a800:ff:feda:470f port 80 (tcp) failed: Operation timed out

Betrifft allgemein IPv6, v4 ist ok.

 

[morromett]

weiß jemand vielleicht wieso das hier funktioniert:

root:/root>nmap -6 2610:10:20:722:a800:ff:feda:470f
[code]
root:/root>nc -vz6 2610:10:20:722:a800:ff:feda:470f 80

wenn Du es genau wissen willst, kannst Du z. B. mit tcpdump (und dem geeigneten Filter) nachschauen, welche Datenpakete bzw. welche Antworten, mit nmap und welche mit nc gesendet und empfangen (oder nicht empfangen) werden.

 

[Krull]

wenn Du es genau wissen willst, kannst Du z. B. mit tcpdump (und dem geeigneten Filter) nachschauen, welche Datenpakete bzw. welche Antworten, mit nmap und welche mit nc gesendet und empfangen (oder nicht empfangen) werden.

Hhmm, so ganz genau weiß ich jetzt leider immer noch nicht:

root:/root>timeout 30 tcpdump -i wg0 -n -w nmap.pcap host 2610:10:20:722:a800:ff:feda:470f & nmap -Pn -6 2610:10:20:722:a800:ff:feda:470f -p 443                                                                                                                                                                                                      
...
root:/root>tcpdump -vvv -r nmap.pcap                                                                                                      

reading from file nmap.pcap, link-type NULL (BSD loopback)                                                                                                                                                                                                                                                                                                  
16:09:11.670088 IP6 (hlim 255, next-header TCP (6) payload length: 24) fd03:1333::225.59210 > 2610:10:20:722:a800:ff:feda:470f.https: Flags [S], cksum 0x447e (correct), seq 1
947059176, win 1024, options [mss 1460], length 0                                                                                                                                                                                                                                                                                                           
16:09:11.837526 IP6 (flowlabel 0x72b35, hlim 49, next-header TCP (6) payload length: 24) 2610:10:20:722:a800:ff:feda:470f.https > fd03:1333::225.59210: Flags [S.], cksum 0x33
02 (correct), seq 3512747993, ack 1947059177, win 64800, options [mss 1220], length 0

16:09:12.849025 IP6 (flowlabel 0x31f9b, hlim 49, next-header TCP (6) payload length: 24) 2610:10:20:722:a800:ff:feda:470f.https > fd03:1333::225.59210: Flags [S.], cksum 0x33
02 (correct), seq 3512747993, ack 1947059177, win 64800, options [mss 1220], length 0

16:09:14.864533 IP6 (flowlabel 0x8e71f, hlim 49, next-header TCP (6) payload length: 24) 2610:10:20:722:a800:ff:feda:470f.https > fd03:1333::225.59210: Flags [S.], cksum 0x33
02 (correct), seq 3512747993, ack 1947059177, win 64800, options [mss 1220], length 0

16:09:19.025067 IP6 (flowlabel 0x75214, hlim 49, next-header TCP (6) payload length: 24) 2610:10:20:722:a800:ff:feda:470f.https > fd03:1333::225.59210: Flags [S.], cksum 0x33
02 (correct), seq 3512747993, ack 1947059177, win 64800, options [mss 1220], length 0

16:09:27.217000 IP6 (flowlabel 0xc901a, hlim 49, next-header TCP (6) payload length: 24) 2610:10:20:722:a800:ff:feda:470f.https > fd03:1333::225.59210: Flags [S.], cksum 0x33
02 (correct), seq 3512747993, ack 1947059177, win 64800, options [mss 1220], length 0

root:/root>timeout 5 tcpdump -i wg0 -n -w nc.pcap host 2610:10:20:722:a800:ff:feda:470f & nc -w 5 -vz 2610:10:20:722:a800:ff:feda:470f 443

...
root:/root>tcpdump -vvv -r nc.pcap

reading from file nc.pcap, link-type NULL (BSD loopback)

15:47:24.891187 IP6 (flowlabel 0x43b01, hlim 49, next-header TCP (6) payload length: 40) 2610:10:20:722:a800:ff:feda:470f.https > fd03:1333::225.33088: Flags [S.], cksum 0x88
72 (correct), seq 1442103153, ack 1014389405, win 64260, options [mss 1220,sackOK,TS val 2326896946 ecr 1717097738,nop,wscale 7], length 0

15:47:25.732276 IP6 (flowlabel 0x66ed8, hlim 64, next-header TCP (6) payload length: 40) fd03:1333::225.33088 > 2610:10:20:722:a800:ff:feda:470f.https: Flags [S], cksum 0xc05
5 (correct), seq 1014389404, win 65535, options [mss 1360,nop,wscale 6,sackOK,TS val 1717098748 ecr 0], length 0

15:47:25.900467 IP6 (flowlabel 0xc8ede, hlim 49, next-header TCP (6) payload length: 40) 2610:10:20:722:a800:ff:feda:470f.https > fd03:1333::225.33088: Flags [S.], cksum 0x84
81 (correct), seq 1442103153, ack 1014389405, win 64260, options [mss 1220,sackOK,TS val 2326897955 ecr 1717097738,nop,wscale 7], length 0

15:47:26.926494 IP6 (flowlabel 0xef7e9, hlim 49, next-header TCP (6) payload length: 40) 2610:10:20:722:a800:ff:feda:470f.https > fd03:1333::225.33088: Flags [S.], cksum 0x80
7e (correct), seq 1442103153, ack 1014389405, win 64260, options [mss 1220,sackOK,TS val 2326898982 ecr 1717097738,nop,wscale 7], length 0

15:47:27.943313 IP6 (flowlabel 0x66ed8, hlim 64, next-header TCP (6) payload length: 40) fd03:1333::225.33088 > 2610:10:20:722:a800:ff:feda:470f.https: Flags [S], cksum 0xb7b
2 (correct), seq 1014389404, win 65535, options [mss 1360,nop,wscale 6,sackOK,TS val 1717100959 ecr 0], length 0

15:47:28.110912 IP6 (flowlabel 0x450c2, hlim 49, next-header TCP (6) payload length: 40) 2610:10:20:722:a800:ff:feda:470f.https > fd03:1333::225.33088: Flags [S.], cksum 0x7b
de (correct), seq 1442103153, ack 1014389405, win 64260, options [mss 1220,sackOK,TS val 2326900166 ecr 1717097738,nop,wscale 7], length 0

 

[morromett]

Hhmm, so ganz genau weiß ich jetzt leider immer noch nicht:

root:/root>timeout 30 tcpdump -i wg0 -n -w nmap.pcap host 2610:10:20:722:a800:ff:feda:470f & nmap -Pn -6 2610:10:20:722:a800:ff:feda:470f -p 443

Der Filter für tcpdump ist nicht optimal. Versuch mal mit:

tcpdump -c 50 -vvveni any host 2610:10:20:722:a800:ff:feda:470f and port 80

Bist Du sicher, dass dein Traffic mit nmap und nc, immer das wg0-Interface benutzt hat?
Den Portscan mit nmap machst Du jetzt nur auf den Port 80:

nmap -6 -sS 2610:10:20:722:a800:ff:feda:470f -p80

nc -6 -zv 2610:10:20:722:a800:ff:feda:470f 80

tcpdump muss nicht in eine Datei schreiben, denn das geht auch nach stdout.

 

[Krull]

Der Filter für tcpdump ist nicht optimal. Versuch mal mit:
tcpdump -c 50 -vvveni any host 2610:10:20:722:a800:ff:feda:470f and port 80

# tcpdump -c 50 -vvveni any host 2610:10:20:722:a800:ff:feda:470f and port 80                                                              
tcpdump: any: No such device exists
(BIOCSETIF failed: Device not configured)

Laut Manpage gibt es 'any' wohl nur bei Linux.

Aber:

$ nc -vz 2610:10:20:722:a800:ff:feda:470f 443
Connection to 2610:10:20:722:a800:ff:feda:470f 443 port [tcp/https] succeeded!

Tja, keine Ahnung wieso das jetzt geht und vorher nicht :-/ Ich werde mal beobachten, ob es die nächsten Tage vielleicht wieder klemmt.

 

[Krull]

So wie es aussieht, liegt es an der Firewall. Nmap kann sich offenbar irgendwie durchschlängeln, Netcat aber nicht. Mit abgeschaltetem PF geht beides.

pf.conf:

set skip on lo
block in all
block return out all

pass in on wlan0 proto icmp from 192.168.0.0/16 keep state
pass in on wlan0 proto ipv6-icmp from fe80::/10 keep state

pass out on wlan0 to { 192.168.0.0/16 fe80::/10 ff00::/8 } keep state
pass out on wlan0 to wg0 keep state
pass out on wg0 to any keep state

Die letzten beiden Regeln sollen eigentlich nichts blockieren, aber dennoch den Datenverkehr stoppen, wenn das VPN ausfällt. Aber für IPv6 scheint das noch nicht ganz zu passen...

 

[jmt]

Ich hatte ein ähnliches Problem. Da lag es an der MTU für Wireguard. Die musste ich für IPv6 von 1420 auf 1412 verringern.

 

[Yamagi]

Da sagt @jmt direkt was. Ich habe mit meinem Tunnelbroker-Tunnel irgendwann kapituliert und aufgegeben zu versuchen alleine mit Path MTU Discovery auszukommen. Der Tunnel selbst hat eine MTU von 1472 gesetzt. Das sind 1500 - 20 Byte Tunnelheader - 8 Byte PPPoE-Header. Die 8 Byte für den PPPoE-Header sollten nicht notwendig sein, aber sicher ist sicher. Darauf kommt der Hammer in der pf.conf, inklusive giftigem Kommentar:

# The IPv6 tunnel has a MTU of 1472 (1500 bytes - 20 bytes tunnel
# header - 8 bytes PPPoE header to be on the save side). With that
# PMTU discovery works fine with nearly all hosts. But at least
# netflix.com and bahn.de fail to send any data. While the discovered
# PMTU is correct, the calculated MSS is always 8 bytes too large. I never
# figured out why, it may be related to the PPPoE header. Clamp the
# MSS to 1412 (1472 - 40 byte IPv6 header - 20 bytes TCP header) to
# work around that problem.
#
# There's at least one report of the same problem on the net:
# https://www.reddit.com/r/ipv6/comments/evv7r8/ipv6_and_netflix/fg66bbw/?utm_source=reddit&utm_medium=web2x&context=3
scrub on gif0 all max-mss 1412 fragment reassemble

Auch wenn mir das nicht gefällt ist seitdem Ruhe und die Sache tut einwandfrei. In diesem Fall ist es ein gif-Tunnel. Andere Tunneltypen und VPN-Systeme haben eventuell andere Headergrößen und brauchen entsprechend angepasste Werte.

 

[Krull]

Hmm, irgend etwas fehlt wohl noch. Ich habe nun sowohl in wg0.conf "MTU = 1412" als auch "scrub on wg0 all max-mss 1412 fragment reassemble" in die pf.conf eingetragen (vor 'block in all'). Jeweils einzeln, aber auch beides gleichzeitig. Aber Netcat mag leider immer noch nicht mit IPv6 :-/

 

[midnight]

So wie es aussieht, liegt es an der Firewall. Nmap kann sich offenbar irgendwie durchschlängeln, Netcat aber nicht. Mit abgeschaltetem PF geht beides.

pf.conf:

set skip on lo
block in all
block return out all

pass in on wlan0 proto icmp from 192.168.0.0/16 keep state
pass in on wlan0 proto ipv6-icmp from fe80::/10 keep state

pass out on wlan0 to { 192.168.0.0/16 fe80::/10 ff00::/8 } keep state
pass out on wlan0 to wg0 keep state
pass out on wg0 to any keep state

Die letzten beiden Regeln sollen eigentlich nichts blockieren, aber dennoch den Datenverkehr stoppen, wenn das VPN ausfällt. Aber für IPv6 scheint das noch nicht ganz zu passen...

Schon probiert, proto icmp und proto ipv6-icmp wegzulassen oder proto { icmp tcp udp } bzw. proto { ipv6-icmp tcp udp } zu definieren? Netcat kann meines Wissens nach kein icmp, nmap allerdings schon.

 

[Krull]

Schon probiert, proto icmp und proto ipv6-icmp wegzulassen oder proto { icmp tcp udp } bzw. proto { ipv6-icmp tcp udp } zu definieren? Netcat kann meines Wissens nach kein icmp, nmap allerdings schon.

Du meinst die beiden "pass in"-Regeln weglassen? Diese beziehen sich ja nur auf das lokale Netz. Damit gibt es keine Probleme. Auch Netcat funktioniert mit lokalem v6:

$ nc -vz fe80::fd2a:b523:ed0f:1a1a%wlan0 22
Connection to fe80::fd2a:b523:ed0f:1a1a%wlan0 22 port [tcp/ssh] succeeded!

 

[midnight]

Du meinst die beiden "pass in"-Regeln weglassen? Diese beziehen sich ja nur auf das lokale Netz. Damit gibt es keine Probleme.

Um zu schauen, obs an den letzten beiden Regeln liegt, setze doch einfach mal ein pass on wg0 ans Ende deiner /etc/pf.conf

 

[Krull]

Um zu schauen, obs an den letzten beiden Regeln liegt, setze doch einfach mal ein pass on wg0 ans Ende deiner /etc/pf.conf

# echo "pass on wg0" >> /etc/pf.conf
# pfctl -f /etc/pf.conf
# nc -vz 2610:10:20:722:a800:ff:feda:470f 443
nc: connect to 2610:10:20:722:a800:ff:feda:470f port 443 (tcp) failed: Operation timed out

 

[Krull]

Tja, das Problem hat sich augenscheinlich verflüchtigt. Vor einer Woche habe ich das System von 12.2 -> 13.0 aktualisiert. Seitdem macht Netcat keine Schwierigkeiten mehr. Leider weiß ich nicht, woran genau es gelegen hat. Die zwischenzeitlichen Änderungen an Wireguard und pf habe ich jedenfalls wieder zurück genommen.