Re: Problem with Ipsec transport mode over NAT

2006-02-25 Thread Herbert Xu
On Sat, Feb 25, 2006 at 07:51:06PM +0100, Patrick McHardy wrote: > > > I suppose you should treat CHECKSUM_UNNECESSARY as an indication that > > you need to recompute the checksum from scratch instead of adjusting > > it. So start by getting skb_checksum_help to only zap CHECKSUM_HW, > > and then

Re: Problem with Ipsec transport mode over NAT

2006-02-25 Thread Patrick McHardy
Herbert Xu wrote: > 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 >

Re: Problem with Ipsec transport mode over NAT

2006-02-24 Thread Herbert Xu
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

Re: Problem with Ipsec transport mode over NAT

2006-02-24 Thread Chinh Nguyen
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

Re: Problem with Ipsec transport mode over NAT

2006-02-23 Thread Patrick McHardy
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] -

Re: Problem with Ipsec transport mode over NAT

2006-02-23 Thread Chinh Nguyen
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 >>che

Re: Problem with Ipsec transport mode over NAT

2006-02-23 Thread Patrick McHardy
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 pri

Re: Problem with Ipsec transport mode over NAT

2006-02-23 Thread Chinh Nguyen
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, >

Re: Problem with Ipsec transport mode over NAT

2006-02-22 Thread Patrick McHardy
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 functio

Problem with Ipsec transport mode over NAT

2006-02-22 Thread Chinh Nguyen
I believe there is a bug with TCP traffic encrypted in Transport Mode over NAT (ie. UDP-encap ESP). I sent a message to the netfilter-devel list and someone suggested that I post to netdev. Here are my messages. Thanks. Original Message Subject: Understanding Netfilter and IPSe