Bad UDP Checksum from pfSense - DNS/NTP

elvisimprsntr

BACKGROUND

Been doing some packet capture to confirm DNS and NTP queries are working correctly. Observed "bad udp cksum" in the responses from pfSense. Not just random, but 100% of the time.

Seems this is not new, as I have read other forum posts with similar issues, but not seen root cause and resolution.

DNS QUERIES

    192.168.69.30.58152 > 192.168.69.5.53: [udp sum ok] 48017+ A? imap.gmail.com. (32)
04:42:34.367844 IP (tos 0x0, ttl 64, id 1706, offset 0, flags [none], proto UDP (17), length 126)
    192.168.69.5.53 > 192.168.69.30.58152: [bad udp cksum 0x0bf0 -> 0x49cc!] 48017 q: A? imap.gmail.com. 3/0/0 imap.gmail.com. CNAME gmail-imap.l.google.com., gmail-imap.l.google.com. A 173.194.213.108, gmail-imap.l.google.com. A 173.194.213.109 (98)
04:42:42.515095 IP (tos 0x0, ttl 255, id 6068, offset 0, flags [none], proto UDP (17), length 64)
    192.168.69.121.49891 > 192.168.69.5.53: [udp sum ok] 4381+ A? time-ios.apple.com. (36)
04:42:42.515262 IP (tos 0x0, ttl 64, id 45662, offset 0, flags [none], proto UDP (17), length 145)
    192.168.69.5.53 > 192.168.69.121.49891: [bad udp cksum 0x0c5e -> 0xb6ca!] 4381 q: A? time-ios.apple.com. 4/0/0 time-ios.apple.com. CNAME time-ios.g.aaplimg.com., time-ios.g.aaplimg.com. A 17.253.12.253, time-ios.g.aaplimg.com. A 17.253.6.125, time-ios.g.aaplimg.com. A 17.253.12.125 (117)
04:42:45.856588 IP (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto UDP (17), length 64)
    192.168.69.20.54609 > 192.168.69.5.53: [udp sum ok] 15676+ A? h30494.www3.hp.com. (36)
04:42:45.856709 IP (tos 0x0, ttl 64, id 52804, offset 0, flags [none], proto UDP (17), length 134)
    192.168.69.5.53 > 192.168.69.20.54609: [bad udp cksum 0x0bee -> 0x7c26!] 15676 NXDomain q: A? h30494.www3.hp.com. 0/1/0 ns: www3.hp.com. SOA txe01hpiibpe.ams.hp.net. hostmaster.hp.com. 443241637 3600 3600 2419200 900 (106)
04:42:46.716857 IP (tos 0x0, ttl 255, id 46091, offset 0, flags [none], proto UDP (17), length 70)
    192.168.69.35.50716 > 192.168.69.5.53: [udp sum ok] 35928+ A? gateway-carry.icloud.com. (42)
04:42:46.716982 IP (tos 0x0, ttl 64, id 45067, offset 0, flags [none], proto UDP (17), length 236)
    192.168.69.5.53 > 192.168.69.35.50716: [bad udp cksum 0x0c63 -> 0x5525!] 35928 q: A? gateway-carry.icloud.com. 9/0/0 gateway-carry.icloud.com. CNAME gateway.fe.apple-dns.net., gateway.fe.apple-dns.net. A 17.248.184.45, gateway.fe.apple-dns.net. A 17.248.137.117, gateway.fe.apple-dns.net. A 17.248.184.24, gateway.fe.apple-dns.net. A 17.248.137.115, gateway.fe.apple-dns.net. A 17.248.137.181, gateway.fe.apple-dns.net. A 17.248.137.74, gateway.fe.apple-dns.net. A 17.248.137.145, gateway.fe.apple-dns.net. A 17.248.137.182 (208)

NTP QUERIES

04:45:57.587151 IP (tos 0x0, ttl 60, id 41342, offset 0, flags [none], proto UDP (17), length 76)
    192.168.69.90.1500 > 192.168.69.5.123: [udp sum ok] NTPv1, length 48
	Client, Leap indicator:  (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
	Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
	  Reference Timestamp:  0.000000000
	  Originator Timestamp: 0.000000000
	  Receive Timestamp:    0.000000000
	  Transmit Timestamp:   0.000000000
	    Originator - Receive Timestamp:  0.000000000
	    Originator - Transmit Timestamp: 0.000000000
04:45:57.587266 IP (tos 0xb8, ttl 64, id 38523, offset 0, flags [none], proto UDP (17), length 76)
    192.168.69.5.123 > 192.168.69.90.1500: [bad udp cksum 0x0bfa -> 0x1b02!] NTPv1, length 48
	Server, Leap indicator:  (0), Stratum 2 (secondary reference), poll 3 (8s), precision -22
	Root Delay: 0.055801, Root dispersion: 0.024978, Reference-ID: 132.163.97.4
	  Reference Timestamp:  3748149234.580028217 (2018/10/10 04:33:54)
	  Originator Timestamp: 0.000000000
	  Receive Timestamp:    3748149957.587198825 (2018/10/10 04:45:57)
	  Transmit Timestamp:   3748149957.587239689 (2018/10/10 04:45:57)
	    Originator - Receive Timestamp:  3748149957.587198825 (2018/10/10 04:45:57)
	    Originator - Transmit Timestamp: 3748149957.587239689 (2018/10/10 04:45:57)

Derelict

That is perfectly normal if you have checksum offloading because the checksums are not calculated at the point the capture is taken. The NIC adds them on the way out.