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

Top Replies

  • The specific change you mention was a result of a security review we carried out on the OTP functionality. It is not good practice to provide methods to recover existing secrets because this makes it much easier to create cloned tokens that could be used without the knowledge of the original user to gain access to their account. Recovering OTP on an account by deleting the existing secret and creating a new one is more secure because even if it is done by the wrong person, the original user will realize the error the next time they try and log in using their old token.

    You see the same behaviour in most websites that offer OTP options like this - the only way to recover if you lose your OTP is to re-initialize with a new secret.

    Your point about including more specifics about this in the release notes is valid. We try to keep the release notes brief so that customers can read them all quickly and identify areas that may concern them where they can dig in to documentation to find out more. Sometimes we make them too brief. We'll take your feedback into account.

    [I updated my original post because I mistakenly thought I was reading the v19 EAP1 forum. Apologies for any confusion.]

    Jump to answer
Parents
  • Installed and all our workstation Heartbeats are missing (after rebooting workstations).

    Quite an issue as heartbeats are required for all workstation connectivity. Had to physically connect to the XG to put a temporary access rule in.

Reply
  • Installed and all our workstation Heartbeats are missing (after rebooting workstations).

    Quite an issue as heartbeats are required for all workstation connectivity. Had to physically connect to the XG to put a temporary access rule in.

Children
  • Seems to be faster, less having to refresh pages to get all inserts.

    No improvements to IPv6.

    Ian

    Added:- still have the heartbeat service failure.

    Probably a bit harsh with the no improvements in IPv6, seeing there is a fix listed.

    The FQDN tab still does not recognise IPv6 addresses, so when will this be fixed?

    Ian

    XG115W - v19.5.1 mr-1 - Home

    If a post solves your question please use the 'Verify Answer' button.



    expanded original comment about IPv6.
    [edited by: rfcat_vk at 6:41 AM (GMT -8) on 1 Dec 2021]
  • I think I may have solved this. Details are in a similar issue I had before when I had to re-register an XG in Sophos Central - https://community.sophos.com/sophos-xg-firewall/f/discussions/130861/how-does-heartbeat-work

    For future reference and so I can anticipate this in advance, is it normal for new certificates to be generated for a firmware update, or is this specific to this firmware update?

  • This should not be the case and is not expected to break after the firmware update. Could you create a support case to get the sorted out? 

    __________________________________________________________________________________________________________________

  • Also have the heartbeat error. 

    I also get the following message under --> System --> Sophos Central.

    Security Heartbeat is not available due to licenses. Check your licenses. Please contact your Sophos partner to update your Sophos Central or Sophos Firewall licenses.

    The license is okay, though. Re-registering the XG in Central did not help either.

  • If it is indeed a certificate issue, your endpoints need access to the internet and a DNS server to be able to update their certificate. This is the problem for us, because without a heartbeat, our endpoints are blocked on our network, so they can't update the certificate. I have to change our firewall rules so they can get the certificate and then they got there Heartbeats and I could change the firewall rules back.

    Not sure if you have the same sort of setup so I don't know if this will help you resolve your issue.

  • I have passed on an Access ID via so that devs can have a look at the logs.

  • Same Issue here. Clients on the VLAN that does NOT require HB on the firewall rule that allows http/https to WAN work fine, clients are authenticated using HB. Clients on the VLAN that requires HB to access the internet cannot authenticate using HB and cannot access anything on the WAN. This was an upgrade 18.5.1 -> 18.5.2 on an XG flashed SG430.

    After removing the HB and "match known users" requirement from the firewall rule the clients started authenticating using HB again.

  • Yes, MR2 regenerate a certificate on the firewall level. We will update all needed documents to reflect this and what to do. 

    Additionally we are checking, why a client is not able to update in the state of missing hb. 

    __________________________________________________________________________________________________________________

  • I would have thought that the issue (at least for us) was DNS. Even when we allowed internet access, certificates could not be renewed because we also require Heartbeat to access our internal DNS server (which isn't the XG). Unlike Heartbeat itself, which connects to a fixed IP, certificate renewal must use a URL. If you can't resolve that URL then you aren't going to be able to renew the certificate whatever internal firewall exceptions are present on the XG. Certificates renewed fine once we allowed access to our DNS without a Heartbeat.

  • __________________________________________________________________________________________________________________