On Wed, 31 May 2023 at 22:20, Peter Naulls <pe...@chocky.org> wrote:
>
> 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.
Not that I got any clue, but this looks very suspicious that you saw
the supposed-to-go-through-tunnel packet at an intermediate router
(the openwrt device).
Regards,
yousong
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
