broken TCP checksums with IPv6 and route-to/reply-to on gif interfaces
TCP checksums on IPv6 traffic matching rules specifying route-to or reply-to end up with broken TCP checksums. Every packet from a given system has the same wrong TCP checksum. Change the IPv6 source IP and the checksum it uses changes, and still stays the same across all packets.
The issue doesn't exist in stock FreeBSD 10-STABLE.
It is at least somewhat hardware-specific. In VMware ESX, vmxnet3 doesn't exhibit the issue, but e1000 does. All physical hardware seems to be affected (RCC-VE, APU, and more).
Example on 172.27.44.174. 'ping6 google.com' works, 'fetch -6 http://google.com' fails. Take out the route-to from the rule:
pass out route-to ( ... ) inet6 from ... keep state allow-opts label "let out anything from firewall host itself"
and it works.
#1 Updated by Chris Buechler over 3 years ago
Appears 290161 needs MFCed.
#5 Updated by Jim Pingle over 3 years ago
- Status changed from Feedback to Confirmed
- Assignee changed from Chris Buechler to Luiz Souza
There is still a problem here. It works for traffic from the firewall itself but not for traffic flowing through that hits a route-to when it enters the firewall.
For example, TCP connection enters LAN, hits a policy routing rule with route-to, exits a V6 WAN. No state is created when it exits the V6 WAN, so the SYN+ACK is denied re-entry. Remove the policy routing from the LAN rule then repeat the test and the state is created, traffic flows as expected.
#6 Updated by Chris Buechler over 3 years ago
- Subject changed from broken TCP checksums with IPv6 and route-to/reply-to to broken TCP checksums with IPv6 and route-to/reply-to on gif interfaces
The original issue is still applicable with gif interfaces, they have the same broken checksum on every TCP packet. It's fixed on every non-gif scenario I've tried.
The issue JimP noted above is separate, opened #5424 for that.
#7 Updated by Chris Buechler over 3 years ago
- Status changed from Confirmed to Feedback
this looks to have fixed the remainder of this issue.
Renato/Luiz, FYI: I just pulled in some patches on that commit and https://github.com/pfsense/FreeBSD-src/commit/fcb1a35e91beb27cdb14eeeff3aab781c0a9671c that jimt pointed out might be related so we could get snapshots to test with. Probably going to want to revert those when syncing up with FreeBSD.