Guest User!

You are not Sophos Staff.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 26 subscribers
  • Views 12647 views
  • Users 0 members are here
Options
Suggested
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

Windows SSL VPN client insists to connect to original 3 x IP addresses in xxxx_ssl_vpn_config.ovpn, how can change it?

Atsushi Shogo

Windows SSL VPN client remembers and tries to connect to the original 3 x IP addresses written in C:\Program Files\Sophos\Sophos SSL VPN Client\config\xxxx_ssl_vpn_config.ovpn, although I have already changed it to a global IP address of the router to connect to Internet.

How can I forget the Windows the old 3 x IP addresses to use the new IP address in xxxx_ssl_vpn_config.ovpn?

Or editing the file is incorrect in case of Windows? Anywhere else Windows VPN client refer?

 

My Android can access the devices in my LAN through SSL VPN by editing xxxx_ssl_vpn_config.ovpn, so I'm sure VPN configuration is fine.

 

<Original last 3 lines of xxxx_ssl_vpn_config.ovpn>

remote 192.168.0.7 8443
remote 192.168.1.1 8443
remote 10.255.0.1 8443

<I have edited as below>

remote xxx.xxx.xxx.xxx 8443 *(xxx.xxx.xxx.xxx is the global IP address of the router)

Of course, 8443 port forward to 192.168.0.7 is set on the router.

 

<Windows VPN client log>

Sun Feb 05 12:57:44 2017 OpenVPN 2.3.8 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [IPv6] built on Dec 9 2016
Sun Feb 05 12:57:44 2017 library versions: OpenSSL 1.0.1u 22 Sep 2016, LZO 2.09
Enter Management Password:
Sun Feb 05 12:57:44 2017 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Sun Feb 05 12:57:44 2017 Need hold release from management interface, waiting...
Sun Feb 05 12:57:44 2017 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Sun Feb 05 12:57:44 2017 MANAGEMENT: CMD 'state on'
Sun Feb 05 12:57:44 2017 MANAGEMENT: CMD 'log all on'
Sun Feb 05 12:57:44 2017 MANAGEMENT: CMD 'hold off'
Sun Feb 05 12:57:44 2017 MANAGEMENT: CMD 'hold release'
Sun Feb 05 12:57:52 2017 MANAGEMENT: CMD 'username "Auth" "testssluser"'
Sun Feb 05 12:57:52 2017 MANAGEMENT: CMD 'password [...]'
Sun Feb 05 12:57:53 2017 Socket Buffers: R=[8192->8192] S=[8192->8192]
Sun Feb 05 12:57:53 2017 Attempting to establish TCP connection with [AF_INET]192.168.0.7:8443 [nonblock]
Sun Feb 05 12:57:53 2017 MANAGEMENT: >STATE:1486267073,TCP_CONNECT,,,,,,
Sun Feb 05 12:58:03 2017 TCP: connect to [AF_INET]192.168.0.7:8443 failed, will try again in 5 seconds: The system tried to join a drive to a directory on a joined drive.
Sun Feb 05 12:58:03 2017 SIGUSR1[soft,init_instance] received, process restarting
Sun Feb 05 12:58:03 2017 MANAGEMENT: >STATE:1486267083,RECONNECTING,init_instance,,,,,
Sun Feb 05 12:58:03 2017 Restart pause, 5 second(s)
Sun Feb 05 12:58:08 2017 Socket Buffers: R=[8192->8192] S=[8192->8192]
Sun Feb 05 12:58:08 2017 Attempting to establish TCP connection with [AF_INET]192.168.1.1:8443 [nonblock]
Sun Feb 05 12:58:08 2017 MANAGEMENT: >STATE:1486267088,TCP_CONNECT,,,,,,
Sun Feb 05 12:58:18 2017 TCP: connect to [AF_INET]192.168.1.1:8443 failed, will try again in 5 seconds: The system tried to join a drive to a directory on a joined drive.
Sun Feb 05 12:58:18 2017 SIGUSR1[soft,init_instance] received, process restarting
Sun Feb 05 12:58:18 2017 MANAGEMENT: >STATE:1486267098,RECONNECTING,init_instance,,,,,
Sun Feb 05 12:58:18 2017 Restart pause, 5 second(s)
Sun Feb 05 12:58:23 2017 Socket Buffers: R=[8192->8192] S=[8192->8192]
Sun Feb 05 12:58:23 2017 Attempting to establish TCP connection with [AF_INET]10.255.0.1:8443 [nonblock]
Sun Feb 05 12:58:23 2017 MANAGEMENT: >STATE:1486267103,TCP_CONNECT,,,,,,
Sun Feb 05 12:58:33 2017 TCP: connect to [AF_INET]10.255.0.1:8443 failed, will try again in 5 seconds: The system tried to join a drive to a directory on a joined drive.
Sun Feb 05 12:58:33 2017 SIGUSR1[soft,init_instance] received, process restarting
Sun Feb 05 12:58:33 2017 MANAGEMENT: >STATE:1486267113,RECONNECTING,init_instance,,,,,
Sun Feb 05 12:58:33 2017 Restart pause, 5 second(s)
Sun Feb 05 12:58:39 2017 Socket Buffers: R=[8192->8192] S=[8192->8192]
Sun Feb 05 12:58:39 2017 Attempting to establish TCP connection with [AF_INET]192.168.0.7:8443 [nonblock]
Sun Feb 05 12:58:39 2017 MANAGEMENT: >STATE:1486267119,TCP_CONNECT,,,,,,
Sun Feb 05 12:58:49 2017 TCP: connect to [AF_INET]192.168.0.7:8443 failed, will try again in 5 seconds: The system tried to join a drive to a directory on a joined drive.
Sun Feb 05 12:58:49 2017 SIGUSR1[soft,init_instance] received, process restarting
Sun Feb 05 12:58:49 2017 MANAGEMENT: >STATE:1486267129,RECONNECTING,init_instance,,,,,
Sun Feb 05 12:58:49 2017 Restart pause, 5 second(s)

