v18: Bug with data counting in firewall rules?

Hi,

I am noticing a strange behavior in v18 and the data counting in the firewall rules. I have some incoming rules (from Internet to DMZ) that are coupled with corresponding DNAT rules. The DMZ contains webservers, so they send a lot more data than they receive. However, the counters in the rules are the other way around: They show a lot more incoming data than outgoing data. 

Unless I am completely misinterpreting these counters (which I would like to rule out), it appears to me these counters have been reversed, e.g. incoming is actually showing outgoing, and outgoing is showing incoming. 

Any thoughts?

  • In reply to Prism:

    Please moderate with the terms. If someone here can open a ticket with the support to investigate can really help.

    For reporting, I do not like them compared to competition and to UTM 9 either.

    I have the doubt that this in/out issue generates false reports too.

    As feature, I am waiting reports per interface where you can start from interface and drill down to services, applications, users and so on. This is one of the most reporting I am using on UTM and on other products.

    Thanks

  • In reply to lferrara:

    Maybe i did a bad Job in explaining the underlying issue.

    Will try it again, because i understand, why this is causing an issue to people, but to resolve this, it is not quite easy.

     

     

    You have different perspectives for Firewall logging. You can perform it on different level.

    Interface Level (LAN or WAN Interface). Connection based (Client to Server, how much Data is processed - No IN/OUT).  

    Logging on the Interface, you have always the perspective IN/OUT. A Firewall always(usually) interact with two Interfaces in a basic communication. So you have two IN/OUT for the same Connection. You have the Destination Interface and the Source Interface. 

    Logging on the Connection, you would have Data send by A and by B. There is no UP/DOWN, only Bytes from A / Bytes from B. Or Bytes from Client, Bytes from Server.   

     

    Lets say, you are establish a connection between LAN Client and WAN Server. You could start to log the traffic now based on the Traffic from the WAN Interface or LAN interface. 

    From the LAN Interface, the Connection could be Logged as IN/OUT.

    From the WAN Interface, the same Connection, IN/OUT would be switched. 

    From the Connection based, you would have Bytes by LAN Client and Bytes by WAN Server. 

     

    Lets now look at XG. The design for years was to take the traffic from the "Destination Interface" perspective. 

    That made sense for the use Case of LAN to WAN. From the WAN interface perspective, Servers are sending date (IN) and Clients are sending data (OUT). 

    For DNAT, this could be an issue. The Destination Interface is DMZ. So the Client in WAN is sending Traffic (OUT), the Server in DMZ is Sending traffic (IN).

    If you leave the LAN/WAN concept and look at LAN to DMZ, you would have a certain expectation: DMZ Interface as Logging Interface: Because most likely your Client (LAN) is talking to a Server (DMZ).

    But this get more and more complicated if you take the bigger picture. You have LAN to LAN. What are you logging? DMZ to DMZ? (two Interfaces in the same Zone). You have your own created Zone? 

     

     

    Should XG automatically figure out which Interface is used and switching the logging based on the connection Destination? Could be "misleading" as well. I am not able to figure out a solution but to give the administrator the possibility to choose at their own, which way around the logging should be done. 

    What would be the solution?  Maybe you could give us some insights, how other vendors do this? Because as far as i know, they most likely only log the Connection (How much traffic is proceed with this rule) without any IN/OUT indicator. That is my finding at the moment. Please consider the bigger picture in resolving this issue. 

    *Edit* Forget one Use Case: Maybe use the WAN interface, then switch between IN/OUT because it is uploaded? But this would not work for VPN, MPLS etc. Also no solution. 

    As  explained, most NGFW are only using the Connection logging for their Firewall rules (which would be only sent by A / B, not IN/OUT). 

     

    Hope this is clear. If not, we can continue this Discussion via PM, if you want. Happy to explain this in more detail, why there is no inconsistency in the current Solution. 

     

     

    PS: Reports are generated based on the connection level. 

  • In reply to cryptochrome:

    Hello cryptochrome,

    I fully agree with you! Your conclusion is perfectly logical and correct. However, there are considerably more illogical things in XG and no one is doing anything about them. They even add others such as defining DNAT rules. This is absolutely monstrous! And how developers solved the illogical creation of DNAT rules:


    - added Server access assistant (DNAT) which automatically creates loopback and reflexive rules (I never needed to define them in my life, probably some Cyberoam paranoia)
    - as public IP addresses offer IP addresses from the internal network, is it really a big problem to select only IP addresses defined in the WAN or DMZ zone, really?
    - it is not possible to define the network service to which traffic is to be redirected under this unique tool. So you need to stop creating the DNAT rule, define the needed service and start over. I guess I didn't mention that it is not possible to use groups of services, but who would need it, right?
    - and what a surprise, as the source network we are offered the whole world, all physical ports, internal networks, DNS domains, DNS hosts but it's really special, zones are not available. Well, who needs it, right?
    - and in the final you will see an overview of all the horrors and what a surprise it is not possible to save the rule as inactive! What a surprise when a firewall rule can be saved as inactive ?!

    And the biggest surprise at the end, this is GA version !!!

    Sorry, this post is absolutely unrelated to this thread, I just wanted to point out that illogicality is many times more across the XG Firewall.

    Regards

    alda

  • In reply to LuCar Toni:

    Luca, thanks for explaining again in detail. I fully understand how it works, and I completely understand where you see the problem:

    From the LAN Interface, the Connection could be Logged as IN/OUT.
    From the WAN Interface, the same Connection, IN/OUT would be switched. 
    [...]
    The design for years was to take the traffic from the "Destination Interface" perspective.

    This is absolutely correct. Depending on perspective (external vs. internal), from a logical point of view, direction switches. And that's why taking the "destination interface" perspective just doesn't cut it. It leads to logic errors, as we have just established. 

     

    Other firewall vendors solve this by letting the firewall know which networks are considered internal networks and which ones are considered external. On Checkpoint, for example, you explicitly define a network topology in the firewall config. You assign networks into different brackets (namely internal and DMZ, the rest it automatically considered external). Some other firewalls do this more simply by just using route lookups (anything that is not in the routing table, e.g. uses the default route, is considered external). Juniper uses a combination of zones and routes. 

    Once it is determined whether the session initiator is external or internal, you can derive the correct "perspective", e.g. traffic direction.

    If initiator is external, count like this:

    Initiator sends data = INcoming
    Initiator received data = OUTgoing

    If initiator is internal, count like this:

    Initiator sends data = OUTgoing
    Initiator receives data = INcoming

    Sophos XG already uses zones. It even has a designation for each zone. You could consider every zone designated with WAN role as external. Voila. 

     

     

     

     
  • In reply to cryptochrome:

    Thanks for your suggestion.

    What about other zones, which actually could be external (VPN Zone, MPLS Zones, Zones behind routing devices (For example Dark Fiber etc.))? You would consider them as external or Internal? Giving the administrator a option to decide about each zone could be a better approach. 

     

    As said, there could be done many assumption on the firewall to find out, whether the traffic should be considered as IN or OUT. 

    Do you know, how other vendor actually perform, if you create a ANY-ANY Rule? This will hit for internal and external Traffic, hence it will lead to weird traffic data counter, isnt it? Also rules, which implies LAN and external zone in it (LAN & WAN to LAN & WAN).  

     

    Your examples makes perfectly sense, but are actually hard to archive and could lead to conflicts, which needs to be considered. 

     

    PS: There are setups, which this will eventually break: XG without WAN Zone but Uplink to the Internet (eBGP, Upstream hosts etc.), Parent Proxy Setups. DNAT into a VPN Tunnel (Traffic coming from WAN, going into the VPN Tunnel. Is it Out, Out? Hard to tell). 

     

  • In reply to LuCar Toni:

     

    the RX and TX are independent from the zone. RX and TX depends on the NIC where you are listening to.

    For example:

    your computer is sending a request to download data (it is not actually downloading the package) from an external public ip, what happens in terms of RX/TX?

    your computer nic: high TX/low RX

    nic of the switch where the computer is connected (ETH 0): high RX (because the port is receiving the request) / low TX

    nic of the switch where the router is connected (ETH 23): high TX (because the same number of packets (with some modification) is sent / low RX

    Now the package has been identified and the process starts again from the server high TX to router WAN port (high RX), high TX from router port to switch port ETH 23 (RX), ETH 0 TX and the computer nic RX.

    This process applies in networking since 1960s.

    Hope now it is clear.

  • In reply to lferrara:

    It was clear in the beginning, but what are you suggesting? 

    Are you see an issue in the way, XG is doing this? If you, please name it, maybe i can talk about this. 

    RX/TX is just another phrase of IN/OUT (Interface/NIC Level). 

  • In reply to LuCar Toni:

    LuCar Toni

    What about other zones, which actually could be external (VPN Zone, MPLS Zones, Zones behind routing devices (For example Dark Fiber etc.))? You would consider them as external or Internal? Giving the administrator a option to decide about each zone could be a better approach. 

    That's actually what I was suggesting in my last post :)  By pointing out how other firewall vendors do it. They let admins define the network topology in some way, through which you designate external vs internal networks. 

    LuCar Toni

    Do you know, how other vendor actually perform, if you create a ANY-ANY Rule? This will hit for internal and external Traffic, hence it will lead to weird traffic data counter, isnt it? Also rules, which implies LAN and external zone in it (LAN & WAN to LAN & WAN).  

    It has nothing to do with the rule, really. Whether the rule is any-any or more specific doesn't matter. The firewall still has to determine the incoming and outgoing interfaces of the connection. And it still has to determine who initiated the session in a flow. That's all it needs, when a topology (external vs internal) has been defined. 

    LuCar Toni

    Your examples makes perfectly sense, but are actually hard to archive and could lead to conflicts, which needs to be considered. 

    It's not really hard to achieve, see other firewall vendors. It just has to be thought through and properly engineered. I am pretty sure Sophos engineers would be able to come up with a solution fairly easily. 

    LuCar Toni

    PS: There are setups, which this will eventually break: XG without WAN Zone but Uplink to the Internet (eBGP, Upstream hosts etc.), Parent Proxy Setups. DNAT into a VPN Tunnel (Traffic coming from WAN, going into the VPN Tunnel. Is it Out, Out? Hard to tell). 

    Nope, nothing would break :)  See my comment above. All you need is a topology definition of some kind and then look at session establishment and which interfaces/zones the traffic traverses. And in complex, routed networks with BGP or MPLS and VPNs it's still all the same. You just have to define the topology from the perspective of the local firewall. It can be as simple as defining that all networks that the local firewall protects are considered internal networks and everything else is considered external (from that particular firewall's perspective).

  • In reply to cryptochrome:

    Maybe you could DM/PM me some screenshots of other vendors, how they do it on their rule set? Just curious about their solution. 

    Tried to find some information about this via research, but as other mentioned, other vendors are not showing such kind of traffic in their ruleset, as far as i could see. Could be wrong about that. 

     

  • In reply to LuCar Toni:

    No, I can't. It's the weekend. You just have to trust me on this. One example: Fortigate firewalls from Fortinet. You can enable a bytes column right in the ruleset. On Checkpoint, if you enable the Accounting feature, you right click on a rule, select "show in log", and it opens the log showing your bytes received, bytes sent, and total browse time (if it is app enabled) for every connection. It's similar on Palo Alto. 

    Not sure why you doubt any of this.

  • In reply to cryptochrome:

    cryptochrome
    On Checkpoint, if you enable the Accounting feature, you right click on a rule, select "show in log", and it opens the log showing your bytes received, bytes sent, and total browse time (if it is app enabled) for every connection.

     

    It literally opens the own checkpoint logs for this, if you can do the same thing on XG for data counting, the only problem is, the XG logs is worse than checkpoint.

    But I don't blame Sophos entirely for this, Their using a web based management solution, you can't compare to checkpoint smart console.

    PAN and Checkpoint also uses Hit Counters by default instead of data counting, of course you can enable to shows Bytes A/B on it (On PAN.).

     

    Also by default checkpoint uses Hit Counters on the rules instead of bandwidth as It is in XG.

     


     

    Of course in the logs will show bandwidth,duration,sessions.But as stated before, don't compare smart console directly to XG.

     

    Also, genuine question, Why data counting directly on the rule in XG is so important for you? What's the best use-case scenario for it?

    Isn't it better to just use the Logs/Reporting function that already exists? I know both of them are bad compared to the competitors, but at least it "works".

     

    LuCar Toni
    Tried to find some information about this via research, but as other mentioned, other vendors are not showing such kind of traffic in their ruleset, as far as i could see. Could be wrong about that. 

    They don't show it like XG.

     

    Also after after 40 replies over this thread,Isn't it better to XG follow the industry standard and also use hit counters for the rules instead of just showing bandwidth, also please, show when the rule has first and last used.

     

    Thanks!

  • In reply to Prism:

    Thanks for the log Prism.

    Since RX/TX depend on the interface you are using, I suggest Sophos to maintain the counters an apply the counters to the first matching interface.

    For LAN to WAN, TX is the traffic sent by the LAN and RX is the traffic received. Same thing from WAN to LAN: TX traffic sent by the WAN interface, RX traffic received. So in case of 10 MB file upload from WAN to LAN, RX is 10 MB, TX is few KBs.

    Also I suggest Sophos to put back the reports per Inteface like UTM does.

    Let's see what other users say about.

    Please vote and consider this feature request:

    https://ideas.sophos.com/forums/330219-xg-firewall/suggestions/34421893-report-of-traffic-for-each-wan-interface

    Regards

  • In reply to Prism:

    Prism

    Also, genuine question, Why data counting directly on the rule in XG is so important for you? What's the best use-case scenario for it?
    Isn't it better to just use the Logs/Reporting function that already exists? I know both of them are bad compared to the competitors, but at least it "works".

    The thing is, it's not important to me at all :-)  When I opened this thread, I never expected a huge discussion like this. I just noticed the counters on my incoming rules were wrong and opened a post, thinking it may be a bug. And now here we are, haha. 

    I also don't care whether the counters are displayed right in the rule or whether I have to open a different view for it (reports, logs, whatever). It doesn't really matter. The whole point is: the counters that are there are wrong. Sending data out of the WAN interface and showing that as incoming traffic is just plain crazy :)

    Prism

    They don't show it like XG.

    Well... they do, actually. Some even directly in the rule (Fortinet), some others require a few additional mouse clicks, but the data is available. With proper directional display. 

    Prism

    Also after after 40 replies over this thread,Isn't it better to XG follow the industry standard and also use hit counters for the rules instead of just showing bandwidth, also please, show when the rule has first and last used.

    I would second this request. It would be very helpful in housekeeping scenarios. 

  • In reply to Prism:

    Also, since you guys keep mentioning XG reports and that the data is available there as well, I just took a look. I clicked on an application in the traffic dashboard and immediately had to laugh out loud and hard. Like if this would make any sense whatsoever:

    Mind you, this is for one application. It tells me the source and destination zones had the exact same amount of hits and data, which of course is utter nonsense. Another pointer at just how wrong Sophos calculate data. 

  • In reply to cryptochrome:

    People have been complaining about XG reports and logs since it came out.

    That's why I wrote: (but at least it "works".)

    I'm a optimistic person; But only god knows when the devs will do something about this.

     

    I hope the best for v18.5, so no one have to complain about this anymore.