OpenWrt IKEv2 NAT traversal (or similar) problem

[Peter Naulls]

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.

Thanks again.