Thread Info
  • State Not Answered
  • +3 person also asked this people also asked this
  • Locked Locked
  • Replies 56 replies
  • Subscribers 34 subscribers
  • Views 11546 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

v18: Bug with data counting in firewall rules?

cryptochrome

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?



This thread was automatically locked due to age.
Parents
  • FormerMember
    0 FormerMember

    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,

  • 0 in reply to FormerMember

    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?

  • +1 in reply to cryptochrome

    Hi  

    To answer your question about how the data counter works, if someone on the internet uploads to your webserver, that would be incoming traffic.  The server responses to those connections will be less unless you are downloading data from internet to local LAN.

    I hope that clears it up.

     

    Thanks!

  • 0 in reply to KingChris

    My Plex rule (and others) is the same, and I have always been so confused.  When I was on v17, I noticed it was only the "Business" rules which did this.  The other rule type (User / Network??) was the other way around, which is what I would expect.  So it has to do with DNAT rules it seems.  So confused.

    Just now I checked and it shows "in 42GB, out 371MB".  My Plex server itself is not taking in that much data, but serving up to family/friends.  Why is this counted as "in"?  I can't wrap my head around it.  This is clearly 42GB leaving my Plex server, hitting the XG and then going out the WAN.

  • +1 in reply to NateP2

    *Edit* To reflect this Thread better;

     

     

    V17.5 Client to Server through DNAT.

    Upload Something:

    Download something:

    Same behavior like V18. 

     

     

    LAN to WAN. Download shown as IN Bytes.

    DMZ to WAN. Download shown as IN Bytes.

    WAN to DMZ(DNAT). Download shown as IN Bytes. 

     

    The Plex Scenario shows this perfectly. 

    If the Client is in LAN, Plex in DMZ, streaming a Movie shows the movie as IN Bytes. 

    If the Client is in WAN, Plex in DMZ, Streaming a Movie shows the movie as IN Bytes. 

     

    Just to be complete.

    Client - XG1 SNAT - Internet - XG2 DNAT - Server 

    Client Upload:

    XG1 (SNAT):

    XG2 (DNAT):

     

     

    Client Download something:

    XG1 (SNAT):

    XG2 (DNAT):

     

  • 0 in reply to KingChris

    KingChris said:

    Hi  

    To answer your question about how the data counter works, if someone on the internet uploads to your webserver, that would be incoming traffic.  The server responses to those connections will be less unless you are downloading data from internet to local LAN.

     

     

    If that is the case then my observation is correct and we are looking at a bug here. The data is counted in the wrong directions for connections that are subject to DNAT. See Nate's response, too. He pretty much confirms it. 

  • 0 in reply to cryptochrome

    To add to my answer above something: 

     

    Actually you could resolve this by a little Switch in a Firewall to give the Administrator the possibility to "Switch" IN / OUT. 

    A little flag to tell the Firewall "This Rule is for NAT!". 

    But this would be just a "easy way out". I would actually hope, this is resolved in a deeper level in the upcoming releases!  :) 

  • 0 in reply to LuCar Toni

    LuCar Toni said:

     

    Lets recap the IN and OUT in Firewall Rule quickly.

    IN means, traffic coming from the Destination going through the XG to the Source.

    OUT means traffic, coming from the Source going through the XG to the Destination.

    [...] 

    Because basically the Firewall Rules was used for Traffic behind the XG through XG to the Internet, for example, this made perfectly sense. 

    Your Client is downloading something in the Internet. 

    LAN to WAN: IN 100 GB, Out 1 MB - Because the Internet is sending you traffic and we counting this as IN traffic. 

      

    I am not sure I can follow.... Let me re-iterate what I am seeing:

    Internet <-> XG Firewall <-> DMZ Server

    Internet user downloads a lot of data from the server in the DMZ. XG firewall shows this traffic as INcoming on the corresponding firewall rule. Nothing about that makes sense, it's just utterly wrong. 

    Again, this only applies on rules that are subject to DNAT. On SNAT connections, it shows the correct directions. This is inconsistent behavior at best, but I would actually go as far as saying this is clearly a bug.

    Note that this is reflected in all reports and statistics (counters in diagnostics etc.) as well. 

  • 0 in reply to cryptochrome

    Your Example is the same issue like the the PLEX issue here in this Thread.

     

    Firewall makes perfectly sense for "none DNAT traffic" because the counter was build for everything behind XG. 

    DNAT turns the switch and allows traffic coming from WAN to LAN. 

     

     

    Think about this: you create a ANY - ANY Rule. 

    This will allow LAN to WAN. But also WAN to LAN (Your DNAT Traffic). 

    How should the traffic counter now work? It is hard to tell and that is causing this issue for now. 

     

    Firewall rule counter was not designed to reflect such kind of traffic in the first place. 

    PS: I am not saying it is good in any way. I just try to tell you the Root Cause of this. 

  • 0 in reply to LuCar Toni

    LuCar Toni said:

     

    Think about this: you create a ANY - ANY Rule. 

    This will allow LAN to WAN. But also WAN to LAN (Your DNAT Traffic). 

    How should the traffic counter now work? It is hard to tell and that is causing this issue for now. 

     

    How the traffic should be counted? Like on any other network device on this planet, like on any other firewall: based on traffic direction, which can be observed by looking at the interfaces on which traffic enters and leaves. Even simple layer 2 switches can distinguish between incoming and outgoing traffic. There is no guess work involved. You look at the traffic, you see that the connection was initiated from the internet (wan interface) and that reply packets are coming from a different interface. In a nutshell, this is very basic connection tracking. It has nothing to do with NAT. You can clearly tell which side initiates the connection and which side responds. Whether IP addresses get translated in the process is irrelevant. 

    All the firewall has to do is look at who initiated the connection. If the server in the DMZ initiates a connection through an interface, it's outgoing traffic. If the server responds to a connection, it's incoming traffic. 

  • 0 in reply to cryptochrome

    I fully agree with . Lucar yours response is not helpful!

    If this is an issue, must be addressed and fixed. I guess that the counters are written inside postgres so I do not want to imagine that even the reports are wrong.

    Regards

  • 0 in reply to cryptochrome

    All the firewall has to do is look at who initiated the connection. If the server in the DMZ initiates a connection through an interface, it's outgoing traffic. If the server responds to a connection, it's incoming traffic. 

     
    That is how XG performs the Traffic logging.  
    NAT is not the issue, it is the definition of Zone concept. The Firewall with IN/OUT as "Terms" causing this misleading terms. 
     

    We are counting the Traffic after processing the Traffic through all modules. It is about to Leave the destination Interface and gets tracked.

     

    Important is the Traffic Initiator, as you said. 

     

     

    LAN to WAN. IN means Download (Send by the XG LAN Interface / WAN Server). OUT means Upload (Send by the XG WAN Interface / LAN Client). 

    WAN to DMZ. IN means Download (Send by the XG WAN Interface / DMZ Server). OUT means Upload (Send by the XG DMZ Interface / WAN Client) 

     

     

    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.  

     

     

    It is more likely a perspective issue. 

     

    Looking at the Plex Issue.

    Plex Client is in the WAN. 

    Plex Server is in the DMZ. 

     

    Client is building the Connection to Plex Server.

    Starting to Stream a Movie. 

    Client requests the Movie, sending 5 MB. 

    Server sending the Movie to the Client, Sending 10 GB. 

    Firewall: IN 10 GB, OUT, 5 MB. 

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

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

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

    Firewall: Downloads 5 MB from the Plex Client, Uploads 10 GB to the Plex Client.  

     

     

     

    XG Firewall Tracking does everything correct, from my point of view. 

     

     

    Maybe remove IN/OUT as Terms? You would have: 10 GB / 5 MB for example. 

     

     

     

    *edit* 

    Lets take another example:

    Client to DMZ. 

    Client downloads a file from my DMZ Server.

    IN would be the Traffic send by my Server.

    OUT would be the traffic send by my Client. 

     

    Thats how it works since the beginning. 

    Now the same is done by DNAT + Firewall. 

    Basically XG did not Change anything in his firewall behavior for NAT. It is simply another Client to Server concept. 

