pfSense

IP packages that are routed through pfsense are reassambled, if incoming packages are fragments and the MTU of outgoing interface allows refragmentation to a higher MTU. In some cases the IP header checksum is calculated wrong:
- problems occure if packages are reassambled to exactly one package (e.g. IN: 1400+80 > OUT: 1480 ; or IN: 600+600+250 > OUT: 1450).
- problems do not occure if packages are reassambled to more then one outgoing package (e.g. IN: 1400+1400 > OUT: 1500+1300)
(i did some rounding of the package size for abstraction, in real there is also some overhead for source and destination IP, etc)

Setup for reproduction:
-----------------------

Machine A <> pfsense <> Machine B

- Machine A has set an MTU of 1400
- pfsense and Machine B use MTU of 1500

Steps for reproduction:
-----------------------
1.) ping from A to B (via GW pfsense) using IPv4: ping <ip of B> -s 1450
2 packages (Fragments) are received by pfsense (1400+50)
1 package leaves pfsense (1450) -> IP header checksum wrong; B drops package; no ICMP reply message
2.) ping from A to B (via GW pfsense) using IPv4: ping <ip of B> -s 1600
2 packages (Fragments) are received by pfsense (1400+200)
2 packages (Fragments) leave pfsense (1500+100) -> IP header checksums OK; B answers with ICMP reply

Some details that may be relevant:
- we use VLANs on all networks
- problem occurs indepent of underlying hardware (we use it on a DELL server and original netgate HW XG-7100)
- if we disable scrub, packages are not reassambled when passing through pfsense and no error occurs

Interesting observation:
- if header checksum is calculated wrongly, it is exactly 0x0100 higher than the checksum of the first incoming fragment. This leads me to the assumption that there is some logical bug in the implementation of header checksum calculation

I think the setup i quite easy so you can reproduce it, but if you need assistance don't hesitate to ask me