Closed gtxaspec closed 1 year ago
Ok, forget everything I said before; I brainfarted badly.
So the way I see it, your network is like this, right?
+--------+ IPv6 +---------+ IPv4 +-----------------------+
| V |--------| T |--------| www.cpc.ncep.noaa.gov |
| (CLAT) | | (NAT64) | | |
+--------+ +---------+ +-----------------------+
You're telling me a curl from T to cpc works. IPv6 from V to cpc works as well. IPv4 from V to cpc doesn't.
Ok. I'm currently abroad, and lack access to my hardware. I'll be back on Monday, though I will probably have to postpone the actual testing until Tuesday.
But I can ask some preliminary questions:
ifconfig
instead of ip address
. Is this because of the distro?Actually, your tcpdump implies the endpoints can reach each other. Guess I really can't solve this without hitting the lab.
Comment above heavily edited; please disregard the email version.
@ydahhrk thank you for looking at this.
You're telling me a curl from T to cpc works. IPv6 from V to cpc works as well. IPv4 from V to cpc doesn't.
cpc is ipv4 only T to cpc works IPv6 from V to cpc works (dns64) IPv4 from V to cpc doesn't work
ip a
=DPing from V's outer namespace to V's inner namespace:
root@V:~# traceroute 192.0.0.1
traceroute to 192.0.0.1 (192.0.0.1), 30 hops max, 60 byte packets
1 192.0.0.1 (192.0.0.1) 0.035 ms 0.005 ms 0.004 ms
root@V:~# ping 192.0.0.1
PING 192.0.0.1 (192.0.0.1) 56(84) bytes of data.
64 bytes from 192.0.0.1: icmp_seq=1 ttl=64 time=0.034 ms
64 bytes from 192.0.0.1: icmp_seq=2 ttl=64 time=0.047 ms
64 bytes from 192.0.0.1: icmp_seq=3 ttl=64 time=0.049 ms
--- 192.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2034ms
rtt min/avg/max/mdev = 0.034/0.043/0.049/0.006 ms
From V inner namespace to T using ipv6:
root@V:~# ip netns exec jool ping 2001:db7:b0a3:3000::1
PING 2001:db7:b0a3:3000::1(2001:db7:b0a3:3000::1) 56 data bytes
64 bytes from 2001:db7:b0a3:3000::1: icmp_seq=1 ttl=62 time=0.095 ms
64 bytes from 2001:db7:b0a3:3000::1: icmp_seq=2 ttl=62 time=0.098 ms
--- 2001:db7:b0a3:3000::1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1030ms
rtt min/avg/max/mdev = 0.095/0.096/0.098/0.001 ms
Hi @gtxaspec and @ydahhrk
At the university, I have an environment with a Wi-Fi network using 464XLAT. I have noticed the same behavior reported on some sites, only when the client machine only uses IPv4 on its interface.
Windows client machine IP:
Network Adapter Wi-Fi:
Sufixo DNS específico de conexão. . . . . . : fca.unicamp.br Endereço IPv4. . . . . . . . . . . . . . . : 192.168.200.111 Máscara de Sub-rede . . . . . . . . . . . . : 255.255.255.0 Gateway Padrão. . . . . . . . . . . . . . . : 192.168.200.1
The mapping in PLAT is proceeding normally:
Jool: default 2022/12/14 17:45:25 (GMT) - Added session 2801:8a:c040:200:6f00::#59753|64:ff9b::c8a0:406#443|143.106.230.240#47222|200.160.4.6#443|TCP
However, running a test in curl, stops when exchanging SSL certificates and does not transfer site data.
C:\Users\Henri\curl https://www.nic.br -vvvv
Using Wireshark, the exchange of SSL certificates appears, but then there is no data exchange. Interesting that several [TCP Dup ACK] appear, and there is no more response.
I am still trying to figure out what could be going on.
When the client machine receives the double stack, there is no problem because the path is made by IPv6, not involving the translation in Jool PLAT.
Thanks
@gtxaspec can you try what happens after you run
ip link set clat mtu 1400
or
ip6tables -t mangle -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
@IndeedNotJames confirmed, connections now working with ip link set clat mtu 1400
or ip6tables -t mangle -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
completely forgot about MTU in this situation... lol
thank you!
Hi @gtxaspec and @IndeedNotJames
Wowwww very good, I confirm that changing the MTU of the network interface to 1400 of the client machines connected to WiFi, several sites worked. Great :-))
Now could someone explain the reason for this behavior only in this specific case, I was curious.
Thanks all !
Host T: Stateful NAT64 Translator Host V: ipv6 server using node based translation clat ( directions followed from https://nicmx.github.io/Jool/en/node-based-translation.html, using pool6 )
All running jool 4.1.8.0
host V ifconfig output:
host V:
host V tcpdump of the above curl:
works as expected if i curl it from T directly... also works fine from V using DNS64 w/NAT64 from T also works using clatd + tayga... but I like jool =D
What would be preventing the TLS handshake from working properly while using jool?