Reply
  • 0 in reply to cryptochrome

    All the firewall has to do is look at who initiated the connection. If the server in the DMZ initiates a connection through an interface, it's outgoing traffic. If the server responds to a connection, it's incoming traffic. 

     
    That is how XG performs the Traffic logging.  
    NAT is not the issue, it is the definition of Zone concept. The Firewall with IN/OUT as "Terms" causing this misleading terms. 
     

    We are counting the Traffic after processing the Traffic through all modules. It is about to Leave the destination Interface and gets tracked.

     

    Important is the Traffic Initiator, as you said. 

     

     

    LAN to WAN. IN means Download (Send by the XG LAN Interface / WAN Server). OUT means Upload (Send by the XG WAN Interface / LAN Client). 

    WAN to DMZ. IN means Download (Send by the XG WAN Interface / DMZ Server). OUT means Upload (Send by the XG DMZ Interface / WAN Client) 

     

     

    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.  

     

     

    It is more likely a perspective issue. 

     

    Looking at the Plex Issue.

    Plex Client is in the WAN. 

    Plex Server is in the DMZ. 

     

    Client is building the Connection to Plex Server.

    Starting to Stream a Movie. 

    Client requests the Movie, sending 5 MB. 

    Server sending the Movie to the Client, Sending 10 GB. 

    Firewall: IN 10 GB, OUT, 5 MB. 

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

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

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

    Firewall: Downloads 5 MB from the Plex Client, Uploads 10 GB to the Plex Client.  

     

     

     

    XG Firewall Tracking does everything correct, from my point of view. 

     

     

    Maybe remove IN/OUT as Terms? You would have: 10 GB / 5 MB for example. 

     

     

     

    *edit* 

    Lets take another example:

    Client to DMZ. 

    Client downloads a file from my DMZ Server.

    IN would be the Traffic send by my Server.

    OUT would be the traffic send by my Client. 

     

    Thats how it works since the beginning. 

    Now the same is done by DNAT + Firewall. 

    Basically XG did not Change anything in his firewall behavior for NAT. It is simply another Client to Server concept. 

