HA Configuration Correct port must be monitored LAN port 1

Hi Dev,

You can find the HA log files in the /log directory through the advanced shell. To access log files through SSH, do as follows:

1. Log in to the CLI console of the primary device using administrator credentials.
2. Select option 5. Device Management.
3. Select option 3. Advanced Shell.
4. Type: cd /log
5. Press Enter.
6. To show the list of logs, type: ls
7. To view a log, type: cat LOGFILENAME

The below table describes the four relevant log files for HA.

I initially understood the problem differently too...
But:
If a monitored interface goes “down”, the firewall goes into “FAILED” status and stops processing traffic.
Unfortunately, this also happens at the same time with the slave if both (master and slave) have a "monitored link down".
...unlike the SG firewall which keeps the last "working" node active

Thank you mate... 

So, i was looking into this, as i did not remember this issue.

My cluster did the same approach to this behavior like UTM did. 
I brought both monitoring ports down (at the same time) on both appliances.

No reboot of Node1 and no Reboot of Node2. 
Node2 went into "Faulty". Node1 went into "Standalone". Traffic still processed by Node1 and no interruption in the network. 

As soon as i brought both links up: Reboot of Node2. Node1 stays online as Standalone. No interruption in the network. 
Node2 will get back to the cluster after the reboot and everything is working. 

So i am not seeing any kind of "issue here". 

Just to make sure, i did another test: I killed the Port1 (monitoring port) of AUX first. It will go into Faulty (no reboot). Then i waited some seconds and also brought Port1 down on the primary. Still the primary remains the standalone and waits. 

I am confused now ... i have checked the same thing but my firewall is restarting... whenever i turned of my lan port switch 

Hi LuCar,
This behaviour would be great and what I expected, but i bring down a network with rebooting a small (but monitored) DMZ-Switch. The whole internal routing stopped.

Compare ticket 07015414
"Hello Dirk,
I clarified during the call that in the event that any of the primary appliance's monitoring ports are down, the primary appliance will enter a fault state and the auxiliary appliance will assume control of the current traffic. If both appliances' monitor ports fail, both appliances will enter a faulty state and during that time, traffic will not be entertained"

"We can see that the Monitoring Port for the Primary was down, and as a result, it entered the FAULT condition.
If we check the AUX device at the same time, Monitoring Port was down.
Due to the Monitoring Port going down, both appliances were in an FAULT condition when the problem occurred."

I asked about 10 people at Sophos. Everyone said this was normal/expected behaviour.
I actually didn't want to believe that.

Basically, Sophos Firewall will try to stay online 24/7. 

Could be related to the general firmware update question. 

https://community.sophos.com/kb/en-us/122816

Many points are covered by this KBA:

https://community.sophos.com/kb/en-us/123174

As well as this:

https://community.sophos.com/kb/en-us/126722

And also verify switch configuration as switch misconfiguration cause the issue.

Regards

There is an old statement about this behavior, from 2018. 

What i now did: Reboot of a Switch, which is connected to the Monitoring Port1 on both appliances.

You see on the left side the Primary. On the Right side the AUX. 

To me, this looks totally fine. I did it with a "switch reboot" as well as i tried it with a "ifconfig down" command within SFOS itself. 

I did this test now 3 times, everytime with the same results. 

There is an old statement about this behavior, from 2018. 

What i now did: Reboot of a Switch, which is connected to the Monitoring Port1 on both appliances.

You see on the left side the Primary. On the Right side the AUX. 

To me, this looks totally fine. I did it with a "switch reboot" as well as i tried it with a "ifconfig down" command within SFOS itself. 

I did this test now 3 times, everytime with the same results.