Re: IPsec performance just 55% of WAN bandwidth
From: Walter Roberson (roberson_at_ibd.nrc-cnrc.gc.ca)
Date: 17 Jul 2003 18:37:12 GMT
In article <KCBRa.email@example.com>,
news.qwest.net <rmalayter--NOSPAM@bai.org> wrote:
:I thought it would be doing that correctly as well, but it seems that the
:sonicwall side isn't fragmenting packets correctly, even though I have it
:turned on. It looks like pings with a payload larger than 1418 bytes are
That doesn't necessarily prove anything. On the Cisco PIX, pings
of 1000 bytes or more are denied by the IDS subsystem as being a potential
attack. I do not know why 1000 exactly, and PIX offers no way to
adjust the boundary.
:I didn't think about the AH slowing things up. Perhaps SHA-1 is not
:accelerated by the hardware. That would pretty much explain things. I'll
:have to experiment with it. SHA-1 is used for the authentication, right? Or
:is it a 3DES-based MAC (we're using 3DES on the tunnel)? On my sonicwall
:side, the settings for the tunnel are "Strong Encrypt and Authenticate:
Sorry, I do not know what exactly that implies on the Sonicwall.
On the PIX, one specifies which component one is applying:
crypto ipsec transform-set vpn-3-transform ah-sha-hmac esp-3des esp-sha-hmac
So, SHA and HMAC can apply to both AH and ESP. esp-sha-hmac implies
authentication of the encapsulated esp payload, and ah-sha-hmac
implies authentication of the IP datagram -including- source and
destination IP headers and payload.
Generally speaking, if your sonicwall goes through the trouble of
hardware accelarating 3DES, -likely- the same hardware acceleration
applies to any SHA1 processing as well.
My hypothesis with respect to AH and latency was not meant at the level
of whether the SHA or HMAC was hardware accelarated or not: my
hypothesis was based upon issues of coordination of multiple received
packets in order to prove authentication and so on. I should have a
closer look at the specs to see how it all really works; there might
not be any technical grounding for my hypothesis.
:We're getting 13 ms
:average pings, pretty low. With a TCP window size of 17.5K, that still would
:allow for over 10 Mbps. I don't think that's an issue here.
Are the pings going inside the tunnel or outside the tunnel? If
they are going outside the tunnel, then the latency of performing
AH or ESP (and anti-replay and so on) could potentially be slowing
the VPN link to a much higher latency.
We are getting about 27.8 ms ping times through a VPN tunnel to
a remote PIX 501 that is connected by gigabit and OC-192 WAN links
and 100 Mbit LAN to us.
We are getting 4.7 ms ping times through a VPN tunnel to a local
PIX 501 that is connected through 100 Mb LAN links from our lab bench
to the logical outside of our network. The difference in throughput
between the two units is quite noticable.
-- Take care in opening this message: My grasp on reality may have shaken loose during transmission!