It continues and never connect.

-------------------

 

My Android VPN client log shows contacted and connected to xxx.xxx.xxx.xxx:8443 without any issue.

Reboot Windows, uninstall & re-install VPN client didn't help to fix it.

I appreciate your experience!

Tks & Rgds,



This thread was automatically locked due to age.
  • 0

    Atsushi,

    Every time you change the ssl vpn configuration on your XG, users have to download the new configuration from user portal.

    Download and install the new configuration from user portal and it will work.

    Regards

  • 0 in reply to lferrara

    XG, when properly configured, will put a domain name in the "remote" line of ovpn file.
    That way it points at xg.yourdomain.com,  and you will be able to use it without editing.
    Note, TS is behind NAT,  and XG only has private IPs, so using IP addresses in remote line will always require manual editing of files.

  • 0 in reply to sixteen again

    Sixteeen,

    Some settings are automatically updated by the SSL Client but not all of them:

    For example, if you change the Certificate been used by the SSL VPN Server, clients will not connect, unless users update their configuration; changing the SSL Port (when the feature will be available), will not allow the users to connect; changing the public IP where SSL VPN server listen too, users will not be able to connect anymore.

    So my advice is that users must have proper permissions in case a massive changing is performed on XG. Of course this should be shared by XG Admins and who manage the Users to update the possibile opvn file.

    Of coure every environment is different so sharing is the key.

    Regards

  • 0

    Dear, lferrara & sixteen again

    Yes, my XG firewall has only private IP address under a router, and I don't use dynamic DNS as of now.
    Probably I will use dynamic DNS in near future, but yet yet as of now.
    Hence, I had to edit the "xxxx_ssl_vpn_config.ovpn".

    Today I tested on another PC, the modification of "xxxx_ssl_vpn_config.ovpn" reflected exactly without any issue.
    So, the problem seemed to be only on the 1st PC.
    Really not sure why the 1st PC insisted to remember and use the original 3 x IP addresses although "xxxx_ssl_vpn_config.ovpn" had been modified.
    It's weird.
    If the issue continues to happen on the 1st PC, I will do the OS recovery.

    Thank both of you so much!

  • 0 in reply to lferrara

    lferrara,

    Ofcourse changes to port or ovpn certificates affect current VPN users.    But why should the public IP?  From a productive site, I just downloaded a user.ovpn file, and it contains the line:

    remote   <fqdn>

    And that's what TS needs, since his 3 IP addresses are private, so ovpn will never work without manual editing