Traffic allowed although rule specifies "drop" - or log entry is incorrect / misleading ?

Which Firmware do you use? 

The Firmaware is Sophos Firewall XG home SFVH (SFOS 18.5.1 MR-1-Build326)  running on a Protectli FW4B

Thought this behavior was fixed with NC-64820 but looks like it only covers inbound traffic. See: https://docs.sophos.com/releasenotes/index.html?productGroupID=nsg&productID=xg&versionID=18.0

Awarrenhttp proxy blocks inbound connections on port 443.

What this generally speaking means: If you configure a block role on SFOS, you see the yellow indication of Proxy. This means, the traffic for HTTP/S is dropped by the proxy instead of firewall. The Proxy will drop it stateless and gives a block page to the user. 

This was the case for inbound traffic, therefore it was fixed for inbound. But outbound seems to be still the case. I assume because of user interaction (Blocking is more radical then to deny the traffic in proxy, because of user interaction in browser). 

Check the web proxy log. 

Thank you!   This does explain the symptoms I‘ve been seeing, and I just confirmed tHat there are matching entries in the wegfeiltet ( I wonder what Autocorrect was thinking here, thIs should have been „webfilter“) log.  Anyhow, I still think the status „ALLOWED“ in the firewall log is misleading or even an error. 

With best regards from Germany

Volker

Thank you!   This does explain the symptoms I‘ve been seeing, and I just confirmed tHat there are matching entries in the wegfeiltet ( I wonder what Autocorrect was thinking here, thIs should have been „webfilter“) log.  Anyhow, I still think the status „ALLOWED“ in the firewall log is misleading or even an error. 

With best regards from Germany

Volker

Hello Volker,

Adding to what has been mentioned in this post, if you do a conntrack on the console of the XG for this connection what does conntrack shows?

What firmware version are you using?

Regards,

Good morning Emmanuel,,

I did conntrack -L -s 192.168.1.247 -d

and got

 SFVH_SO01_SFOS 18.5.1 MR-1-Build326# conntrack -L -s 192.168.1.247 -d 47.112.127 .239                                                                             proto=tcp      proto-no=6 timeout=5 state=CLOSE_WAIT orig-src=192.168.1.247 orig -dst=47.112.127.239 orig-sport=35103 orig-dport=443 packets=4 bytes=216 reply-sr c=192.168.1.1 reply-dst=192.168.1.247 reply-sport=3128 reply-dport=35103 packets =3 bytes=132 [ASSURED] mark=0x8001 use=3 id=4304640 masterid=0 devin=Port1 devou t= nseid=0 ips=0 sslvpnid=0 webfltid=2 appfltid=0 icapid=0 policytype=1 fwid=62  natid=2 fw_action=0 bwid=0 appid=0 appcatid=0 hbappid=0 hbappcatid=0 dpioffload= 0 sigoffload=0 inzone=1 outzone=2 devinindex=5 devoutindex=0 hb_src=0 hb_dst=0 f lags0=0x80020000208008 flags1=0x40040000048 flagvalues=3,15,21,41,55,67,70,94,10 6 catid=84 user=0 luserid=0 usergp=0 hotspotuserid=0 hotspotid=0 dst_mac=00:e0:6 7:2a:88:d8 src_mac=00:62:6e:58:85:94 startstamp=1634092152 microflow[0]=INVALID  microflow[1]=INVALID hostrev[0]=0 hostrev[1]=0 ipspid=0 diffserv=0 loindex=6 tls ruleid=0 ips_nfqueue=0 sess_verdict=0 gwoff=0 cluster_node=0 current_state[0]=12 1 current_state[1]=121 vlan_id=0 inmark=0x0 brinindex=0 sessionid=484 sessionidr ev=47623 session_update_rev=0 dnat_done=0 upclass=0:0 dnclass=0:0 pbrid_dir0=0 p brid_dir1=0 conn_fp_id=NOT_OFFLOADED 

The firmware is SFVH (SFOS 18.5.1 MR-1-Build326)   

Thats the expected behavior. You see the proxy is intercepting this traffic by the port redirect to 3128. This is to give the user a block page in the end of the connection instead of just block the traffic. 

From a user perspective, he will get a block page, not only a connection refused in browser.

Yes, I understood that part.  Of course, in this particular case the behavior is less than perfect .   These are IP-Cameras, which are used in a surveillance system.  The rules are set up in such a way, that, except for port 123 for NTP requests, they may not reach out to the WAN..  of course, they try- using HTTPS to some website living in China.  And the camera couldn‘t care less it it gets sent a „blocked“ page 

That‘s where my alarm bell starts ringing when I see „ALLOWED“ in the firewall log.  The message is at least misleading… 

Hello Volker,

Thank you for the information. 

As mentioned by Luca, this is currently expected, but I do agree that is misleading.

Searching internally I found a case similar to yours, they’re still currently looking into it, and seeing what changes would need to be done in the architecture of the SFOS to fix this.

Regards,

Good evening, Emmanuel,

Thanks - knowing where the reefs and shallows  are allows me to circumvent them . Not as good as no reefs at all, but a situation I can live with quite comfortably