Page 1 of 1

Problem with obfs2/obfs3 (Bad encapsulated packet length?)

Posted: Tue Jan 16, 2018 11:20 am
by LessHairyApe
Followed the instructions here:
https://www.sparklabs.com/support/kb/ar ... viscosity/

(1) OpenVPN, TCP, port 443
(2) Verified working in a 'vanilla' connection in Viscosity (yay)
(3) Run the following on the server, also created firewall rule
obfsproxy --log-min-severity=debug --no-safe-logging obfs2 --dest=127.0.0.1:443 server 0.0.0.0:993
(4) Duplicated the working vanilla connection in Viscosity, changed only the port to 993 and the obfuscation method to obfs2 in the UI
(5) Connect

Client Log:
2018-01-15 19:17:25: Attempting to establish TCP connection with [AF_INET]127.0.0.1:54844 [nonblock]
2018-01-15 19:17:26: TCP connection established with [AF_INET]127.0.0.1:54844
2018-01-15 19:17:26: TCPv4_CLIENT link local: (not bound)
2018-01-15 19:17:26: TCPv4_CLIENT link remote: [AF_INET]127.0.0.1:54844
2018-01-15 19:17:26: WARNING: Bad encapsulated packet length from peer (18516), which must be > 0 and <= 1627 -- 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...]
2018-01-15 19:17:26: Connection reset, restarting [0]
2018-01-15 19:17:26: SIGUSR1[soft,connection-reset] received, process restarting
obfs2proxy output:
2018-01-15 19:17:29,139 [DEBUG] fact_s_0x806f4f518: New connection from [REDACTED]:54959.
2018-01-15 19:17:29,139 [INFO] Starting factory <obfsproxy.network.network.StaticDestinationClientFactory instance at 0x806f82ef0>
2018-01-15 19:17:29,139 [DEBUG] fact_c_0x806f82ef0: Client factory started connecting.
2018-01-15 19:17:29,139 [DEBUG] conn_0x806f87d90: connectionMade (server): Setting it as downstream on our circuit.
2018-01-15 19:17:29,139 [DEBUG] circ_0x806f82cf8: Setting downstream connection (conn_0x806f87d90).
2018-01-15 19:17:29,140 [DEBUG] conn_0x806f87d90: Incomplete circuit; cached 1448 bytes.
2018-01-15 19:17:29,140 [DEBUG] conn_0x806f87e90: connectionMade (server): Setting it as upstream on our circuit.
2018-01-15 19:17:29,140 [DEBUG] circ_0x806f82cf8: Setting upstream connection (conn_0x806f87e90).
2018-01-15 19:17:29,140 [DEBUG] circ_0x806f82cf8: Circuit completed.
2018-01-15 19:17:29,140 [DEBUG] obfs2 handshake: responder queued 7959 bytes (padding_length: 7935).
2018-01-15 19:17:29,141 [DEBUG] conn_0x806f87d90: Writing 7959 bytes.
2018-01-15 19:17:29,141 [DEBUG] circ_0x806f82cf8: downstream: Received 4344 bytes.
2018-01-15 19:17:29,141 [DEBUG] obfs2 receivedDownstream: Waiting for key.
2018-01-15 19:17:29,141 [DEBUG] obfs2 receivedDownstream: Got 4320 bytes of handshake data (padding_length: 4469, magic: 0x2bf5ca7e)
2018-01-15 19:17:29,141 [DEBUG] obfs2 receivedDownstream: Consumed 4320 bytes of padding, 149 still to come (0).
2018-01-15 19:17:29,141 [DEBUG] circ_0x806f82cf8: downstream: Received 149 bytes.
2018-01-15 19:17:29,142 [DEBUG] obfs2 receivedDownstream: Consumed 149 bytes of padding, 0 still to come (0).
2018-01-15 19:17:29,142 [DEBUG] obfs2 receivedDownstream: Processing 0 bytes of application data.
2018-01-15 19:17:29,142 [DEBUG] conn_0x806f87e90: Writing 0 bytes.
2018-01-15 19:17:29,146 [DEBUG] circ_0x806f82cf8: downstream: Received 56 bytes.
2018-01-15 19:17:29,146 [DEBUG] obfs2 receivedDownstream: Processing 56 bytes of application data.
2018-01-15 19:17:29,146 [DEBUG] conn_0x806f87e90: Writing 56 bytes.
2018-01-15 19:17:29,147 [DEBUG] circ_0x806f82cf8: upstream: Received 311 bytes.
2018-01-15 19:17:29,147 [DEBUG] obfs2 receivedUpstream: Transmitting 311 bytes.
2018-01-15 19:17:29,147 [DEBUG] conn_0x806f87d90: Writing 311 bytes.
2018-01-15 19:17:29,147 [DEBUG] conn_0x806f87e90: Connection was lost (Connection was closed cleanly.).
2018-01-15 19:17:29,147 [DEBUG] conn_0x806f87e90: Closing connection.
2018-01-15 19:17:29,147 [DEBUG] circ_0x806f82cf8: Tearing down circuit.
2018-01-15 19:17:29,147 [DEBUG] conn_0x806f87d90: Closing connection.
2018-01-15 19:17:29,148 [INFO] Stopping factory <obfsproxy.network.network.StaticDestinationClientFactory instance at 0x806f82ef0>
2018-01-15 19:17:29,148 [DEBUG] conn_0x806f87d90: Connection was lost (Connection was closed cleanly.).

Re: Problem with obfs2/obfs3 (Bad encapsulated packet length?)

Posted: Mon Jan 22, 2018 12:42 pm
by James
Hi LessHairyApe,

What version of Viscosity are you using? I'd recommend giving the latest beta try and see if that makes any difference, as we did overhaul the obfuscation engine as part of adding obfs4 support:
https://www.sparklabs.com/support/kb/ar ... -versions/

Otherwise I'd hazard a guess that the obfsproxy instance on the server may not be correctly connecting to the OpenVPN instance. I'd recommend making sure that the OpenVPN server is listening on localhost (if it's configured to listen on the external IP address it may not be), that it isn't configured to port-share 443, that there are no firewall or NAT rules that could be interfering, and try temporarily disabling any tls-auth/tls-crypt settings just to see whether that could be an issue.

Cheers,
James

Re: Problem with obfs2/obfs3 (Bad encapsulated packet length?)

Posted: Mon Jan 22, 2018 2:07 pm
by LessHairyApe
Thanks James. I did try moving OpenVPN from 443 to 1194, no difference. Tried with Viscosity 1.7.6 (1425).

Stay tuned for updates from Beta.