This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Can't connect to SSL VPN on Linux

I am in the final stages of setting up our new XG 135 and I've hit a problem when testing the SSL VPN on Linux. I have tried several distributions but currently I'm using the following:

Linux Ubuntu1604vm 4.4.0-31-generic #50-Ubuntu SMP Wed Jul 13 00:07:12 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

This is the OpenVPN version information:

OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jan 9 2019
library versions: OpenSSL 1.0.2g-fips 1 Mar 2016, LZO 2.08
Originally developed by James Yonan
Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@openvpn.net>
Compile time defines: enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dependency_tracking=no enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=yes enable_fragment=yes enable_http_proxy=yes enable_iproute2=yes enable_libtool_lock=yes enable_lzo=yes enable_lzo_stub=no enable_maintainer_mode=no enable_management=yes enable_multi=yes enable_multihome=yes enable_pam_dlopen=no enable_password_save=yes enable_pedantic=no enable_pf=yes enable_pkcs11=yes enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_silent_rules=no enable_small=no enable_socks=yes enable_ssl=yes enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=yes enable_win32_dll=yes enable_x509_alt_username=yes with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_plugindir='${prefix}/lib/openvpn' with_sysroot=no

The error that I get is the following (after running the command openvpn --config <auto_generated_ovpn_file>):

Tue Mar 2 14:15:16 2021 us=684560 ROUTE_GATEWAY 192.168.1.254/255.255.255.0 IFACE=enp0s3 HWADDR=08:00:27:f2:56:59
Tue Mar 2 14:15:16 2021 us=684777 TUN/TAP device tun0 opened
Tue Mar 2 14:15:16 2021 us=684788 TUN/TAP TX queue length set to 100
Tue Mar 2 14:15:16 2021 us=684797 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Tue Mar 2 14:15:16 2021 us=684811 /sbin/ip link set dev tun0 up mtu 1500
Tue Mar 2 14:15:16 2021 us=694792 /sbin/ip addr add dev tun0 10.1.0.1/24 broadcast 10.1.0.255
Tue Mar 2 14:15:16 2021 us=699204 UDPv4 WRITE [22] to [AF_INET]86.157.139.153:8443: P_ACK_V1 kid=0 [ 42 ]
Tue Mar 2 14:15:20 2021 us=966074 /sbin/ip route add 86.157.139.153/32 via 192.168.1.254
Tue Mar 2 14:15:20 2021 us=966788 /sbin/ip route add 10.0.1.0/24 via 10.1.0.0
RTNETLINK answers: Invalid argument
Tue Mar 2 14:15:20 2021 us=969677 ERROR: Linux route add command failed: external program exited with error status: 2
Tue Mar 2 14:15:20 2021 us=969738 /sbin/ip route add 10.0.0.0/18 via 10.1.0.0
RTNETLINK answers: Invalid argument
Tue Mar 2 14:15:20 2021 us=970372 ERROR: Linux route add command failed: external program exited with error status: 2
Tue Mar 2 14:15:20 2021 us=970424 /sbin/ip route add 86.157.139.153/32 via 192.168.1.254
RTNETLINK answers: File exists
Tue Mar 2 14:15:20 2021 us=970970 ERROR: Linux route add command failed: external program exited with error status: 2
Tue Mar 2 14:15:20 2021 us=971039 Initialization Sequence Completed

The SSL VPN IP address settings in the XG are the following:

Subnet: /24 (255.255.255.0)

IPv4 lease range: 10.1.0.0-10.1.0.254

The SSL VPN policy is currently setup with "Use as default gateway" disabled as a matter of preference. However, I have tried with it enabled (as described here: https://support.sophos.com/support/s/article/KB-000039342?language=en_US) also and it makes no difference.

The IP address appears to be getting assigned in Linux and I can see it as a live connection in the XG dashboard when connected.

Note that the current configuration works for Windows, so I was surprised to see it failing on Linux.

I would appreciate any suggestions as we were just about to proceed with deployment until we discovered this problem.



This thread was automatically locked due to age.