Using the same certificate and .ovpn script for iOS OpenVPN client and x64 Windows client, but getting different block size connections with same Synology VPN server. Using default server cipher BF-CBC. I want to have a minimum of 128 block and prefer 256. My questions are, why would the connections have different block sizes using same ovpn, certs, and script? How to fix? How to get to 256 bit? Thx in advance. Windows connection log shows 64 key size and I get this warning in the log: [list]"WARNING: INSECURE cipher with block size less than 128 bit (64 bit)"[/list] Yet I get this log on iOS, which seems to show connection at 128 bit: [list] 2017-01-24 10:02:54 PROTOCOL OPTIONS: cipher: BF-CBC digest: SHA1 compress: LZO peer ID: -1 2017-01-24 10:02:54 EVENT: ASSIGN_IP 2017-01-24 10:02:54 Connected via tun 2017-01-24 10:02:54 EVENT: CONNECTED admin@REDACTED.no-ip.biz:1194 (XX.170.XX.XX) via /UDPv4 on tun/10.8.0.6/ 2017-01-24 10:02:54 LZO-ASYM init swap=0 asym=0 2017-01-24 10:02:54 SetStatus Connected 2017-01-24 10:33:09 OS Event: NET AVAILABLE (RESUME): Internet:ReachableViaWiFi/-R t------ WiFi:ReachableViaWiFi/-R t-----d 2017-01-24 10:33:09 OS Event: NET AVAILABLE (RESUME): Internet:ReachableViaWiFi/-R t------ WiFi:ReachableViaWiFi/-R t-----d 2017-01-24 10:33:09 OS Event: NET AVAILABLE (RESUME): Internet:ReachableViaWiFi/-R t------ WiFi:ReachableViaWiFi/-R t-----d 2017-01-24 10:33:12 RECONNECT TEST: Internet:ReachableViaWiFi/-R t------ WiFi:ReachableViaWiFi/-R t-----d 2017-01-24 10:33:12 TUN reassert 2017-01-24 10:33:12 TUN reset routes 2017-01-24 10:33:12 EVENT: PAUSE 2017-01-24 10:33:13 RESUME TEST: Internet:ReachableViaWiFi/-R t------ WiFi:ReachableViaWiFi/-R t-----d 2017-01-24 10:33:13 EVENT: RESUME 2017-01-24 10:33:13 EVENT: RECONNECTING 2017-01-24 10:33:13 Contacting XX.170.XX.XX:1194 via UDP 2017-01-24 10:33:13 EVENT: WAIT 2017-01-24 10:33:13 SetTunnelSocket returned 1 2017-01-24 10:33:13 Connecting to [REDACTED.no-ip.biz]:1194 (XX.170.XX.XX) via UDPv4 2017-01-24 10:33:13 EVENT: CONNECTING 2017-01-24 10:33:13 Tunnel Options:V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client 2017-01-24 10:33:13 Creds: Username/Password 2017-01-24 10:33:13 Peer Info: IV_GUI_VER=net.openvpn.connect.ios 1.0.7-199 IV_VER=3.0.11 IV_PLAT=ios IV_NCP=2 IV_TCPNL=1 IV_PROTO=2 IV_LZO=1[/list] My .ovpn text: [list] comp-lzo dev tun tls-client remote REDACTED.no-ip.biz 1194 redirect-gateway dhcp-option DNS 192.168.1.1 auth-nocache ns-cert-type server pull proto udp script-security 2 ca ca.crt reneg-sec 0 auth-user-pass [/list] My connection log on Windows x64 client: [list]Tue Jan 24 11:17:26 2017 OpenVPN 2.3.14 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Dec 7 2016 Tue Jan 24 11:17:26 2017 Windows version 6.2 (Windows 8 or greater) 64bit Tue Jan 24 11:17:26 2017 library versions: OpenSSL 1.0.2i 22 Sep 2016, LZO 2.09 Enter Management Password: Tue Jan 24 11:17:32 2017 UDPv4 link local (bound): [undef] Tue Jan 24 11:17:32 2017 UDPv4 link remote: [AF_INET]XX.170.XX.XX:1194 Tue Jan 24 11:17:32 2017 TLS Error: local/remote TLS keys are out of sync: [AF_INET]XX.170.XX.XX:1194 [0] Tue Jan 24 11:17:33 2017 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Tue Jan 24 11:17:33 2017 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Tue Jan 24 11:17:33 2017 [REDACTED.com] Peer Connection Initiated with [AF_INET]XX.170.XX.XX:1194 Tue Jan 24 11:17:35 2017 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Tue Jan 24 11:17:35 2017 open_tun, tt->ipv6=0 Tue Jan 24 11:17:35 2017 TAP-WIN32 device [Ethernet 2] opened: \\.\Global\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}.tap Tue Jan 24 11:17:35 2017 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.7.1.14/255.255.255.252 on interface {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} [DHCP-serv: 10.7.1.13, lease-time: 31536000] Tue Jan 24 11:17:35 2017 Successful ARP Flush on interface [24] {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} Tue Jan 24 11:17:40 2017 Initialization Sequence Completed[/list]

