Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:1: route (2.4.5)

[alllexx88]

I have a Linux x86_64 OpenVPN 2.3.11 on a server side (a Synology NAS) and an x86_64 Windows OpenVPN 2.4.5 on a client side. All push "route <subnet> <mask>" options in server-side config file cause an options error on the client like this one:

Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:1: route (2.4.5)

If I add option route <subnet> <mask> to the client config, it works as expected. I experienced the same issue with 2.4.2 client, so I assume this may hold for all 2.4.x versions.

[Gert Döring]

Client log file, please, or it did not happen. We need to see the line with PUSH_REPLY.

[alllexx88]

Sorry, I don't see any PUSH_REPLY lines. Here's the log (server IP shadowed):

Sat Apr 14 21:14:02 2018 OpenVPN 2.4.5 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Mar  1 2018
Sat Apr 14 21:14:02 2018 Windows version 6.2 (Windows 8 or greater) 64bit
Sat Apr 14 21:14:02 2018 library versions: OpenSSL 1.1.0f  25 May 2017, LZO 2.10
Sat Apr 14 21:14:07 2018 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Sat Apr 14 21:14:07 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]*.*.*.*:1194
Sat Apr 14 21:14:07 2018 UDP link local (bound): [AF_INET][undef]:1194
Sat Apr 14 21:14:07 2018 UDP link remote: [AF_INET]*.*.*.*:1194
Sat Apr 14 21:14:09 2018 [*.*.*.*] Peer Connection Initiated with [AF_INET]*.*.*.*:1194
Sat Apr 14 21:14:10 2018 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:1: route (2.4.5)
Sat Apr 14 21:14:10 2018 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).
Sat Apr 14 21:14:10 2018 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).
Sat Apr 14 21:14:10 2018 WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.
Sat Apr 14 21:14:10 2018 open_tun
Sat Apr 14 21:14:10 2018 TAP-WIN32 device [Ethernet 2] opened: \\.\Global\{694EA0E3-F8F8-456D-AB4C-C058C7FB6CC9}.tap
Sat Apr 14 21:14:10 2018 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.6/255.255.255.252 on interface {694EA0E3-F8F8-456D-AB4C-C058C7FB6CC9} [DHCP-serv: 10.8.0.5, lease-time: 31536000]
Sat Apr 14 21:14:10 2018 Successful ARP Flush on interface [10] {694EA0E3-F8F8-456D-AB4C-C058C7FB6CC9}
Sat Apr 14 21:14:10 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sat Apr 14 21:14:15 2018 Initialization Sequence Completed

[alllexx88]

I've increased verbosity. Here's the PUSH_REPLY line:

Tue Apr 17 23:00:30 2018 us=445220 PUSH: Received control message: 'PUSH_REPLY,route  ,route 10.8.0.1,topology net30,ping 10,ping-restart 60,ifconfig 10.8.0.6 10.8.0.5'

Full log file attached above.

[alllexx88]

Sorry, I figured it out. Synology runs a sed expression on the server config file, which in my case turned a valid push "route <subnet> <netmask>" line into push "route ". Thanks for the PUSH_REPLY tip, now I got it figured out.

[Gert Döring]

I was about to write something about "the route statement in the PUSH_REPLY is broken", but you already found it :-) - cool.

[tct]

CC