Patrick McHardy wrote:
I don't know what correct fix is. Adding an extra call to xfrm4_policy_check
in
tcp_v4_rcv before the checksum check fixes this problem and doesn't seem to
break anything else. On the other hand, moving some of the code in
esp_post_input into esp_input (especially line 298)
On Fri, Feb 24, 2006 at 04:57:33AM +, Patrick McHardy wrote:
So we could move checksum validation behind xfrm4_policy_check or
already set ip_summed to CHECKSUM_UNNECESSARY in esp_input. Already
setting ip_summed in esp4_input looks easier. But this still leaves
Absolutely.
The only
Patrick McHardy wrote:
Chinh Nguyen wrote:
I discovered that the bug is in the function tcp_v4_rcv for kernel
2.6.16-rc1.
After the ESP packet is decapped and decrypted in xfrm4_rcv_encap_finish, the
unencrypted packet is pushed back through ip_local_deliver. For a UDP packet,
it
goes (back)
Chinh Nguyen wrote:
Patrick McHardy wrote:
What values does skb-ip_summed have before that?
the skb-ip_summed value before the checksum check in tcp_v4_rcv is
CHECKSUM_NONE. Hence tcp_v4_rcv checks its value, which is incorrect because
the
checksum is with regards to the private IP but
Patrick McHardy wrote:
Chinh Nguyen wrote:
Patrick McHardy wrote:
What values does skb-ip_summed have before that?
the skb-ip_summed value before the checksum check in tcp_v4_rcv is
CHECKSUM_NONE. Hence tcp_v4_rcv checks its value, which is incorrect because
the
checksum is with regards to
Chinh Nguyen wrote:
Patrick McHardy wrote:
Netfilter recalculates the checksum when NATing it.
The NATing is not done by netfilter but by the NAT device between the IPsec
peers.
I see, so the TCP checksum includes the wrong IPs.
[Linux ipsec client C] -- [NAT device] --
Chinh Nguyen wrote:
I discovered that the bug is in the function tcp_v4_rcv for kernel
2.6.16-rc1.
After the ESP packet is decapped and decrypted in xfrm4_rcv_encap_finish, the
unencrypted packet is pushed back through ip_local_deliver. For a UDP packet,
it
goes (back) to function
