Thread Info
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

Can't connect externally using .PRO file connection

Jeff Vandervoort

XGS135 wearing SFOS 19.5.1 MR-1-Build278.

Trying to create a (mostly) automated Sophos Connect installation for an SSL VPN, and am pretty close. I thought.

I am using the following .PRO file--

[
  {
    "gateway": "vpn.externaldomain.com",
    "user_portal_port": 443,
    "otp": false,
    "auto_connect_host": "internaldomain.local",
    "can_save_credentials": true,
    "check_remote_availability": true,
    "run_logon_script": false
  }
]
 

I have the User Portal enabled on the LAN but not the WAN. The install scripts will only run when on the LAN, and when complete, Connect prompts the user for credentials. Once valid creds with SSL VPN permission are entered--so I thought--the configuration would be imported, after which the VPN could connect on the WAN as well.

But that's not what happened.

I can connect while on the LAN. But on the WAN, the connection fails with this message: "No response from gateway: X.X.X.X 8443 tcp-client".

If I enable the user portal on the WAN, I can connect. But that's not an acceptable solution.

Is enabling the user portal on the WAN the only way a .PRO file will work to make a VPN connection from the WAN?



This thread was automatically locked due to age.
  • 0

    Hello  ,

    Thank you for reaching out to the community, can you ensure if the tcp/udp Port 8443 is open from the ISP end, you can check the status here - https://www.ipfingerprints.com/portscan.php

    For tcp:


    For udp:



    Thanks & Regards,
    _______________________________________________________________

    Vivek Jagad | Team Lead, Technical Support, Global Customer Experience

    Log a Support Case | Sophos Service Guide
    Best Practices – Support Case  | Security Advisories 
    Compare Sophos next-gen Firewall | Fortune Favors the prepared
    Sophos Community | Product Documentation | Sophos Techvids | SMS
    If a post solves your question please use the 'Verify Answer' button.

    • 0 in reply to Vivek Jagad

      That was the first thing I thought of,  . Port 8443 was open. 443 (user portal) was not. Once it became available (by enabling the User Portal for the WAN zone), connection was successful.

      If I import a .OVPN file, I can connect from the WAN without enabling the User Portal on the WAN zone. I just can't connect if I use a .PRO file.

      I do know the .PRO file obtains the config using port 443, and only works when the User Portal is enabled. But I had assumed that the .PRO file, coupled with the user's credentials, would import the config while on the LAN, then retain the config for use on the WAN. That would make sense.

      But empirically, the user portal must be available on any zone where one intends to connect by SSL VPN when configured by a .PRO file. Is that correct?

      • 0 in reply to Jeff Vandervoort

        if you do not want to enable on zone specific, the you can also Add Local service ACL exception rule.

        Thanks & Regards,
        _______________________________________________________________

        Vivek Jagad | Team Lead, Technical Support, Global Customer Experience

        Log a Support Case | Sophos Service Guide
        Best Practices – Support Case  | Security Advisories 
        Compare Sophos next-gen Firewall | Fortune Favors the prepared
        Sophos Community | Product Documentation | Sophos Techvids | SMS
        If a post solves your question please use the 'Verify Answer' button.

        • 0 in reply to Vivek Jagad

          I don't ever want to enable the User Portal on the WAN, by zone or any other means. Especially given SFOS' history of WAN portal vulnerabilities.

          So, I take it you are confirming that making the User Portal available on the WAN is the only way to use a .PRO file to make a VPN connection from the WAN?

          • 0 in reply to Jeff Vandervoort

            Hi   and   - We tested internally and confirm the following.

            >>

            I do know the .PRO file obtains the config using port 443, and only works when the User Portal is enabled. But I had assumed that the .PRO file, coupled with the user's credentials, would import the config while on the LAN, then retain the config for use on the WAN

            >>

            The above statement is correct, as long as there's no change in the SSLVPN global settings.

            If there's a change in the SSLVPN global setting, for the client to get the changed config, we need to have the user portal enabled on WAN.

            I hope we have answered your query Jeff.

            • 0 in reply to Jeff Vandervoort

              Userportal is required to be open when using .pro file - that is true unfortunately

              When we deployed it, we thougt after initial testing, userporal needs only to be open when the users make their first connection.

              In real life, it is not true. Some Connect clients want to connect to userportal again, even they already have their config and it has not been changed on the firewall.

              You can then decide if you want to leave the userportal open 24/7 or to undo the .pro file deployment and use .ovpn again. Both have advantages and disadvantages. None is perfect.

              • 0 in reply to LHerzog

                Hi LHerzog, 

                That should not be true. As Giridhar said, even when using .pro files, User Portal access is only required when configuration changes and user have to re-download the config. If configuration didn't change, users do not require access to the User Portal to connect. 

                To double check, Giridhar & the engineering team re-tested this behaviour today and confirmed that's the case. 

                • 0 in reply to bobbylam
                  bobbylam said:
                  If configuration didn't change, users do not require access to the User Portal to connect. 

                  Once I communicated the same here on the forums. Then the occurrences increased, where users could not connect any more and we could see by the captcha field in the connect client, that it wanted to connect to userportal. Other clients of the same VPN config policy did not want to connect to user portal at the same time. You cannot handle to open and close user portal all day when users demand access to it.

                  • 0 in reply to LHerzog

                    In the upcoming SFOS v20 release, we are separating VPN configuration into a separate service, so admins do not have to expose the User Portal to WAN and their users can still retrieve updated VPN configuration. 

                    That should eliminate this management overhead on the admins, without the security risk of exposing User Portal on WAN. 

                    • 0 in reply to bobbylam

                      Thats good news! First time I read about that change. I hope this also works, when the userportal is running on a different port than the default one :-)

                      • 0 in reply to LHerzog

                        This improvement is still under development, but we took that feedback directly from users on this community!

                        • 0 in reply to bobbylam

                          Interesting discussion.

                          VPNs in my experience just aren't that dynamic. They're set up and stay the way they are unless there's a WAN IP change. With or without the SFOS v20 changes, as seldom as the VPN config will change, admins should at least have the option of having the config imported on the LAN and saved for use on the WAN. Then, even SFOS v19.5 would be useful, and the v20 config service would not need to be made available on the WAN in most cases. One less open port. Connect should check for changes when on the LAN, and whenever the User Portal is available in any zone.

                          As it is now, the .PRO file is useless unless you're willing to make the User Portal available on the WAN. Period. That's something even Sophos posts scary warnings about when you enable it in the GUI--and with good reason, judging by past vulns.

                          v20 will be too late for this project, whose deadline is Sophos draconian decision to remotely brick all Cyberoams on 1 Jul. They need to be rid of that Cyberoam, for sure, but my client was struggling before this news. So, I will need to fall back on .OVPNs and the support cost that will add.