Clean Up rule "from any, to any, drop" that's allowed on the Internet anyway !!! WTF ?

Yeah, this would be a serious issue if the Log Viewer was truly reflecting what's happening.

Unfortunately the Log Viewer is mostly broken and doesn't report correctly on what the device is doing.

If you want to really know what's happening access the XG Firewall via SSH and use the command line tools.

The GUI is useful for creating objects, rules, interface status and the occasional report. Serious log analysis using the GUI will just leave you frustrated, confused, no hair and an endless stream of swearing.

Yeah, this would be a serious issue if the Log Viewer was truly reflecting what's happening.

Unfortunately the Log Viewer is mostly broken and doesn't report correctly on what the device is doing.

If you want to really know what's happening access the XG Firewall via SSH and use the command line tools.

The GUI is useful for creating objects, rules, interface status and the occasional report. Serious log analysis using the GUI will just leave you frustrated, confused, no hair and an endless stream of swearing.

2018 soon and still stuck using CLI ... 

Would you happen to have a list of those commands ?

Thanks

Hundreds of "allowed" traffic on the clean up rule today.

To update the thread in regards to the allowed traffic that Big_Buck was experiencing, we were able to perform a remote session together to further investigate.

The traffic that was being passed was his local Sophos Access Points communicating with the internal Sophos XG interface to establish a tunnel. The XG will listen for this local access point traffic regardless of what firewall rules are in place. With the clean up rule disabled, the access point traffic was still being allowed and received by the XG by the default rule 0. It was just interesting that the traffic was matching to this cleanup rule when viewed in the log viewer. Perhaps because the rule is encompassing "any>any". I have noted this and will followup to attempt to replicate with our internal team to report.

The other traffic that was being allowed was ICMP pings, however this may have been caused due to Pings being allowed on the WAN zone via the local service ACL.
We also disabled this during our troubleshooting call which I hope will resolve this.

Regards,

FloSupport | Community Support Engineer

The official CLI documentation is here:

Sophos Firewall Command Line Reference Guide v16.5

Also there's a bunch of logfiles in /var/tslog. awarrensmtp.log and awarrenmta.log in particular are useful for Legacy Mode and MTA Mode troubleshooting respectively.

tl;dr

Log Viewer misrepresents what's actually happening.

Use other tools (e.g. Console, Advanced Shell) to see what's really happening.

FloSupport said:

To update the thread in regards to the allowed traffic that  was experiencing, we were able to perform a remote session together to further investigate.

The traffic that was being passed was his local Sophos Access Points communicating with the internal Sophos XG interface to establish a tunnel. The XG will listen for this local access point traffic regardless of what firewall rules are in place. With the clean up rule disabled, the access point traffic was still being allowed and received by the XG by the default rule 0. It was just interesting that the traffic was matching to this cleanup rule when viewed in the log viewer. Perhaps because the rule is encompassing "any>any". I have noted this and will followup to attempt to replicate with our internal team to report.

The other traffic that was being allowed was ICMP pings, however this may have been caused due to Pings being allowed on the WAN zone via the local service ACL.

We also disabled this during our troubleshooting call which I hope will resolve this.

Regards,

FloSupport | Community Support Engineer

This is one thing I really think Sophos XG needs - the ability to see ALL firewall rules on the firewall page, not just user created. I created an entry on the Sophos Ideas page a few days ago if anyone else thinks this would be useful:

Would you please help.

I need to hear about how you do it.

Thanks.

PJR

I have re-opened the case today.

To clarify, here's a resumé of the clean up rule logs. As of 7th December.

1. With v17 MR1, I had various traffic allowed via CleanUp / DropAll rule up until the 27th November.
2. I upgraded from v17 MR1 to v17 MR2 on the 6th December.  But I reverted back to v17 MR1.
3. I noticed then traffic was allowed via CleanUp / DropAll rule up.  Far more than what I saw up until 27th November.
4. Sophos support looked at it, and we brought back both main firewalls to v17 MR2.
5. We disabled existing VPN IKEv2.  Created a new one with much the same parameters except for Gateway Settings' "Local Id" and "Remote Id" left untouched to default value. (i.e. blank)
6. Main VPN worked under v17 MR2.

Then we looked at what was happening with logs related to the CleanUp / DropAll rule

1. Most allowed traffic generated in CleanUp / DropAll rule originate from three AP55c antennas from LAN Network to LAN address of the firewall on port 8474.
2. Some WAN ICMP traffic is allowed to a WAN address behind which one of our network is NATed.  Not the same WAN address as our firewall.
3. Some WAN traffic on port 6666 is allowed to a WAN address behind which one of our network is NATed on port 8443.  Not the same WAN address as our firewall.
4. Some WAN traffic on ports 54680 is allowed to a WAN address behind which one of our network is NATed on port 8443.  Not the same WAN address as our firewall.
5. Some WAN traffic on ports 10978 is allowed to a WAN address behind which one of our network is NATed on port 8443.  Not the same WAN address as our firewall.
6. Some WAN traffic on ports 49977 is allowed to the WAN address of the firewall on port 8443.
7. Some WAN traffic on ports 53798 is allowed to a WAN address behind which a second one of our network is NATed on port 8443.  Not the same WAN address as our firewall.
8. Some WAN traffic on ports 10978 is allowed to a WAN address behind which a second one of our network is NATed on port 8443.  Not the same WAN address as our firewall
9. Some WIFI traffic on ports 43265 is allowed to  WAN on port 443.
10. Some WAN ICMP traffic is allowed to a WAN address behind which a second one of our network is NATed on port 8443.  Not the same WAN address as our firewall
11. et.c. et.c. et.c.  Many more.  There's traffic generated on most of our WAN ip addresses in fact.

For all of the above:

1. Ping is not allowed via ACL.
2. Sometime the destination port is blank, sometime it is port 2 (WAN)
3. Sometime the originating port is port 1, sometime it is port 2.

 The problem is worsening.

I'm back to MR1.

v17 MR2 have killed our access to Exchange OWA.

Too many problems with MR2.

This is nausea.

Hey Big_Buck

-Edited to correct my mistake-

Could you please also verify using the Packet Capture utility available in the diagnostic tools regarding this traffic?
Please also note the TCPdump tool available within the CLI. 

Thanks,

FloSupport | Community Support Engineer