OpenWrt IKEv2 NAT traversal (or similar) problem

[Yousong Zhou]

On Wed, 31 May 2023 at 22:20, Peter Naulls <peter at chocky.org> wrote:
>
> On 5/30/23 21:09, Yousong Zhou wrote:
> > On Wed, 31 May 2023 at 06:38, Peter Naulls <peter at 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