Unable to connect over BT Wifi / Openzone

j.a.mcguire

Hi there, I have a OpenVPN server which otherwise works fine however when I attempt to connect via BT Wifi I receive the following erorr on the server log:

Wed Oct 22 22:36:34 2014 109.144.191.3:53330 WARNING: Bad encapsulated packet length from peer (22616), which must be > 0 and <= 1560 -- 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...]

I attempted setting the link-mtu in the configuration on the client to 1472 after testing using 'ping 8.8.8.8 -l 1472' and successfully receiving responses, however the packet length from peer message remains the same (Bad encapsulated packet length from peer (22616)).

I am using crypto AES-128-CBC and compression.

client version:
Thu Oct 23 09:23:01 2014 OpenVPN 2.3.4 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Aug 7 2014

server version:
Thu Oct 23 07:17:56 2014 OpenVPN 2.3.4 i386-portbld-freebsd10.0 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Jun 8 2014

The link is configured for TCP although I have tried UDP. I have attempted to tunnel the connection via SSH and receive the same error, so I think it's something specific to the OpenVPN configuration rather than any transparent proxy/firewall BT are using.

Any advice appreciated.

Traffic

j.a.mcguire wrote I have attempted to tunnel the connection via SSH and receive the same error, so I think it's something specific to the OpenVPN configuration

and yet ..

j.a.mcguire wroteI have a OpenVPN server which otherwise works fine however when I attempt to connect via BT Wifi I receive the following erorr

Sounds like BT WiFi problem ...

Also:

j.a.mcguire wroteI attempted setting the link-mtu in the configuration on the client to 1472

Note:

j.a.mcguire wroteplease ensure that --tun-mtu or --link-mtu is equal on both peers

See --link-mtu, --tun-mtu, mssfix and fragment in The Manual v23x

As you have Freebsd available you may also be able to use --mtu-disc and --mtu-test, see the manual for details.

j.a.mcguire

I'll try to do some further testing with the 'mssfix' and 'fragment' options and update, although I have configured the mtu options on the client and server to various matching values.

On my working link if I attempt to implement mssfix and fragment per the examples in the man page I am unable to establish a connection. My working link is also able to transmit at 1472 MTU. I note that if I switch my working link to UDP from TCP my connection fails to negotiate TLS although it does appear to establish an initial connection as I am prompted for the SSL password. But this is really an aside from the main issue and I can fall-back to TCP which works fine.

It can't be specific to BT Wifi other than some limitation on the network configuration. It's not like they can do deep packet inspection on an encrypted SSH tunnel to discern it's VPN traffic and block it, so there's no reason it shouldn't work once configured correctly.

j.a.mcguire

Mtu-test works well!

Server:
[root@diesel /home/diesel/jim]# openvpn --mtu-test --dev tun0 --port 30443
Fri Oct 24 16:14:37 2014 OpenVPN 2.3.4 i386-portbld-freebsd10.0 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Jun 8 2014
Fri Oct 24 16:14:37 2014 library versions: OpenSSL 1.0.1j 15 Oct 2014, LZO 2.08
Fri Oct 24 16:14:37 2014 ******* WARNING *******: all encryption and authentication features disabled -- all data will be tunnelled as cleartext
Fri Oct 24 16:14:37 2014 TUN/TAP device tun0 exists previously, keep at program end
Fri Oct 24 16:14:37 2014 TUN/TAP device /dev/tun0 opened
Fri Oct 24 16:14:37 2014 UDPv4 link local (bound): [undef]
Fri Oct 24 16:14:37 2014 UDPv4 link remote: [undef]
Fri Oct 24 16:14:52 2014 Peer Connection Initiated with [AF_INET]188.95.132.8:17926
Fri Oct 24 16:14:53 2014 Initialization Sequence Completed
Fri Oct 24 16:14:53 2014 NOTE: Beginning empirical MTU test -- results should be available in 3 to 4 minutes.
Fri Oct 24 16:18:34 2014 NOTE: failed to empirically measure MTU (requires OpenVPN 1.5 or higher at other end of connection).

Fri Oct 24 16:14:53 2014 NOTE: Beginning empirical MTU test -- results should be available in 3 to 4 minutes.
Fri Oct 24 16:18:34 2014 NOTE: failed to empirically measure MTU (requires OpenVPN 1.5 or higher at other end of connection).

Client:

