5

I would like some help in identifying a missing Packet in a TCP Stream.

My Scenario:

I have an Application Layer Firewall where I can filter specific Web sites and Applications.

When I access a simple Website from a Client with the IP 172.16.11.3/16 my Firewall will correctly identify the website I accessed.

When I change the IP address from this Client to 172.16.10.3/16 my Firewall will not identify the website anymore.

Please note that everything stays the same, the only difference is one octet in the IP.

In order to find the problem I did a packet capture on the Firewall and I can see that there is indeed a difference. From the non-working IP, I am missing one single TCP Packet in my sequence indifference to the working IP.

Following is a Screenshot of the problematic Packet being blue:

Wiresharp Capture

My assumption is that the Firewall is missing a Packet in the TCP Stream and can therefore not correctly identify the Application.

My Question: Can anyone tell me if my assumption is feasible and could anyone guess what could cause the TCP Stream to look different? My money is on a buggy Core Switch between Client and Firewall.

Edited to add:

  • I captured the traffic on the internal interface of the firewall before the firewall process even gets the traffic. Configuration or type of Firewall should not be relevant. On top of that, I can replicate this behavior on a different firewall which is connected to a mirror port.

  • Networktopo is pretty easy: Client 10.3 or 11.3 <- Client Network 172.16.0.0/16 -> L3 Core <- Transportnetwork 172.20.5.0/24 -> Firewall

  • Capture where logging is not working as intended and my Packet is missing: https://www.cloudshark.org/captures/8d271219db64

  • Capture where the traffic gets logged as intended: https://www.cloudshark.org/captures/960191af2a44

Improve this question
8
  • You don't provide nearly enough information. For instance, what model and software version is the firewall, and what is the configuration? You need to edit your question to add as much detail as possible.
    – Ron Maupin ♦
    Commented Oct 30, 2015 at 16:21
  • Unless everyone is complaining about very poor performance, it's very unlikely that its a switch problem -- especially if the scenario above is reproducible. My money is on the firewall config. But, as @RonMaupin says, we can't help you without more info.
    – Ron Trunk
    Commented Oct 30, 2015 at 17:23
  • You could improve your question by editing it to add more details. You may find our Question Checklist helpful when editing your question. For example: a network diagram, configurations and while screenshots are okay, the actual packet captures are better. A great place to share your packet captures would be CloudShark.
    – YLearn
    Commented Oct 30, 2015 at 20:21
  • 2
    What you capture may, or may not, have anything to do with the described problem. You want help, so you should provide the firewall model and configurations. For instance the change of address in the third octet is no big deal if the subnet mask is /16, but it can be a big deal if the subnet mask is a /24, and we can't know what may be slightly wrong. You can sanitize the configurations to remove, or change, any public addresses.
    – Ron Maupin ♦
    Commented Oct 30, 2015 at 21:16
  • The "missing" pakcet is just an ACK and the non-working capture provides the same ACK in the following GET request. Of more interest may be that you have a TCP retransmission in the working capture even though we see the ACK. Perhaps the ACKs are received but then not forwarded out of the firewall properly in the "working" example? Can you provide captures from the outside of the firewall as well? Also, the non-working example opens two TCP sessions with the server. Do you know why?
    – YLearn
    Commented Oct 30, 2015 at 21:19

2 Answers 2

Reset to default
2

Configuration or type of Firewall should not be relevant

Without having more information such as the hardware involved and their configs, my guess is that the fault is configuration related. Perhaps the two addresses are covered by two different rules. One which does a DNS lookup and one which doesn't.

As they say, the simplest answer is usually the right one.

Improve this answer
0

To answer your question (not the reason for the failure)

The packet count difference between the two captures doesn't mean something is wrong. Packet 10 in the first capture (103_chak..) is an ACK that's piggy-backed in another data packet. Packet 7 in the second capture (113_chak..) is just an empty ACK for previous received data.

The reason for the piggy-back in the first capture is that the HTTP GET (packet 10) is sent 20 ms after the received packet. In the second capture there is no piggy-backing because the HTTP GET is sent almost 2 seconds (very long time) after the received packet so an empty ACK is needed before that.

If you look at the last segments SEQ/ACK numbers in both captures, they are the same. Which means both sessions in the end of the day sent the same amount of data, just one session had an extra packet.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.