PfSense causing bad IP Header checksums
-
The only time I had problems with checksums on ALIX were when I had a wireless interface bridged to LAN, and in that case it resulted in no traffic passing at all, not lost packets.
It may still help. It doesn't hurt to disable checksums and try it, see if it makes things better.
-
The only time I had problems with checksums on ALIX were when I had a wireless interface bridged to LAN, and in that case it resulted in no traffic passing at all, not lost packets.
It may still help. It doesn't hurt to disable checksums and try it, see if it makes things better.
Yes, I did disable checksums with the same corrupt results as before. So that doesn't seem to be the cause.
-
Do you get the bad checksums for TCP traffic too? If so, I would expect to see retransmissions from the other end, due to the TCP segments being discarded.
-
Its interesting that the bad checksums are zero. Is this also true of a larger sample?
With support for hardware checksum offloading I would expect that on transmission of a routed packet the IP header checksum might be set to 0 with the device driver to take responsibility for calculating the IP header checksum (either offloaded to hardware or calculated in software). If checksum is calculated by hardware the packet capture might always show a bad checksum. If checksum is calculated by software and packet capture is done before the checksum is updated in the packet then packet capture will always show a bad checksum. (And this could be driver specific!) This is just speculation because I haven't checked the sources.
Have you checked for reported checksum errors in any of the end systems involved in this conversation?
Do you see the bad checksums in RECEIVED packets on the WAN interface? (You don't see them on received packets on the LAN interface.)
Have you checked the protocol error counters on the LAN system in the VOIP conversations? On a FreeBSD system the shell commands systat -tcp and systat -ip can be used to watch the change in the protocol counters.
-
good point, wallaby.
-
I seem to have bad checksums for all traffic, but not ALL traffic, just quite a bit.
Also, its ONLY happening when the traffic goes THROUGH the firewall. If I do a capture on the LAN side, all traffic heading to the outside world is fine. If I do a WAN capture, all internet traffic into our LAN is fine. Once it traverses the firewall is where the checksums become bad.
What is interesting is that in 1.2.2 I disabled the hardware checksum offloading and continued to have the bad checksums. But at another clients with 1.2.3 RELEASE I disabled the hardware checksum, and the bad checksums mostly went away.
Before this conversation, I have NOT checked for checksum errors.
The PBX is a linux box, and the phones are mostly Polycom 501's. I have not checked for protocol error counters.
-
Well, this makes sense, since the firewall is regenerating the packets as it forwards them. If a packet received has a bad IP checksum, it should be discarded, so the only traffic to transit thru the firewall should be one with a good checksum.
-
Well, this makes sense, since the firewall is regenerating the packets as it forwards them. If a packet received has a bad IP checksum, it should be discarded, so the only traffic to transit thru the firewall should be one with a good checksum.
All the packets it receives have good checksums. pfSense is writing the bad checksums and sending them along. I think the pfSense might be the problem with my poor voip quality.
I need to update the the 1.2.2 to 1.2.3 and disable the checksum feature in the pfSense to see if it makes a difference. I wont be able to do that until after the new year.
-
All the packets it receives have good checksums. pfSense is writing the bad checksums and sending them along.
In an earlier reply I tried to suggest the possibility that packet capture of transmitted packets might not show exactly what is transmitted on the wire. Before concluding that pfSense is corrupting the checksums on packets it forwards (if pfSense was routinely doing this I'm sure there would be a lot more complaints) I think it would be good to get confirming evidence, say from the protocol error counters on the PBX or from a tcpdump trace on the PBX or a protocol analyser.
The other thing I think you should check is that you really did turn off checksum unloading. I believe it is not sufficient to just tick the box, I think the save button below the box needs to clicked on to activate the changed setting.
-
All the packets it receives have good checksums. pfSense is writing the bad checksums and sending them along.
In an earlier reply I tried to suggest the possibility that packet capture of transmitted packets might not show exactly what is transmitted on the wire. Before concluding that pfSense is corrupting the checksums on packets it forwards (if pfSense was routinely doing this I'm sure there would be a lot more complaints) I think it would be good to get confirming evidence, say from the protocol error counters on the PBX or from a tcpdump trace on the PBX or a protocol analyser.
The other thing I think you should check is that you really did turn off checksum unloading. I believe it is not sufficient to just tick the box, I think the save button below the box needs to clicked on to activate the changed setting.
I was able to do a tcpdump on the pbx (tcpdump -s 1500 -nl not port 22 -w wireshark.cap) and look at the file with wireshark. I did NOT see any checksum errors when doing this.
It seems that the packet capture on pfsense is capturing before writing back to the wire, so your not seeing the the truth. I'm just surprised that more people did not mention this was the case.
As for making sure turning off checksums, yes, I not only checked the box, but also clicked the save button.
-
I had similar checksum errors early on when I first started using voip through my pfsense box. In my case it turned out to be what I thought to be an apparent faulty nic. (Realtech- I know I know… I see now...) Since replacing the nic, my voip systems have been rock solid. And no more errors.
May not be related but I figured Id mention it...