Bad encapsulated packet length - socks proxy problem?

rhk

Getting the following message when inserting a socks proxy in the connection (without the proxy, it connects fine):

WARNING: Bad encapsulated packet length from peer (43520), which must be > 0 and <= 1544 -- please ensure that --tun-mtu or --link-mtu is equal on both peer

Client.conf is:

client
dev tun
proto tcp
remote ec2-xxx-xxx-xxx-xxx.compute-1.amazonaws.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client1.crt
key client1.key
ns-cert-type server
comp-lzo
verb 4
socks-proxy 192.168.147.82 110  #disable this line and it works fine

The problem is that for production use, I'll need to use a proxy - so need to figure out a way round this issue. The proxy is running under Windows, if that makes any difference. Does anyone know what the issue is, and whats causing it? If not, does anyone have a working proxy on Windows to recommend?

thanks
/steve

rhk

Hi Debbie

Thanks for the reply. Client config is above. Server is running on EC2. Config is:

local 10.236.174.164
port 1194
proto tcp
dev tun
ca ca.crt
cert ip-10-236-174-164.crt
key ip-10-236-174-164.key  # This file should be kept secret
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 4

The proxy in question is an in-house one that runs on Windows and uses .Net TcpClient to echo the TCP stream. It has been thoroughly tested and works fine with other apps.

thanks
/steve

rhk

I turned up the logging and pasted here:

client log = http://pastebin.com/s0Fn1Vb3
server log = http://pastebin.com/vnLwrLbc

latest client config:

client
dev tun
proto tcp
remote ec2-54-211-75-146.compute-1.amazonaws.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client1.crt
key client1.key
ns-cert-type server
comp-lzo
verb 10
socks-proxy 192.168.147.82 1194
connect-retry 10000
log openvpn-client.log

latest server config:

local 10.236.174.164
port 1194
proto tcp
dev tun
ca ca.crt
cert ip-10-236-174-164.crt
key ip-10-236-174-164.key  # This file should be kept secret
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 5
log openvpn-server.log

Network trace from proxy:


(SOCKS5 authentication request)

===: Incoming from 192.168.147.101:57385 = 4 bytes
5 2 0 2 
===: Writing to 192.168.147.101:57385 = 2 bytes
5 0 

(SOCKS5 connect request)

===: Incoming from 192.168.147.101:57385 = 48 bytes
5 1 0 3 41 101 99 50 45 53 52 45 50 49 49 45 55 53 45 49 52 54 46 99 111 109 112 117 116 101 45 49 46 97 109 97 122 111 110 97 119 115 46 99 111 109 4 170 
DNS proxy lookup:ec2-54-211-75-146.compute-1.amazonaws.com = 54.211.75.146
Proxy connected to:54.211.75.146:1194
===: Writing to 192.168.147.101:57385 = 48 bytes
5 0 0 3 41 101 99 50 45 53 52 45 50 49 49 45 55 53 45 49 52 54 46 99 111 109 112 117 116 101 45 49 46 97 109 97 122 111 110 97 119 115 46 99 111 109 4 170 

(SOCKS5 authentication request)

===: Incoming from 192.168.147.101:57385 = 16 bytes
0 14 56 4 80 144 121 81 67 84 27 0 0 0 0 0 
===: Writing to 54.211.75.146:1194 = 16 bytes
0 14 56 4 80 144 121 81 67 84 27 0 0 0 0 0 
===: Incoming from 54.211.75.146:1194 = 28 bytes
0 26 64 8 40 162 177 41 151 107 26 1 0 0 0 0 4 80 144 121 81 67 84 27 0 0 0 0 
===: Writing to 192.168.147.101:57385 = 28 bytes
0 26 64 8 40 162 177 41 151 107 26 1 0 0 0 0 4 80 144 121 81 67 84 27 0 0 0 0 

(disconnection from client)
===: Incoming from 192.168.147.101:57385 = 0 bytes

Really appreciate any help that you can give!

thanks
Steve

rhk

It could well be an issue with the proxy (though it works fine for other applications).

Can you recommend an alternative windows proxy server that would work with OpenVPN?

thanks
Steve

rhk

Hmm.. the manual says the following are only valid if using with protocol=udp (i'm using tcp)

--mssfix
--fragment
--mtu-test

I tried setting --tun-mtu 1400 on both sides, but that still gave me the error.

I then tried setting --tun-mtu 43250 on both sides (to match the strange MTU value that was reported), and it connects now - but fails shortly afterwards "TLS key negotiation failed". I suspect that something in the protocol is being mangled somewhere, and I still cant figure out where that high MTU value is coming from.

However, I've found a temporary workaround, which is to run a SSH tunnel instead of a proxy. This works fine on the same machines (and is OK for what I need right now), but if I have some free time I'll try to dig into this proxy issue in more detail.

thanks
Steve