#1056 closed Bug / Defect (fixed-external)
Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:1: route (2.4.5)
Reported by: | alllexx88 | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | Generic / unclassified | Version: | OpenVPN 2.4.5 (Community Ed) |
Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | |
Cc: |
Description
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.
Attachments (1)
Change History (7)
comment:1 Changed 4 years ago by
comment:2 Changed 4 years ago by
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
Changed 4 years ago by
comment:3 Changed 4 years ago by
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.
comment:4 Changed 4 years ago by
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.
comment:5 Changed 4 years ago by
Resolution: | → fixed-external |
---|---|
Status: | new → closed |
I was about to write something about "the route statement in the PUSH_REPLY is broken", but you already found it :-) - cool.
Client log file, please, or it did not happen. We need to see the line with PUSH_REPLY.