On 5/30/23 21:09, Yousong Zhou wrote:
On Wed, 31 May 2023 at 06:38, Peter Naulls <pe...@chocky.org> wrote:
Is it that your dns traffic is not going through the tunnel? curl
-vvv should reveal the IP address it tries to connect. One
possibility is that maybe the resolv result does not work.
Yes, a DNS was an early check, I don't think this is the problem though.
When I said no data comes back from curl, this wasn't 100% correct - here's
the output (https://www.yahoo.com/ which is another problem site):
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0*
Trying 74.6.231.21:443...
* Connected to www.yahoo.com (74.6.231.21) port 443 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
* CAfile: C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
* CApath: none
} [5 bytes data]
* [CONN-0-0][CF-SSL] TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
0 0 0 0 0 0 0 0 --:--:-- 0:00:04 --:--:-- 0
In Wireshark on the VPN interface, I can see that after the TLSv1 Client
Hello and then ACK, after that I get two errors:
"TCP Previous segment not captured" (port 443) and "Dup ACK". The latter might
just be a side effect of VPN retries or something.
Looking at the interface itself, during the stream of ESP packets, we get a
TCP re transmission packet from the VPN host to the LAN IP, which seems wrong.
This is a match for this tcpdump from br-lan on OpenWrt:
14:14:45.368484 IP (tos 0x0, ttl 255, id 64433, offset 0, flags [none], proto
UDP (17), length 128)
192.168.113.102.4500 > 89.187.170.130.4500: [no cksum] UDP-encap:
ESP(spi=0xce938746,seq=0x52), length 100
14:14:47.919812 IP (tos 0x68, ttl 60, id 18554, offset 0, flags [none], proto
TCP (6), length 342)
20.25.241.18.443 > 192.168.113.102.62792: Flags [P.], cksum 0x12c7
(correct), seq 0:302, ack 1, win 172, length 302
14:14:50.120142 IP (tos 0x0, ttl 255, id 64434, offset 0, flags [none], proto
UDP (17), length 112)
192.168.113.102.4500 > 89.187.170.130.4500: [no cksum] UDP-encap:
ESP(spi=0xce938746,seq=0x53), length 84
Which I think is already a clue - the response is coming back via TCP 443 not
over the VPN UDP 4500.
Thanks again.
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
