Re: IPsec performance just 55% of WAN bandwidth

From: Walter Roberson (roberson_at_ibd.nrc-cnrc.gc.ca)
Date: 07/17/03


Date: 17 Jul 2003 18:37:12 GMT

In article <KCBRa.426$x32.35155@news.uswest.net>,
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
:getting black-holed.

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:
:ESP,3DES,HMAC,SHA1".

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!


Relevant Pages

  • Re: IPsec performance just 55% of WAN bandwidth
    ... It looks like pings with a payload larger than 1418 bytes are ... I do not know why 1000 exactly, and PIX offers no way to ... SHA-1 is used for the authentication, ... Are the pings going inside the tunnel or outside the tunnel? ...
    (comp.security.firewalls)
  • Re: [fw-wiz] Secure access to LAN resources (WAS: terminal services)
    ... > encrypted tunnel. ... VPN devices are designed to do strong authentication. ... It's always a trade-off between risk and protection. ...
    (Firewall-Wizards)
  • Re: [Edit] VPN pix 506 to 501 ...
    ... After, if that not resolve the problem, i will change the crypto map by ... > which tells the PIX to ignore the interface ACLs for tunnel traffic. ... unless you had turned that off with 'logging message'... ...
    (comp.dcom.sys.cisco)
  • PIX packets get NATed which shouldnt
    ... A PIX 501 Version 6.3 managing an IPSec tunnel to an ASA 5510 seems ... to to source NAT on outgoing packets which according to its config ... with its RFC1918 destination address the packet could never have ...
    (comp.dcom.sys.cisco)
  • Re: Cisco PIX VPN access-lists
    ... IPSec tunnel between a Cisco PIX and a Juniper SSG 20. ... Can you specify host and port access lists using that crypto map match ...
    (comp.dcom.sys.cisco)