Children
  • 0 in reply to LuCar Toni

    LuCar Toni said:

    It is more likely a perspective issue. 

     

     
    Maybe. And just to be clear: I completely understand what you are saying, but I think your perspective is still wrong. It's overly complicated, illiogical, entirely disregards the concept of TCP/IP session initiation (from which you must derive traffic direction) and goes against what any other firewall vendor is doing. As a matter of fact, it goes against what every vendor of any kind of network device is doing. 
     
    Just to make sure, it must not matter whether a connection is subject to NAT. All that matters is who is initiating the connection. From that perspective, session initiator is always IN, and session responder is always OUT. 
     
    To stay with your example on Plex:
     
    Plex Client initiates connection to Plex Server (sends 50 KB of data, requesting playback of movie). Plex Server ACKnowledges session, responds with 10 GB of data. Firewall is stateful, sees which side is initiating (SYN) and which side is responding (SYN ACK). Hence, Plex Client is INcoming traffic, Plex Server is OUTgoing traffic. 
     
    If the Plex Server would terminate the client session and then establish a new session back to the client to send the movie, your logic would be correct. But that's not how it works. 
     
    To be frank, I don't understand why we even have to discuss this, given the fact that XG does it correctly for all connections, except when NAT is in place (which changes absolutely nothing in terms of session establishment). This has to be looked at from a network perspective and a user perspective, not from a developer's perspective. 
     
  • 0 in reply to cryptochrome
    Plex Client initiates connection to Plex Server (sends 50 KB of data, requesting playback of movie). Plex Server ACKnowledges session, responds with 10 GB of data. Firewall is stateful, sees which side is initiating (SYN) and which side is responding (SYN ACK). Hence, Plex Client is INcoming traffic, Plex Server is OUTgoing traffic. 
     
    XG uses the Client Perspective. Hence it uses the terms of IN and OUT from the Client perspective. (Initiator). 
    Plex Client traffic is OUTgoing Traffic, because the initiator sends this traffic.
    Plex Server traffic is INcoming Traffic, because the recipient sends this traffic. 
     
    That is how XG does it for years and nobody was asking to change it. 
     
    Now in the setup of the DNAT, it could be misleading. DNAT gives us the setup, that the Initiator is NOT behind XG, instead the recipient is behind XG. 
     
     
    I am actually not sure, how V17.5 (Business App Rules) used to work. 
  • 0 in reply to LuCar Toni

    LuCar Toni said:
     
    XG uses the Client Perspective. Hence it uses the terms of IN and OUT from the Client perspective. (Initiator). 
     

     
    Well that perspective is wrong. Especially given the fact that you use this perspective only on DNAT traffic, but not on SNAT traffic (where you actually do it correctly). Totally inconsistent. 
     
    LuCar Toni said:
     
    Plex Client traffic is OUTgoing Traffic, because the initiator sends this traffic.
    Plex Server traffic is INcoming Traffic, because the recipient sends this traffic. 
     
    That is how XG does it for years and nobody was asking to change it. 
     
     
    As you can see, I am not the only one who is confused about this weird perspective of looking at things. This is probably coming from a developer's mindset, not one of a network engineer's. 
     
    LuCar Toni said:
     
    Now in the setup of the DNAT, it could be misleading. DNAT gives us the setup, that the Initiator is NOT behind XG, instead the recipient is behind XG. 
     
     
    Right. And this should be changed. If DNAT is "misleading" the firewall's data collection, then it's a bug. 
     
    Just to re-iterate, when there is no DNAT in place, the XG actually does it right. The traffic directions are correct in all cases except when DNAT is applied. 
  • 0 in reply to cryptochrome

    V17.5 Client to Server through DNAT.

    Upload Something:

     

    Download something:

     

    Same behavior like V18. 

     

    Just to re-iterate, when there is no DNAT in place, the XG actually does it right. The traffic directions are correct in all cases except when DNAT is applied.

     

    Actually that is not true.

    LAN to WAN. Download shown as IN Bytes.

    DMZ to WAN. Download shown as IN Bytes.

    WAN to DMZ(DNAT). Download shown as IN Bytes. 

     

     

    The Plex Scenario shows this perfectly. 

    If the Client is in LAN, Plex in DMZ, streaming a Movie shows the movie as IN Bytes. 

    If the Client is in WAN, Plex in DMZ, Streaming a Movie shows the movie as IN Bytes. 

     

     

     

    Just to be complete.

    Client - XG1 SNAT - Internet - XG2 DNAT - Server 

    Client Upload:

    XG1 (SNAT):

    XG2 (DNAT):

     

     

    Client Download something:

    XG1 (SNAT):

    XG2 (DNAT):

     

     

    I am not sure, why this discussion comes up "now". 

    This traffic logging is in the product like this forever.

     

  • 0 in reply to LuCar Toni

    LuCar Toni said:

    V17.5 Client to Server through DNAT.

    Same behavior like V18. 

    I am talking about v18, not v17. If v17 has done it like this that's fine, I never noticed and hence didn't care. Now with v18 I noticed. 

    LuCar Toni said:
     

    Actually that is not true.

    LAN to WAN. Download shown as IN Bytes.

    DMZ to WAN. Download shown as IN Bytes.

    WAN to DMZ(DNAT). Download shown as IN Bytes. 

    You're still not grasping the concept of session initiation. It doesn't matter which interface combination (LAN to WAN or the other way around). The only thing that matters is who initiated the connection. You can't seem to wrap your head around it because you keep thinking about this from the client perspective you are used to. But it's wrong. Try to think outside the box. In your WAN to DMZ (DNAT) example above, the client (WAN) is downloading from a server in the DMZ, I assume. The server is sending data TO the client, OUT the WAN interface through the DMZ interface. The only thing that the traffic direction must be derived from is the session initiator. You send data TO the initiator, you send data OUT. You receive data FROM the initiator, data is coming IN. It's really as simple as that. 

     

    If you just want to be right and think the way Sophos XG is doing it now, that's fine. It's still illogical and inconsistent, because the behavior is different between SNAT and DNAT (and yes, that is actually true, at least that's what I see here on v18). 

  • 0 in reply to cryptochrome

    Updated my post above.  

    Client is always the session initiator. Hence we are using In for traffic going to the Session initiator in all perspectives, no matter if NAT or not. 

    Proved it via Screenshots. 

     

    XG act like it should act, always collecting the session initiator and summarize the traffic as IN to the initiator, and OUT coming from the initiator. 

     

    I assume there is nothing wrong with this way to deal with it. 

  • 0 in reply to LuCar Toni

    , 

    can you investigate on the issue inside?

  • +2 in reply to LuCar Toni

    You haven't proven anything other than not understanding, sorry. Client is NOT always the session initiator. You're factually wrong. And just because you always did it like this doesn't make it right. There are two other people in this thread who are as confused about this as I am.

    And yes, you are actually doing it differently when DNAT is applied. Here is my "prove". This is a firewall rule for access to the internet, where users predominantly download stuff from the internet (hence, they are the session initiators). The rule is subject to SNAT(MASQ). It correctly shows most data as incoming and only little data as outgoing, as expected:

    This is a firewall rule that has a corresponding DNAT rule. It shows that the server in the DMZ is sending very little data and it looks like the server is downloading a lot (IN), but it's actually the other way around, the server is SENDING a lot of data to people on the internet (who are the session initiators). The numbers are reversed:

    So there you have it, it is clearly and obviously different when DNAT is in place.

    Don't assume you are right. Consider you might be wrong. Other people in this thread agree.

     

  • 0 in reply to cryptochrome

    I cannot give more input than above.

    My Points are simply:

    V17.5 to V18 - No Changes in Firewall Rule handling regarding data count.

    In / Out will be tracked based on the Session Initiator (https://tools.ietf.org/html/rfc675).

    In is traffic going to the initiator, Out is traffic going to the session recipient. 

     

     

    It is a Term problem. Plex is the server, Clients are the initiator. You do not understand my point, which i try to explain. XG is showing you in Rule 9, the clients are getting 1.14 GB data. Clients are the session initiator, the Clients in the Internet. 

     

     

    Sorry  - I cannot do more than that.