paul at xelerance.com
Wed Jan 4 18:03:22 CET 2006
On Wed, 4 Jan 2006, openswan wrote:
> I used Openswan 2.4.4 and kernel 184.108.40.206 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
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?
> 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?
> 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?
More information about the Users