Use --[b]cipher AES-256-CBC[/b] .. BlowFish only uses a 64bit blocksize and is vulnerable to SWEET [url]https://community.openvpn.net/openvpn/wiki/SWEET32[/url]

I would start with a new [url=https://community.openvpn.net/openvpn/wiki/HOWTO#SettingupyourownCertificateAuthorityCAandgeneratingcertificatesandkeysforanOpenVPNserverandmultipleclients]PKI[/url]

128 block size on iOS but only 64 on Win 10 x64 client

widmark

Using the same certificate and .ovpn script for iOS OpenVPN client and x64 Windows client, but getting different block size connections with same Synology VPN server. Using default server cipher BF-CBC. I want to have a minimum of 128 block and prefer 256.

My questions are, why would the connections have different block sizes using same ovpn, certs, and script? How to fix? How to get to 256 bit? Thx in advance.

Windows connection log shows 64 key size and I get this warning in the log:

"WARNING: INSECURE cipher with block size less than 128 bit (64 bit)"

Yet I get this log on iOS, which seems to show connection at 128 bit:

2017-01-24 10:02:54 PROTOCOL OPTIONS:
cipher: BF-CBC
digest: SHA1
compress: LZO
peer ID: -1
2017-01-24 10:02:54 EVENT: ASSIGN_IP
2017-01-24 10:02:54 Connected via tun
2017-01-24 10:02:54 EVENT: CONNECTED admin@REDACTED.no-ip.biz:1194 (XX.170.XX.XX) via /UDPv4 on tun/10.8.0.6/
2017-01-24 10:02:54 LZO-ASYM init swap=0 asym=0
2017-01-24 10:02:54 SetStatus Connected
2017-01-24 10:33:09 OS Event: NET AVAILABLE (RESUME): Internet:ReachableViaWiFi/-R t------ WiFi:ReachableViaWiFi/-R t-----d
2017-01-24 10:33:09 OS Event: NET AVAILABLE (RESUME): Internet:ReachableViaWiFi/-R t------ WiFi:ReachableViaWiFi/-R t-----d
2017-01-24 10:33:09 OS Event: NET AVAILABLE (RESUME): Internet:ReachableViaWiFi/-R t------ WiFi:ReachableViaWiFi/-R t-----d
2017-01-24 10:33:12 RECONNECT TEST: Internet:ReachableViaWiFi/-R t------ WiFi:ReachableViaWiFi/-R t-----d
2017-01-24 10:33:12 TUN reassert
2017-01-24 10:33:12 TUN reset routes
2017-01-24 10:33:12 EVENT: PAUSE
2017-01-24 10:33:13 RESUME TEST: Internet:ReachableViaWiFi/-R t------ WiFi:ReachableViaWiFi/-R t-----d
2017-01-24 10:33:13 EVENT: RESUME
2017-01-24 10:33:13 EVENT: RECONNECTING
2017-01-24 10:33:13 Contacting XX.170.XX.XX:1194 via UDP
2017-01-24 10:33:13 EVENT: WAIT
2017-01-24 10:33:13 SetTunnelSocket returned 1
2017-01-24 10:33:13 Connecting to [REDACTED.no-ip.biz]:1194 (XX.170.XX.XX) via UDPv4
2017-01-24 10:33:13 EVENT: CONNECTING
2017-01-24 10:33:13 Tunnel Options:V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client
2017-01-24 10:33:13 Creds: Username/Password
2017-01-24 10:33:13 Peer Info:
IV_GUI_VER=net.openvpn.connect.ios 1.0.7-199
IV_VER=3.0.11
IV_PLAT=ios
IV_NCP=2
IV_TCPNL=1
IV_PROTO=2
IV_LZO=1

My .ovpn text:

comp-lzo
dev tun
tls-client
remote REDACTED.no-ip.biz 1194
redirect-gateway
dhcp-option DNS 192.168.1.1
auth-nocache
ns-cert-type server
pull
proto udp
script-security 2
ca ca.crt
reneg-sec 0
auth-user-pass

My connection log on Windows x64 client:

Tue Jan 24 11:17:26 2017 OpenVPN 2.3.14 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Dec 7 2016
Tue Jan 24 11:17:26 2017 Windows version 6.2 (Windows 8 or greater) 64bit
Tue Jan 24 11:17:26 2017 library versions: OpenSSL 1.0.2i 22 Sep 2016, LZO 2.09
Enter Management Password:
Tue Jan 24 11:17:32 2017 UDPv4 link local (bound): [undef]
Tue Jan 24 11:17:32 2017 UDPv4 link remote: [AF_INET]XX.170.XX.XX:1194
Tue Jan 24 11:17:32 2017 TLS Error: local/remote TLS keys are out of sync: [AF_INET]XX.170.XX.XX:1194 [0]
Tue Jan 24 11:17:33 2017 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Tue Jan 24 11:17:33 2017 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Tue Jan 24 11:17:33 2017 [REDACTED.com] Peer Connection Initiated with [AF_INET]XX.170.XX.XX:1194
Tue Jan 24 11:17:35 2017 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Tue Jan 24 11:17:35 2017 open_tun, tt->ipv6=0
Tue Jan 24 11:17:35 2017 TAP-WIN32 device [Ethernet 2] opened: \\.\Global\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}.tap
Tue Jan 24 11:17:35 2017 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.7.1.14/255.255.255.252 on interface {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} [DHCP-serv: 10.7.1.13, lease-time: 31536000]
Tue Jan 24 11:17:35 2017 Successful ARP Flush on interface [24] {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
Tue Jan 24 11:17:40 2017 Initialization Sequence Completed

TinCanTech

Use --cipher AES-256-CBC .. BlowFish only uses a 64bit blocksize and is vulnerable to SWEET

https://community.openvpn.net/openvpn/wiki/SWEET32

widmark

Thanks I didn't know about the 64 bit max on blowfish. I'm not exactly sure how to do this... looks like it will require getting into SSH on the Synology VPN server... not something I have played with much. Any hints?

TinCanTech

You should be able to add --cipher AES-256-CBC to your server and client (restart and try)

https://openvpn.net/index.php/open-source/documentation/howto.html

https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage

widmark

I was able to figure out SSH and change the server profile to use AES-256-CBC (client side is easy peasy). It was necessary also to use the command auth SHA256 on client and server in addition to the cipher AES-256-CBC. Thank you much for this help!

How can I verify the key size? I believe my certificate allows up to 4096 key length but I have no commands in my profile specifying anything.

I also have a server certificate that was installed a few years ago. How can I confirm that is being verified on each VPN session? I do have this command in the profile: ns-cert-type server. Maybe it already is doing this and would return an error if it wasn't working?

Thx

TinCanTech

I would start with a new PKI