[Openswan Users] Re: Tx Checksum Offload problem

[openswan]

Paul Wouters wrote:

>On Wed, 4 Jan 2006, openswan wrote:
>
>  
>
>>I used Openswan 2.4.4 and kernel 2.6.12.6 with KLIPS patch and
>>everything is ok. The clients that use this VPN connection are mostly
>>(WINDOWS 2000 Workstations and Linux Workstations). They have installed
>>ethernet cards 3COM 3c509 and VIA RHINE.
>>When I tried to activate "Tx checksum offload (Hardware Checksum)" on
>>these ethernet cards all packets that passed the Openswan (KLIPS) became
>>delayed or dropped (maybe with invalid Checksum!?). When I deactivate
>>this option i.e. the IP Stack to make the CHECKSUM everything is working
>>fine.
>>    
>>
>
>The cards cannot and should not rewrite ipsec packets. Any change will break
>the authenticity of the packet. IPsec protects against packet rewriting,
>whether it is done by the good or the bad guys.
>
>Depending on how this is implemented, it is a bug in the kernel (for giving
>the packets to the hardware) or the hardware (for changing packets it shouldn't)
>
>Note that I said "ipsec packets". I menat protocol 50 and 51. If we are
>talking about NAT-T poackets, eg ESPinUDP packets, then it should be
>possible to do hardware offloading of the outer UDP packet. What packets did
>you see this behaviour for?
>  
>
    The problem is in that the option "Tx Checksum Offload" is activated
only on the WORKSTATIONS i.e. the traffic there is unencrypted (IP
traffic). On the server where Openswan(+KLIPS) is installed this option
is not activated. I think that it shoud not influence who calculate the
"Checksum" in IP packets on the WORKSTATIONS because they are standart
IP packets that will be encapsulated in ESP protocol on the Openswan
server. According to my modest opinion the question is "Is there any
difference in IP packets coming from the WORKSTATIONS when the option
"Tx Checksum Offload" is activated and not activated". I think there is
because when "Tx Checksum Offload" is OFF the tunnel is working fine.
Maybe KLIPS cannot handle the packets coming from workstations with
activated option "Tx Checksum Offload"

>>Note: When the packets don't pass the Openswan(KLIPS) although the
>>option "Tx checksum offload (Hardware Checksum)" on clients is activated
>>packets are not delayed or dropped i.e. the problem is not in the kernel
>>code maybe.
>>    
>>
>
>But then they are also not encrypted, and ipsec does not come into play right?
>  
>
Yes absolutely then all traffic passes the Openswan server without
encryption and is not delayed or dropped. Only when the traffic passed
via the KLIPS  packets are getting dropped and delayed.

>  
>
>>Can you tell me is this a bug or a feature that's not supported by
>>Openswan and if there is the same problem if I use Native IPSEC not KLIPS?
>>    
>>
>
>I would expect the same result from NETKEY and KLIPS, though netkey might contain
>some code that tells the kernel to bypass offloading for these packets.
>
>Can you tell me how you enable/disable the offloading? Is it a compile time option
>for the driver or is it a runtime option we can see and possible set?
>  
>
 The  option "Tx Checksum Offload" is a runtime option. On Linux
workstations it can be activated using modprobe like this: modprobe
3c59x hw_checksums=1
 On Windows workstations it's also a runtime option located in "Device
Manager".
 

>Paul
>  
>
Nikolay