Guest User!

You are not Sophos Staff.

Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 27 subscribers
  • Views 1011 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

rule 0 invalid although rules are set

Thomas Rechberger

Hello

there are lot of threads how to deactivate those rule 0 invalid messages in logviewer which seems to be common in XG. But even with rules i.e. web browsing, there are still those messages. Is this a bug?
Also this is misleading because the messages report deny but the traffic actually is not.



This thread was automatically locked due to age.
  • 0

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

    Its quite common, that XG Firewall will drop this traffic. Applications sometime burst FIN packets and/or the webserver cleans their connection tables. 

    XG will flush their table after 3 hours. Some server will flush after 3-24h. So this  traffic hits the invalid traffic. 

  • 0 in reply to LuCar Toni

    At first glance it looks like all traffic has gone there.

    So this is recommended?

    set advanced-firewall tcp-est-idle-timeout 21600

    exampe message:

    2021-03-13 13:05:01Firewallmessageid="01001" log_type="Firewall" log_component="Invalid Traffic" log_subtype="Denied" status="Deny" con_duration="0" fw_rule_id="N/A" nat_rule_id="0"
    policy_type="0" user="" user_group="" web_policy_id="0" ips_policy_id="0" appfilter_policy_id="0" app_name="" app_risk="0" app_technology="" app_category="" vlan_id=""
    ether_type="IPv4 (0x0800)" bridge_name="" bridge_display_name="" in_interface="Port1" in_display_interface="Port1" out_interface="" out_display_interface="" src_mac="" dst_mac=""
    src_ip="192.168.138.59" src_country="R1" dst_ip="xxx" dst_country="GBR" protocol="TCP" src_port="42778" dst_port="80" packets_sent="0" packets_received="0" bytes_sent="0"
    bytes_received="0" src_trans_ip="" src_trans_port="0" dst_trans_ip="" dst_trans_port="0" src_zone_type="" src_zone="" dst_zone_type="" dst_zone="" con_direction="" con_id="" virt_con_id=""
    hb_status="No Heartbeat" message="Could not associate packet to any connection." appresolvedby="Signature" app_is_cloud="0"

  • +1 in reply to Thomas Rechberger

    Its not. It does not matter what so ever. 

    The point is: This is normal. Stateful firewall do this all the time. A connection is build based on conntrack: You build a tcphand shake, the XG notice this and allows this connection. 1x the logviewer will protocol this. The connection based on source, destination and ports are logged and allowed.

    If there is not traffic for (3 hours per default), xg will delete this session, as it is idle state. 

    If the webserver and/or the client came up with the idea to send any packet for whatever reason, it will be dropped, as the initial session is already flushed. 

    Another reason for this invalid traffic is: If the client/server close the connection on purpose for what ever reason (application based), some apps send multiple "finish" packets. So they burst with multiple packets. XG will pickup the first packet and close/delete the session. Every further packet are getting logged as invalid traffic. 

    XG has invalid traffic logging per default enabled. SG does not. 

    In the End, most likely this packet is not relevant for the other end. If you extend the live time of the timeout of idle connection, XG will not drop those packets, instead forward them to the destination, which likely will drop it. I do not know any application, using such long lifetime frames. 

  • 0 in reply to LuCar Toni

    Understood. But shouldnt be more information be displayed in firewall log to see the reason. Otherwise the firewall log gets kind of useless with all those cosmetic errors.