v18: Bug with data counting in firewall rules?

Hi cryptochrome, 

Could you please share the screenshot of the firewall rule that shows data in and out counters? I will verify if it should be like that or not and update you.

Thanks,

Hi cryptochrome, 

Could you please share the screenshot of the firewall rule that shows data in and out counters? I will verify if it should be like that or not and update you.

Thanks,

Sure, here you go:

Firewall Rule:

Corresponding NAT rule:

Firewall Rule Details:

Note that this is just one example. I am seeing the same "reversed" counter on other incoming rules. 

How do you count the data? If someone on the internet initiates the connection and transfers a lot of data, does that count as incoming or outgoing?

LuCar Toni said:

LAN to WAN:

Download Scenario: Client sends 5 Bytes to XG. Server sends 10 MB to XG.  XG Sends 5 Bytes to Server, XG Sends 10 MB to the Client. 

From XG Perspective: 

Firewall: IN 10 MB, OUT 5 Bytes. 

Firewall: Sent 10 MB to the Client, Sent 5 Bytes to the Server. 

Firewall: Gets 10 MB from the Server, Gets 5 Bytes from the Client.

Firewall: Downloads 10 MB from the Server, Uploads 5 Bytes to the Server.

Firewall: Downloads 5 Bytes from the Client, Uploads 10 MB to the Server. 

DNAT Scenario:

Download Scenario: WebClient sends 5 Bytes to XG. DMZ Server sends 10 MB to XG.  

Firewall: IN 10 MB, OUT, 5 Bytes. 

Firewall: Sent 10 MB to the WebClient, Sent 5 Bytes to the DMZ Server. 

Firewall: Gets 10 MB from the DMZ Server, Gets 5 Bytes from the WebClient.

Firewall: Downloads 10 MB from the DMZ Server, Uploads 5 Bytes to the  DMZ Server.

Firewall: Downloads 5 Bytes from the WebClient, Uploads 10 MB to the WebClient. 

Sorry Lucar, but I do not agree with you at all.

Traffic starts to count when the first point starts the connection. So if we are in a situation LAN to WAN, the Client sends a request on an external website to GET a package, so the server responds "OK this is the 10 MB package" and bla bla bla, the download starts. So on the WAN interface, I expect to see Inbound 10 MB while Outbound just few KBs.

The same applies for WAN to LAN. I expect to see that outbound of WAN port is 10 MB while the inbound are just few KBs.

This is the universal approach.

From advanced shell use the "old" iftop command in this way:

iftop -i Port2

once inside use the "t" letter to switch between TX and RX and at the same time start to download something from internet.

Same thing for traffic from WAN to LAN.

Please update with the test. I do not want to connect to a customer's XG box today for a test as it is Saturday.

This is how XG is doing it on all installations. 

I will not update the iftops for now, they will simply reflect the same thing. 

Luk, you need to keep in Mind, Firewall Logging will be the same, if you talking about WAN, LAN,DMZ etc. XG will not start to act differently, because you have a DNAT. 

So do not worry, everything is the same like on V17.5. I could not find any inconsistency in the logging but a discussion about whether it should be called IN for Value A or called OUT for Value A. The Values are correct. 

As told earlier, i am not saying this is the best solution for everything, it is more likely a "term issue". 

Also checked ideas.sophos.com. Could not find a feature request to reverse those values. 

My suggestion would be to have this parameters variable and let the customer choose, how XG should show the traffic on this particular firewall rule. 

PS: If Sophos change those values, they would not make any sense to me.

LAN to WAN with Big OUT and Low IN, looks odd to me. 

WAN to DMZ would be fine with those switch. BIG OUT, Low IN. 

Sophos could simply remove IN/OUT Terms to meet other vendors. 

Sometimes you do not have to agree with everybody, cryptochrome . That is actually my personal opinion like always. I am posting as a person here, not a Sophos Employee in my Free Time.

After setting all cards to the table, other should revisit the post and decide, if they agree or not. 

Prism FloSupport NateP2 

After your first post, it looked like there is a Bug, which is not. 

So you are agree with me, there is no Bug nor inconsistency in the whole process? 

The only point, which you want to have, is to change/switch both values for A/all firewall rules, correct? 

If you would change it for all Rules, maybe other firewall rules could be not logically anymore. 

LuCar Toni said:

PS: If Sophos change those values, they would not make any sense to me.

Obviously.

And that's the whole problem here. You still don't understand the issue. And you refuse to even consider that something you don't understand ("make any sense to me") could actually be right.

I guess ignorance is bliss.

LuCar Toni said:

 

Sophos could simply remove IN/OUT Terms to meet other vendors. 

Since you edited your post while I was typing my response, here is my reply to the additions you made to it:

LuCar Toni said:

 

So you are agree with me, there is no Bug nor inconsistency in the whole process? 

God, this is painful. No, I do not agree with you. Because you refuse to understand the issue. I have repeatedly stated that there is in fact an inconsistency, because the data counting actually works fine on outgoing, SNAT/MASQ traffic. It works differently on incoming DNAT traffic. So there is at least an inconsistency. Whether that inconsistency should be labeled as a bug is not for me to decide (although I would definitely see it as one).  

LuCar Toni said:

The only point, which you want to have, is to change/switch both values for A/all firewall rules, correct? 

If you would change it for all Rules, maybe other firewall rules could be not logically anymore. 

No :-/ Not correct. I do not want values changed for all firewall rules. Only for those where the indication of traffic direction is actually wrong (from what I can tell, that is only relevant to incoming DNAT traffic). 

But you're not listening, so whatever. 

LuCar Toni said:

So you are agree with me, there is no Bug nor inconsistency in the whole process? 

I understand what cryptochrome is trying to explain to you, but in my opinion, this isn't a bug.

I don't even care about the data counting in the rules, every other NGFW vendor I've used never showed the data counting as XG shows, they always showed in the Rule "Hit Counter". At the same time showing the first time the Rule has been used, and the last time It has been used. Which is much better than showing just the amount of data transferred over that rule in XG right now.

If you wanted to see the traffic bandwidth being transferred over a rule, you would use the Logs or the Reporting system of the appliance. The only problem of doing this in XG, is because the current logs & reporting system is bad compared to the competition.

Thanks!

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

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? cryptochrome 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 Prism 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. 

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

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. 

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). 

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). 

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.

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). 

LuCar Toni said:

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 said:

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 said:

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 said:

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).

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. 

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.

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".

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!

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

Prism said:

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 said:

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 said:

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. 

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. 

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.