Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

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 Firewall: v19.5 GA: Feedback and experiences

Release Post:  Sophos Firewall v19.5 is Now Available 

Old v19.0 MR1 thread:  Sophos Firewall: v19.0 MR1: Feedback and experiences 

EAP Sub thread:  SFOS v19.5 Early Access Program (Read Only) 

EAP 19.5 Thread:  Sophos Firewall: v19.5 EAP1: Feedback and experiences 



This thread was automatically locked due to age.
  • Hi, We can't risk another downtime.

    We'll upgrade only when you are certain that the problem is fixed.

    What DB entry was missing and why?

  • __________________________________________________________________________________________________________________

  • Hi Bill,

    There is one parent table entry is missed which referred in one of the child table which cause this issue.

    As you've restore backup in v19.0.1, all your entries gets corrected, hence we are not able to find root cause for this.

    But I am sure now you'll not face this issue again in upgradation, at-least this same issue.

    If you still have concern then you can raise support case.

  • Hello 

    Want to Update from  19.0.1 MR1 Build 365 in Sophos Central, the Update Gear is spinning around 3 Hours, the "Alert" Says Firewall is Receiving the Update since 2h45M but nothing happen :-(, i found the KB from Yesterday. At first Update on Firewall itself was not found, after 1 Hour i tried it again and there was an Update found.
    So my customer dicided to wait until Sophos Central is working.

    So the Update Gear is spinning forever and ever, does Sophos Central abort this update after X Hours? Is there anything to do on Firewall itself to abourd this Cycle?

    https://support.sophos.com/support/s/article/KB-000044725?language=en_US

    Thanks in Advance
    Franjo

  • Hi,

    i updated a onprem VM XG without HA successfully.

    But when i updated a HA cluster onprem (2 x VM KVM) and switched Active/Passive the configurations are different !


    I noticed in HA link there are some messages like that

    18:23:57.846962 IP 169.254.192.2.13964 > 169.254.192.1.6379: Flags [S], seq 2618702982, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
    18:23:57.848188 IP 169.254.192.1.6379 > 169.254.192.2.13964: Flags [S.], seq 3666333204, ack 2618702983, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
    18:23:57.848439 IP 169.254.192.2.13964 > 169.254.192.1.6379: Flags [.], ack 1, win 229, length 0
    18:23:57.848552 IP 169.254.192.2.13964 > 169.254.192.1.6379: Flags [P.], seq 1:15, ack 1, win 229, length 14: RESP "PING"
    18:23:57.849556 IP 169.254.192.1.6379 > 169.254.192.2.13964: Flags [P.], seq 1:1068, ack 1, win 229, length 1067: RESP "DENIED Redis is running in protected mode because protected mode is enabled and no password is set for the default user. In this mode connections are only accepted from the loopback interface. If you want to connect from external computers to Redis you may adopt one of the following solutions: 1) Just disable protected mode sending the command 'CONFIG SET protected-mode no' from the loopback interface by connecting to Redis from the same host the server is running, however MAKE SURE Redis is not publicly accessible from internet if you do so. Use CONFIG REWRITE to make this change permanent. 2) Alternatively you can just disable the protected mode by editing the Redis configuration file, and setting the protected mode option to 'no', and then restarting the server. 3) If you started the server manually just for testing, restart it with the '--protected-mode no' option. 4) Setup a an authentication password for the default user. NOTE: You only need to do one of the above things in order for the server to start accepting connections from the outside."
    18:23:57.849570 IP 169.254.192.1.6379 > 169.254.192.2.13964: Flags [F.], seq 1068, ack 1, win 229, length 0
    18:23:57.849833 IP 169.254.192.2.13964 > 169.254.192.1.6379: Flags [.], ack 1068, win 245, length 0
    18:23:57.850101 IP 169.254.192.2.13964 > 169.254.192.1.6379: Flags [R.], seq 15, ack 1069, win 245, length 0
    18:23:57.850857 IP 169.254.192.1.6379 > 169.254.192.2.13964: Flags [.], ack 1, win 229, length 0
    18:23:57.851090 IP 169.254.192.2.13964 > 169.254.192.1.6379: Flags [R], seq 2618702983, win 0, length 0

    I think if REDIS db is not synced correctly, the configuration will has some issues ?

    Where is a solution ?

    Thanks

    Sk3

  • Hi Paolo, 

    Redis is not used to store configuration information on SFOS, only state information. Can you please clarify what you meant when you said configuration is different after you switched active/passive in your cluster? What steps specifically did you perform, and which configuration are different? 

  • I've got a problem with SIP line registration after upgrading to 19.5 (SFOS 19.5.0 GA-Build197).

    Did someone else have an issue with that ? Do you find a solution ?

    Thanks

  • Since upgrade from 19.0.1 to 19.5.0 LAN and WAN Ports are flapping up and down multiple times per minute.

    Port1 is completely unplugged.

    WAN port is of course plugged. Machine has ping loss and unstable VPN due to that issues after the upgrade.

    System is HA A/P on XGS136

    SYSTEM 23.12.2022 10:41 Interface Interface Port1 is Down 17813
    SYSTEM 23.12.2022 10:41 Interface Interface Port1 is Up 17813
    SYSTEM 23.12.2022 10:41 Interface Interface WAN_Static is Up 17813
    SYSTEM 23.12.2022 10:41 Interface Interface Port1 is Down 17813
    SYSTEM 23.12.2022 10:41 Interface Interface WAN_Static is Down 17813
    SYSTEM 23.12.2022 10:41 Interface Interface Port1 is Up 17813
    SYSTEM 23.12.2022 10:40 Interface Interface Port1 is Down 17813
    SYSTEM 23.12.2022 10:40 Interface Interface Port1 is Up 17813
    SYSTEM 23.12.2022 10:40 Interface Interface WAN_Static is Up 17813
    SYSTEM 23.12.2022 10:40 Interface Interface Port1 is Down 17813
    SYSTEM 23.12.2022 10:40 Interface Interface WAN_Static is Down 17813
    SYSTEM 23.12.2022 10:40 Interface Interface Port1 is Up 17813
    SYSTEM 23.12.2022 10:40 Interface Interface WAN_Static is Up 17813
    SYSTEM 23.12.2022 10:40 Interface Interface Port1 is Down 17813
    SYSTEM 23.12.2022 10:40 Interface Interface Port1 is Up 17813
  • Link-Flap behaviour stopped after an unplanned reboot of node1. Not good what happened here.

  • This looks like a Switch problem. If you did a failover (update), this will also let the firewalls switch the vMACs + vIP. This scenario can cause fun with the switch, if there is something like spoof protection. This looks like the switch disabled the the port and enabled it back again. 

    Check the logs of the Switch, if there are any. And check if you have Spoof protection / STP enabled on those ports. 

    __________________________________________________________________________________________________________________