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?

> 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?

Paul
_______________________________________________
Dev mailing list
Devopenswan.org
http:/
/lists.openswan.org/mailman/listinfo/dev

> 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?

ethtool toggles various hardware and driver features
including hardware offloading.

-- 
Matthew Galgoci
GIS Production Operations
Red Hat, Inc
919.754.3700 x44155
_______________________________________________
Dev mailing list
Devopenswan.org
http:/
/lists.openswan.org/mailman/listinfo/dev

Jivin Paul Wouters lays it down ...
> 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?

We ship a lot of routers with RealTek 8139CP chips and they
do HW
checksumming.  It has never affected IPSEC to my knowledge.

The checksum is just the IP checksum and it doesn't matter
who
works it out it should be the same right ?

The 8139cp driver on input sets ip_summed to
CHECKSUM_UNNECESSARY if it has
ok'd the packet. It only calculates the checksum on output
if
ip_summed == CHECKSUM_HW.  If that helps at all ?  Perhaps
the
offloading is broken in those drivers ?  If it's not on by
default I
would ask why it's not on by default 

Not 100% sure I've tested a 2.6 + klips + openswan + hw
summing combination,
but I have definately tested it with 2.4,

Cheers,
Davidm

-- 
David McCullough, davidmcyberguard.com.au, Custom
Embedded Solutions + Security
Ph:+61 734352815 Fx:+61 738913630 http://www.uCdot.org http://www.cyberguard.com
_______________________________________________
Dev mailing list
Devopenswan.org
http:/
/lists.openswan.org/mailman/listinfo/dev

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
_______________________________________________
Dev mailing list
Devopenswan.org
http:/
/lists.openswan.org/mailman/listinfo/dev

On Thu, 5 Jan 2006, openswan wrote:

>    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).

Then "Tx Checksum Offload" is broken on those
workstations and MUST NOT be 
enabled while the station is connected to a IP based
network.

There should not be a single bit difference in transmitted
packets if 
hardware offload of Tx checksum is used or not. The
algorithm and packet 
details is in both cases identical.

If you find that there is differences in the transmitted
packets when Tx 
Checksum Offload is enabled/distabled then talk to the NIC
card wendor and 
driver maintainer to work these issues out if you wnat to
use the feature.

Regards
Henrik
_______________________________________________
Dev mailing list
Devopenswan.org
http:/
/lists.openswan.org/mailman/listinfo/dev