Bad encapsulated packet length from peer (2989)

[pro-sumer]

Summary

When trying to connect to the OpenVPN server running on my ASUS RT-AC86U router (running Asuswrt-Merlin 384.7 firmware) in Passepartout for iOS the status changes from "Connecting" to "Inactive", with this error message:

WARNING: Bad encapsulated packet length from peer (2989), which must be > 0 and <= 1626 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]

Steps to reproduce

1. Export .ovpn profile (attached below) from router interface
2. Import profile in Passepartout
3. Select new host
4. Tap "Use this profile"

What is the current bug behavior?

Unable to connect iPhone/iPad to VPN provided by router.

What is the expected correct behavior?

Successful connection to VPN provided by router on iPhone/iPad.

Note that the same profile works fine when using OpenVPN Connect instead of Passepartout.

Relevant logs and/or screenshots

Server (router) log:

TCP connection established with [AF_INET]<IP address of iPhone>:443
<IP address of iPhone>:<port> TLS: Initial packet from [AF_INET]<IP address of iPhone>:443, sid=<redacted> <redacted>
<IP address of iPhone>:<port> WARNING: Bad encapsulated packet length from peer (2989), which must be > 0 and <= 1626 -- please ensure that both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
<IP address of iPhone>:<port> Connection reset, restarting [0]
<IP address of iPhone>:<port> SIGUSR1[soft,connection-reset] received, client-instance restarting

Client (iPhone) log:

App: Passepartout 1.0 (1040)
OS: iOS 12.0.1
Device: iPhone

11:24:27 - Starting tunnel...
11:24:27 - App version: Passepartout 1.0 (1040)
11:24:27 - 	Protocols: [TCP:443]
11:24:27 - 	Cipher: AES-128-CBC
11:24:27 - 	Digest: HMAC-SHA1
11:24:27 - 	Client verification: enabled
11:24:27 - 	MTU: 1250
11:24:27 - 	Compression framing: disabled
11:24:27 - 	Keep-alive: never
11:24:27 - 	Renegotiation: never
11:24:27 - 	TLS wrapping: disabled
11:24:27 - 	Debug: true
11:24:27 - Current SSID: none (disconnected from WiFi)
11:24:27 - Creating link session
11:24:27 - DNS resolve hostname: <hostname of router>
11:24:27 - DNS resolved addresses: ["<IP address of router>"]
11:24:27 - Will connect to <IP address of router>:443
11:24:27 - Socket type is NETCPSocket
11:24:27 - Socket state is connecting (endpoint: <IP address of router>:443 -> in progress)
11:24:27 - Socket state is connected (endpoint: <IP address of router>:443 -> <IP address of router>:443)
11:24:27 - Starting VPN session
11:24:27 - Send hard reset
11:24:27 - Negotiation key index is 0
11:24:27 - Control: Enqueued 1 packet [0]
11:24:27 - Control: Write control packet {HARD_RESET_CLIENT_V2 | 0, sid: <redacted>, pid: 0, [0 bytes]}
11:24:27 - Send control packet (14 bytes): <redacted>
11:24:27 - Control: Try read packet with code HARD_RESET_SERVER_V2 and key 0
11:24:27 - Control: Read packet {HARD_RESET_SERVER_V2 | 0, sid: <redacted>, acks: {[0], <redacted>}, pid: 0}
11:24:27 - Send ack for received packetId 0
11:24:27 - Control: Write ack packet {ACK_V1 | 0, sid: <redacted>, acks: {[0], <redacted>}}
11:24:27 - Control: Remote sessionId is <redacted>
11:24:27 - Start TLS handshake
11:24:27 - TLS.connect: Pulled ciphertext (176 bytes)
11:24:27 - Control: Enqueued 1 packet [1]
11:24:27 - Control: Write control packet {CONTROL_V1 | 0, sid: <redacted>, pid: 1, [176 bytes]}
11:24:27 - Send control packet (190 bytes): <redacted>
11:24:27 - Ack successfully written to LINK for packetId 0
11:24:27 - Control: Try read packet with code CONTROL_V1 and key 0
11:24:27 - Control: Read packet {CONTROL_V1 | 0, sid: <redacted>, acks: {[1], <redacted>}, pid: 1, [1170 bytes]}
11:24:27 - Send ack for received packetId 1
11:24:27 - Control: Write ack packet {ACK_V1 | 0, sid: <redacted>, acks: {[1], <redacted>}}
11:24:27 - TLS.connect: Put received ciphertext (1170 bytes)
11:24:27 - Control: Try read packet with code CONTROL_V1 and key 0
11:24:27 - Control: Read packet {CONTROL_V1 | 0, sid: <redacted>, pid: 2, [1170 bytes]}
11:24:27 - Send ack for received packetId 2
11:24:27 - Control: Write ack packet {ACK_V1 | 0, sid: <redacted>, acks: {[2], <redacted>}}
11:24:27 - TLS.connect: Put received ciphertext (1170 bytes)
11:24:27 - Ack successfully written to LINK for packetId 1
11:24:27 - Control: Try read packet with code CONTROL_V1 and key 0
11:24:27 - Control: Read packet {CONTROL_V1 | 0, sid: <redacted>, pid: 3, [889 bytes]}
11:24:27 - Send ack for received packetId 3
11:24:27 - Control: Write ack packet {ACK_V1 | 0, sid: <redacted>, acks: {[3], <redacted>}}
11:24:27 - TLS.connect: Put received ciphertext (889 bytes)
11:24:27 - TLS.connect: Send pulled ciphertext (2975 bytes)
11:24:27 - Control: Enqueued 1 packet [2]
11:24:27 - Control: Write control packet {CONTROL_V1 | 0, sid: <redacted>, pid: 2, [2975 bytes]}
11:24:27 - Send control packet (2989 bytes): <redacted>
11:24:27 - Ack successfully written to LINK for packetId 2
11:24:27 - Ack successfully written to LINK for packetId 3
11:24:27 - Failed LINK read: Error Domain=kNWErrorDomainPOSIX Code=54 "Connection reset by peer" UserInfo={NSDescription=Connection reset by peer}
11:24:27 - Socket state is disconnected (endpoint: <IP address of router>:443 -> <IP address of router>:443)
11:24:27 - Link failures so far: 1 (max = 3)
11:24:27 - Cleaning up...
11:24:27 - Tunnel did stop (error: linkError)
11:24:27 - Flushing log...

