Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 22 replies
  • Answers 2 answers
  • Subscribers 28 subscribers
  • Views 48203 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

Sophos XG Firewall 16.01.1 on XG135 - Unable to run SSL VPN (Remote Access) - Please Help...

Stefano27383

Hello,

After configuring the VPN SSL client (as described into the documentation) our SSL VPN clients can't connect to the firewall:

Mon Nov 21 16:35:58 2016 TCP: connect to [AF_INET]x.x.x.x:8443 failed, will try again in 5 seconds: The system tried to join a drive to a directory on a joined drive.
Mon Nov 21 16:36:03 2016 MANAGEMENT: >STATE:1479742563,RESOLVE,,,,,,
Mon Nov 21 16:36:03 2016 MANAGEMENT: >STATE:1479742563,TCP_CONNECT,,,,,,
Mon Nov 21 16:36:13 2016 TCP: connect to [AF_INET]x.x.x.x:8443 failed, will try again in 5 seconds: The system tried to join a drive to a directory on a joined drive.
Mon Nov 21 16:36:18 2016 MANAGEMENT: >STATE:1479742578,RESOLVE,,,,,,
Mon Nov 21 16:36:18 2016 MANAGEMENT: >STATE:1479742578,TCP_CONNECT,,,,,,
Mon Nov 21 16:36:28 2016 TCP: connect to [AF_INET]x.x.x.x:8443 failed, will try again in 5 seconds: The system tried to join a drive to a directory on a joined drive.
Mon Nov 21 16:36:33 2016 MANAGEMENT: >STATE:1479742593,RESOLVE,,,,,,
Mon Nov 21 16:36:33 2016 MANAGEMENT: >STATE:1479742593,TCP_CONNECT,,,,,,
Mon Nov 21 16:36:43 2016 TCP: connect to [AF_INET]x.x.x.x:8443 failed, will try again in 5 seconds: The system tried to join a drive to a directory on a joined drive.
Mon Nov 21 16:36:48 2016 MANAGEMENT: >STATE:1479742608,RESOLVE,,,,,,
Mon Nov 21 16:36:48 2016 MANAGEMENT: >STATE:1479742608,TCP_CONNECT,,,,,,

The firewall is behind a NAT router which forwards the traffic correctly (we tried to setup the tunnel from the LAN too without success).

As you can see the PCAP tool logs the 8443 port traffic from the VPN client

The configuration:

 

 

 

We tried to use a new self signed certificate too, but nothing changes...

 

Some additional info:

We changed the appliance LAN and WAN IP after the setup wizard.

The appliance is in HA mode.

 

Thank you for your help.

Stefano

 



This thread was automatically locked due to age.
Parents
  • 0

    Hi Stefano,

    Navigate to Administration> Device Access> WAN/LAN > SSL VPN; make sure SSL VPN is selected and allowed in here.

    Thanks

  • 0 in reply to sachingurung

    Hi sachingurung,

    I forgot to mention, the option for the WAN interface is already active...

  • 0 in reply to sachingurung

    Hi sachingurung,

    we have the following layout (working with the previous UTM)

     

    [DSL line]------[WAN Public IP][Internet Router][LAN 192.168.1.1]-------[WAN 192.168.1.254][Sophos XG1][LAN 10.7.7.1/24]

                                                                                                   |                                                      [HA on eth4]

                                                                                                   | -------[WAN 192.168.1.254][Sophos XG2][LAN 10.7.7.3/24]

     

    From the internet router WAN interface to the XG appliance we successfully NAT the ports 443 (user portal), 4422 (SUM), 3389, etc... we see packets coming in trough the 8443 port to the XG WAN interface.

     

    Here the screenshots:

     

    I'm thinking to remove the primary node, format, reconfigure and test again....

    Thank you for you time.

    Stefano.

     

  • 0 in reply to Stefano27383

    Solved rebuilding the cluster.

    • Removed node 2 from HA, and reverted to factory default configuration.
    • Rebuilt VPN configuration on node 1.

    Everything fine now...

    ...but I have no clue of what happened to the configuration sync process, and why only VPN SSL service was affected.

    Thank you all for you support.

     

  • 0 in reply to Stefano27383

    Hi Stefano,

    Wonderful that the issue is resolved rebuilding HA. XG might have encountered a backend glitch while syncing the ctsyncd and msync files in HA modes. The RCA can only be provided via support.

    Thanks

  • 0 in reply to sachingurung

    Hi All,

    still facing the same issue when joining HA nodes....

    When the system is running as stand-alone there are no issues.

    I want the UTM ha sync daemon back :(

     

     

  • 0 in reply to Stefano27383

    Stefano,

    Open a ticket with the Support. It can be a bug or some daemon that stop working.

    Let us know the answer.

    Thanks

  • 0 in reply to lferrara

    Just ot let you know:

    On Friday I reinstalled both devices.

    Re-imported the config (on a single node) and everything was fine.

    After setting up the HA I lost the SSL VPN service and the IPSEC service (again).

    How many of you have a working setup with HA and SSL VPN Clients?

     

    I will open a case....

  • 0 in reply to Stefano27383

    Hi,

    Provide me the case# from support. I will monitor the case.

    Thanks

  • 0 in reply to Stefano27383

    Stefano,

    just to let you know you're not alone.


    I currently have several tickets by the support because of HA (and HA with IPsec): split-brain on reboot of the primary (secondary locked in "fail-safe mode"), broken sync DB, IPsec not handled by HA (tunnel goes down for 70 to 180 seconds - but this seems related to lack of IKEv2), etc...

  • 0 in reply to David Touitou

    Thank you for sharing David.

    Yesterday we restored our UTM in order to re-format the two XGs and start with a brand new configuration too (without importing the backup config).

    The intention was to solve this basic issues without firing up a support case.

    After reading your message, I doubt this exercise will be useful.

    Maybe running on a stand alone appliance is the only safe option for now.

    Regards.

    Stefano.

  • 0 in reply to Stefano27383

    Just got confirmation by the support team...

    IPsec tunnel goes down for 50 to 170 seconds when switching from active to passive appliance.
    Might change (be fixed?) in SFOS 17 with IKEv2 but not sure.


    There's currently no public (customer or support L2/L3) way to rebuild the sync DB in case of "Probable DB sync problem".
    Switching from active to passive doesn't rebuild either, it is suppose to rebuild itself in case it's needed.
    The only official way is to break (disable) HA, that makes the passive appliance do a factory reset (means you have to reconfigure it from scratch) and rebuild the cluster.

Reply
  • 0 in reply to Stefano27383

    Just got confirmation by the support team...

    IPsec tunnel goes down for 50 to 170 seconds when switching from active to passive appliance.
    Might change (be fixed?) in SFOS 17 with IKEv2 but not sure.


    There's currently no public (customer or support L2/L3) way to rebuild the sync DB in case of "Probable DB sync problem".
    Switching from active to passive doesn't rebuild either, it is suppose to rebuild itself in case it's needed.
    The only official way is to break (disable) HA, that makes the passive appliance do a factory reset (means you have to reconfigure it from scratch) and rebuild the cluster.

Children