Guest User!

You are not Sophos Staff.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 26 subscribers
  • Views 841 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

XG18.0.5 SD WAN Policy not working but worked perfect on XG18.0.4

Thomas Meier2

Hi all,

we do have connected to remote sites to our main site with xg 18.0.4 and a SD WAN policy because the internetbreakout should be on the main site.

Yesterday I updated all xg firewalls to 18.0.5.

But then the SD WAN policy stopped working.

So there was no Internet on the remote sites.

After rolling back to 18.0.4 everything was fine again!

Any idea what went wrong?

Many Thanks

Thomas



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

    Hi ,

    Thank you for reaching out to Sophos Community.

    I'd request you to upgrade only one of the location's firewalls to v18.0.5 MR5 and take the below observation to narrow down the issue.

    Note: Request to take a small downtime window while taking the below observation.

    ==> Check SD-WAN policy route and WAN gateway status.

    ==> Check whether internet is accessible on Sophos firewall(Diagnostics > Tools > Ping > 1.1.1.1 or google.com or any other domain).

    ==> Check packet flow under packet capture.

    Packet capture: support.sophos.com/.../KB-000035761

    ==> Also check drop packets if any.

    Drop-packet-capture: support.sophos.com/.../KB-000036858

    ==> Take an observation by creating a new SD-WAN policy after upgrading the firmware to v18.0.5 MR-5

    It would be great if you can share snapshots of SD-WAN policies configured with the current firmware.

  • 0 in reply to FormerMember

    Hi Yash,

    many thanks for the quick and good help.

    I will perform a test but now I'm not sure how I should aktivate SFOS 18.0.5 MR-5-Build586?

    Should I just boot with this firmware or should I start again the download and then install?

    On firmware I can activate SFOS 18.0.5 MR-5-Build586 and on latest available firmware I see HW-18.0.5_MR-5.SF300-586

    I can't remember the exact writing before upgrading...

    many thanks

    Thomas

    btw: how can I insert a snapshot

  • FormerMember
    0 FormerMember in reply to Thomas Meier2

    SFOS 18.0.5 MR-5-Build586 is an inactive firmware.

    As the current running firmware is v18.0.4 MR-4, the firewall shows SFOS 18.0.5 MR-5-Build586 as the latest available firmware.

    I'd suggest downloading it again and install it.

    Later, follow the steps mentioned in above comment and share your observation.

  • 0 in reply to FormerMember

    Hi Yash,

    I have good news.

    Yeasterday evening I switched again one firewall to SFOS 18.0.5 MR-5-Build586 but just booting the version.

    Everthing works fine also the SD-WAN policy.

    So I leave the firewall with version 18.0.5 and I think also the other firewall will work fine with version 18.0.5.

    Maybe I have to explain something.

    On our mainsite we do have a xg230 firewall cluster and at the time when the cluster was updated to version 18.0.5 I started the update on the remote site firewalls.
    Is it possilble that when the remote FW starts it will try to connect the SD WAN to the main site?
    Because the main FW wasn't up and running at that point the remote FW got the failure.

    I think if I would have restarted the remote FW after the main FW was up and running then on the remote site everthing would have been fine....

    Many thanks for your help

    Kind regards

    Thomas

  • FormerMember
    0 FormerMember in reply to Thomas Meier2
    Thomas Meier2 said:
    On our mainsite we do have a xg230 firewall cluster and at the time when the cluster was updated to version 18.0.5 I started the update on the remote site firewalls.
    Is it possilble that when the remote FW starts it will try to connect the SD WAN to the main site?
    Because the main FW wasn't up and running at that point the remote FW got the failure.

    This would have not caused an issue. I'd suggest checking packet flow when you report/observe any communication-related issue.

    Monitor traffic using Packet Capture Utility

    Monitor packet flow using the command line interface