Config file (certificates/key not listed):

client
dev tun
proto tcp-client
remote <DNS name for my router> 443
float
ncp-ciphers AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC
cipher AES-128-CBC
keepalive 15 60
remote-cert-tls server
resolve-retry infinite
nobind

Server version (on RT-AC86U):

OpenVPN 2.4.6 arm-buildroot-linux-gnueabi [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Oct  7 2018
library versions: OpenSSL 1.0.2p  14 Aug 2018, LZO 2.08

Server version (on RT-AC68U, where the same problem occurs):

OpenVPN 2.4.6 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Oct  7 2018
library versions: OpenSSL 1.0.2p  14 Aug 2018, LZO 2.08

Possible fixes suggested remediation

?

[keeshux]

A thorough fix for MTU issues would be needed sooner or later. For now I think the reason is to be found here:

https://github.com/keeshux/tunnelkit/blob/26fc12c2ef7bd643034c3842673c9367225dc545/TunnelKit/Sources/AppExtension/Transport/NETCPInterface.swift#L186

Read: TCP is not capping packet size (.max), and your server MTU recommendation is currently ignored by the client. The result is that packets can easily get too big to handle (2989 bytes).

Would you try UDP for comparison?

[pro-sumer]

Would you try UDP for comparison?

Yes, after changing proto tcp-client into proto udp I am able to connect!

However, I would like to use TCP (and port 443), since this has a lower chance of being blocked by restrictive firewalls.

[keeshux]

Cool I think I can at least mitigate this in the next Passepartout beta.

[pro-sumer]

TCP port 443 works fine in build 1075. Thanks!