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?

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

  • 0 in reply to LuCar Toni

    LuCar Toni said:

    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. 

     

    But that is NOT what you are doing. If you think that's what you are doing, then we are actually looking at a bug. Because in my case, the firewall is not reporting the actual and factual directionality of the traffic based on session initiator. It's doing the opposite. 

    Also, nobody disputed that this behavoir has not changed from v17 to v18. 

Reply
  • 0 in reply to LuCar Toni

    LuCar Toni said:

    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. 

     

    But that is NOT what you are doing. If you think that's what you are doing, then we are actually looking at a bug. Because in my case, the firewall is not reporting the actual and factual directionality of the traffic based on session initiator. It's doing the opposite. 

    Also, nobody disputed that this behavoir has not changed from v17 to v18. 

Children
  • 0 in reply to cryptochrome

    Last try from my site. I am simply here to try to help to understand what is going on.

     

    https://support.plex.tv/articles/201543147-what-network-ports-do-i-need-to-allow-through-my-firewall/

     

    Your Mobile phone is building a connection to your XG Server, port 32400. 

    XG look up the NAT and Firewall Table to find a proper NAT and Firewall Rule.

    Assuming DNAT and the correct Firewall Rule (WAN to DMZ). 

    XG will forward the Syn Packet to the plex server port 32400.

     

    1.2.3.4:12345 -> WAN IP:32400 [S] 

    1.2.3.4:12345 -> Plex IP:32400 [S]

     

    Plex will respond with SYN/ACK.

    Plex IP:32400 -> 1.2.3.4:12345 [S.]

    WAN IP:32400 -> 1.2.3.4:12345 [S.]

     

    ACK from Device for Three-way Handshake.

    1.2.3.4:12345 -> WAN IP:32400 [.] 

    1.2.3.4:12345 -> Plex IP:32400 [.]

     

    Session established. 

    1.2.3.4 is the Initiator. 

    Plex IP is the Recipient. 

     

    All Devices have this connection mapped. XG, Mobile and Server. 

     

    Assuming the Client asking for a Movie, he pushes this little packet to the Server. 

    Lets say, those packets are 1 MB big in general. 

     

    1.2.3.4:12345 -> WAN IP:32400 [P. GIVE ME MOVIE] 

    1.2.3.4:12345 -> Plex IP:32400 [P. GIVE ME MOVIE] 

     

     

    Server is responding with the Movie. 

    Lets say, this Movie is 20 GB.

    Plex IP:32400 -> 1.2.3.4:12345 [P. MOVIE DATA BIG]

    WAN IP:32400 -> 1.2.3.4:12345 [P. MOVIE DATA BIG]

     

    Now XG is seeing this Traffic. 

    As mentioned earlier, we are using:

    IN for Traffic to the Initiator.

    OUT for Traffic to the Recipient. 

     

    The Firewall will now track:

    IN: [P. MOVIE DATA BIG] & [S.]

    OUT: [P. GIVE ME MOVIE]  & [S] & [.]

     



    Lets assume we take your other Rule for granted.

    LAN to WAN - ANY services. 

    Same construct like above is used.

     

    Your Client is trying to download a Windows Update.

    Client IP:12345 -> Microsoft IP:443 [S]

    WAN IP:12345 -> Microsoft IP:443 [S]

    Microsoft IP:443 -> WAN IP:12345 [S.]

    Microsoft IP:443 -> Client IP:12345 [S.]

    Client IP:12345 -> Microsoft IP:443 [.]

    WAN IP:12345 -> Microsoft IP:443 [.]

     

    Handshake done. 

     

    Client IP:12345 -> Microsoft IP:443 [P. Give me Update / Little Request]

    Microsoft IP:443 -> WAN IP:12345 [P. Update / Big Packets]

     

    Firewall Rule will now pick up:

    IN [P. Update / Big Packets] & [S.]

    OUT: [P. Give me Update / Little Request] & [S] & [S.]

     

     

     

  • 0 in reply to LuCar Toni

    As mentioned earlier, I completely understand how you do it, but I am saying it's wrong, because it does not reflect the actual traffic direction. Using IN when sending traffic TO the initiator is the problem. When you send someone out of your house, you are not saying you are letting him in, do you? Sophos XG does. 

    Using IN when sending data TO someone is just utterly illogical. 

    For what it's worth: I know basically every firewall vendor out there. Checkpoint, Fortinet, Palo Alto, Cisco, Juniper, you name it. They all do it the way I described. Only Sophos has to introduced their own weird concept that doesn't reflect reality. For reasons that are beyond me. 

    I give up. You insist on not understanding, and you insist on "Sophos is right", so it's pretty much pointless to argue with you. I would have wished that Sophos (who you seem to represent here) would take customer feedback more serious instead of just saying: We are right, because we have always done it like this, we are not considering your opinion, deal with it.