C:\Program Files\OpenVPN\bin>.\openvpn --remote server.ip 30443 --proto u
dp --dev tun --mtu-test --ifconfig 192.168.50.2 192.168.50.1
Fri Oct 24 16:14:42 2014 OpenVPN 2.3.4 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO]
[PKCS11] [IPv6] built on Aug 7 2014
Fri Oct 24 16:14:42 2014 library versions: OpenSSL 1.0.1i 6 Aug 2014, LZO 2.05
Fri Oct 24 16:14:42 2014 ******* WARNING *******: all encryption and authenticat
ion features disabled -- all data will be tunnelled as cleartext
Fri Oct 24 16:14:42 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Fri Oct 24 16:14:42 2014 open_tun, tt->ipv6=0
Fri Oct 24 16:14:42 2014 TAP-WIN32 device [Local Area Connection 3] opened: \\.\
Global\{35F3F14B-8329-4E57-994A-ED91032D0E44}.tap
Fri Oct 24 16:14:42 2014 Notified TAP-Windows driver to set a DHCP IP/netmask of
192.168.50.2/255.255.255.252 on interface {35F3F14B-8329-4E57-994A-ED91032D0E44
} [DHCP-serv: 192.168.50.1, lease-time: 31536000]
Fri Oct 24 16:14:42 2014 Successful ARP Flush on interface [30] {35F3F14B-8329-4
E57-994A-ED91032D0E44}
Fri Oct 24 16:14:42 2014 UDPv4 link local (bound): [undef]
Fri Oct 24 16:14:42 2014 UDPv4 link remote: [AF_INET]86.132.135.53:30443

Testing fails:

Fri Oct 24 16:14:53 2014 NOTE: Beginning empirical MTU test -- results should be available in 3 to 4 minutes.
Fri Oct 24 16:18:34 2014 NOTE: failed to empirically measure MTU (requires OpenVPN 1.5 or higher at other end of connection).

Traffic

j.a.mcguire wroteServer:
[root@diesel /home/diesel/jim]# openvpn --mtu-test --dev tun0 --port 30443
Fri Oct 24 16:14:37 2014 OpenVPN 2.3.4 i386-portbld-freebsd10.0 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Jun 8 2014
Fri Oct 24 16:14:37 2014 library versions: OpenSSL 1.0.1j 15 Oct 2014, LZO 2.08
..
Fri Oct 24 16:14:53 2014 NOTE: Beginning empirical MTU test -- results should be available in 3 to 4 minutes.
Fri Oct 24 16:18:34 2014 NOTE: failed to empirically measure MTU (requires OpenVPN 1.5 or higher at other end of connection).

j.a.mcguire wroteClient:

C:\Program Files\OpenVPN\bin>.\openvpn --remote server.ip 30443 --proto u
dp --dev tun --mtu-test --ifconfig 192.168.50.2 192.168.50.1
Fri Oct 24 16:14:42 2014 OpenVPN 2.3.4 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO]
[PKCS11] [IPv6] built on Aug 7 2014
Fri Oct 24 16:14:42 2014 library versions: OpenSSL 1.0.1i 6 Aug 2014, LZO 2.05
...
Fri Oct 24 16:14:53 2014 NOTE: Beginning empirical MTU test -- results should be available in 3 to 4 minutes.
Fri Oct 24 16:18:34 2014 NOTE: failed to empirically measure MTU (requires OpenVPN 1.5 or higher at other end of connection).

Well .. that is strange.

My result:

Server:

Sat Oct 25 14:43:05 2014 us=25880 [b]OpenVPN 2.3.4 i686-pc-linux-gnu[/b] [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on May  3 2014
Sat Oct 25 14:43:05 2014 us=25880 library versions: OpenSSL 1.0.1j 15 Oct 2014, LZO 2.08

Client:

Sat Oct 25 14:43:16 2014 us=203125 [b]OpenVPN 2.3.4 i686-w64-mingw32[/b] [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Aug  7 2014
Sat Oct 25 14:43:16 2014 us=203125 library versions: OpenSSL 1.0.1i 6 Aug 2014, LZO 2.05
...
Sat Oct 25 14:46:33 2014 us=125000 NOTE: Empirical MTU test completed [Tried,Actual] local->remote=[1557,1557] remote->local=[1557,1557]

I have never really had to use this function but it does work for me, perhaps you must only set --mtu-test from one side, I only set it on the client.

Traffic

Instead of using the command line use config files and post the configs you use please.

j.a.mcguire

I've looked into this a little further. tcpdump shows the server receiving and responding to the UDP datagrams, but wireshark shows the client never receives any response.

Why that might be I'm not sure, I suspect a firewall however if the client has initiated the connection and the server receives data, I cannot see why the response might be blocked by a firewall?

Furthermore, after a little more research it has become apparent that you cannot natively tunnel UDP through SSH. In the examples I have seen UDP is converted to TCP before transmission via the tunnel which explains why that does not work.

If I can fall back to using TCP VPN over an SSH tunnel that will suffice.

Traffic

j.a.mcguire wroteit has become apparent that you cannot natively tunnel UDP through SSH. In the examples I have seen UDP is converted to TCP before transmission via the tunnel

I just transferred a 10mb file over my OpenVPN using TFTP in 2 and 1/2 minutes ..