PDA

View Full Version : tcpdump not matching what my sniffer sees



tlmedia
2010-08-05, 09:51
I'm troubleshooting a problem about DiffServ packets getting stripped. I have a sniffer on my external switch, and mirrored my firewall port over to the sniffer. The sniffer sees the DiffServ field is blank.

But when I do a tcpdump on that same external interface, and use wireshark to look at the packets, I see the DiffServ info is there.

I was assuming CheckPoint is stripping DiffServ, but tcpdump seems to disagree.

Is tcpdump captured after all processing? Is it essentially what gets put on the wire?

Or is there a chance the firewall modifies the packet after tcpdump captured it?

Thanks

manuadoor
2010-08-05, 10:13
What I understand is, Traffic is moving towards outside from inside/dmz zone. And you can see Diffserv in the TCP dump and the same not in the Mirrored Ports?

Basically FW service runs after TCP Dump(when traffic inside to outside). What I suggest is, You can run TCP dump in inside interface and then run in the external interface, so that we can confirm that CP is stripping it.

inside<->(tcpdump)<->FW SERVICE<->(tcpdump)<->outside

Regards,

Manu B.
http://manuadoor.blogspot.com

tlmedia
2010-08-05, 10:32
Thanks Manu, that was a good tip.

Watching it from the outside interface confirms that the packets look correct.

So it must be my Cisco switch modify the QoS packets. I'll start looking there.

Thanks again..
TL

manuadoor
2010-08-08, 03:09
Thanks Manu, that was a good tip.

Watching it from the outside interface confirms that the packets look correct.

So it must be my Cisco switch modify the QoS packets. I'll start looking there.

Thanks again..
TL

:) happy to know that checkpoint is in safer side.. Once you resolved let me know what was the issue... :P

Petroman
2010-08-09, 05:33
Is tcpdump captured after all processing? Is it essentially what gets put on the wire?

Or is there a chance the firewall modifies the packet after tcpdump captured it?



tcpdump on the firewall may not show all packets if the software acellerator is on (Secure XL), since it shortcuts around parts of the IP stack.
If you turn off SecureXL it should show everything going to or coming from the network driver.
Thus on incoming you should see things before the firewall processes it.

Control SecureXL .

fwaccel off
fwaccel on
fwaccel stat

safe to use in production unless the load is high on the machine already.

- Petter

fdamstra
2010-08-26, 21:52
So it must be my Cisco switch modify the QoS packets. I'll start looking there
What model is the switch? I believe the higher-end/newer Cisco switches will discard DSCP unless you tell it to trust it. I don't know this with certainty, but if you're still experimenting with this, it might be worth adding:
mls qos
int Gi1/0/1
mls qos trust dscpwhere Gi1/0/1 is the interface that the firewall is connected to. Without this, I believe a L3 capable switch will discard the DSCP values.

Or, if you'd rather, you can use 'mls qos trust cos' to trust the 802.1p values, which the switch will map to new DSCP values.

My confidence on this is at about 45%, so I'd love to hear what you find out.

PeterN
2011-09-26, 06:03
I believe a L3 capable switch will discard the DSCP values.

Or, if you'd rather, you can use 'mls qos trust cos' to trust the 802.1p values, which the switch will map to new DSCP values.

My confidence on this is at about 45%, so I'd love to hear what you find out.

Yep it will probably discard the DSCP(diffserv) values if you don't trust it. CoS is only applicable if its a trunk (layer2) , ToS is layer3 and I assume you saw ToS values in the ip header when you used tcpdump.

/P

Edit: tcpdump -v -n -i interface ip and ip[1]!=0