VPN Lan-to-lan via Wireless Link

Discussion in 'Cisco' started by Elia Spadoni, Mar 23, 2008.

  1. Elia Spadoni

    Elia Spadoni Guest

    I have two sites, connected via a point-to-point link wireless.

    The real bandwidth is inferior to 10Mbps:

    Since the wireless devices that forms the bridge only support WEP 64/128/256
    I just planned to to a GRE+IPSEC (I have not been able to do straight ipsec
    tunnel) to connect the two links.

    I got MTU of 1500 on all devices, I could establish a cleartext wireless
    bridge and then run a VPN on it to encrypt the traffic of the two networks.

    SITE A:

    FIREWALL with 3 legs (one is the WAN link, LAN link, remote-site lan link
    via wi-fi)

    SITE B:

    wireless device (bridge)

    Since the WEP is insecure and quickly breakable, also it adds a lot of
    overhead to the wireless link, reducing bandwidth.
    I planned to do a DES/SHA vpn link running on the wireless link, also not to
    "destroy" the cpu of the router at the end of the links, or at maximum
    AES128 that is more cpu-friendly.

    Since the 3 legged firewall I wrote before on the site A could be a C2651XM
    or a C2650+NM4E or C3620 etc at the moment they dont have any crypto offload
    accellerator (that offloads des and 3des)

    The wireless link is used to share internet connection only., and rarely to
    transfer 650mb files from site a to site B.

    What are your suggestions?
    Elia Spadoni, Mar 23, 2008
    1. Advertisements

  2. Elia Spadoni

    stephen Guest


    you should reduce the MTU to limit fragmentation. i had a problem where a
    2811 topped out at around 3 Mbps in a similar setup, due to fragment
    the encryption b/w you need depends on the link capacity - but s/w
    encryption is a function of processor power.


    1800s / 2800s have built in encryption accelerators.
    stephen, Mar 23, 2008
    1. Advertisements

  3. Elia Spadoni

    Elia Spadoni Guest

    Here I am.

    I just made some read and I finally plan to use AES encryption:

    I will limit the capability of the remote lan (connecting to the HQ via the
    wi-fi link) to 1,2 Mbit up/down (I have at the HQ a 4mbit symmetric link)
    I don't bother the speed of the wireless link (real speed is around 10mbit ,
    but most is negotiated at 5,5mb)
    The remote lan just connect to the internets. The large downloads are
    committed from a server that is in the HQ (accessed by terminal server)
    Once the downloads are completed, they are transferred via the wireless link
    to the remote site (but it is not a daily operation).

    I will plan to use AES encryption on a cleartext wi-fi point-to-point

    this is the draft I plan to use on the router at both ends of the wifi link:
    crypto isakmp policy 2
    encr aes 256
    authentication pre-share
    group 5

    crypto ipsec transform-set VPN-AES256 esp-aes 256 esp-sha-hmac

    I think it is sufficient to guarantee security on the wifi link.
    To reduce overhead I would like to use "esp-null esh-sha-hmac"

    Any suggestions or opinion?
    Elia Spadoni, Mar 23, 2008
  4. Elia Spadoni

    Elia Spadoni Guest

    I plan to use MTU 1400 and MSS 1360 as I used in a different VPN over WAN
    I cannot buy new equipments, i just rely on 2600 routers...
    btw please read my newer post with the latest considerations.

    thanks for your attention :)

    best regards
    Elia Spadoni, Mar 23, 2008
  5. Elia Spadoni

    stephen Guest

    test the performance to see if the routers can handle the thruput you need.

    try the different encrpytion schemes to see if this is workth bothering

    something that is secure, but cripples the use of the link isnt likely to be
    popular no matter how much money you save....
    stephen, Mar 23, 2008
  6. Elia Spadoni

    Elia Spadoni Guest

    I have already tested this configuration (on a wan link)

    Site A:

    1280/512 ADSL LINK

    Site B:
    640/256 ADSL LINK

    using AES256 + esp-aes256 + sha1 and transferring at 500kbps average:

    C837 12F/48D 12.4(18) ADVSEC: 30~38 % constant cpu load.

    C2611 16F/64D 12.3(25) and tried 12.4(8) ADVSEC: 25~35 % constant cpu load
    (I also tested a C2650 32F/128D) and I reached maximum 20~25% cpu load on
    3DES, did not test AES on that but It will be lower cpu usage.

    I assume that doubling the throughput we could achieve theoretically: C837
    80% - 2611 75%


    On the Site A i will do the vpn probably on a C2650 or C2651XM or C3620 so
    the performance will increase a lot (all routers with max flash/dram)

    On site B I will use probably a C831 if I will use 3DES (hardware assisted)
    or AES (95% sure I will use AES)

    I will limit the throughput at 1,2mbit up/down for internet connectivity
    (going OUT) and will not limit for "remote lan connections INSIDE lan"
    Elia Spadoni, Mar 23, 2008
  7. Elia Spadoni

    News Reader Guest

    esp-null esh-sha-hmac?

    That's an ESP transform without cipher. I thought you wanted an
    encrypted tunnel to secure your traffic.

    Also, you have not stated a need for GRE other than the previous
    comment: "I have not been able to do straight ipsec
    tunnel". Perhaps you should address the issue, rather than avoiding it.

    GRE is going to place additional overhead on the tunnel due to the
    additional header. Furthermore, you would want to read up on GRE
    fragmentation issues, MTU requirements etc. IPSec and GRE handle
    fragmentation differently.

    Consider reading the Cisco document: Resolve IP Fragmentation, MTU, MSS,
    and PMTUD Issues with GRE and IPSEC

    Best regards,
    News Reader
    News Reader, Mar 23, 2008
  8. Elia Spadoni

    Elia Spadoni Guest

    I have not been able to use ipsec straight, because I established tunnel,
    ping the remote host, but surely I met frags..

    esp-null... well in the isakmp policy I already used encr aes 256

    is also needed in esp-aes 256 sha hmac?
    It is not already encrypted if I use encr aes 256 in the isakmp policy?
    Elia Spadoni, Mar 23, 2008
  9. Elia Spadoni

    News Reader Guest

    I'm a bit confused by your comments.

    You say you have "established tunnel", but don't indicate an issue.
    Furthermore, you don't specifically say whether the ping worked or did
    not work.

    Use commands like:

    sh crypto isakmp sa detail
    sh crypto ipsec sa detail

    .... to determine whether you have successfully established an ISAKMP SA,
    and IPSec SAs (i.e.: tunnel up or down).

    A ping may fail for a variety of reasons. The far side interface may be
    configured with "no ip unreachables". There may be issues with ACLs,
    NAT, etc. A failed ping does not necessarily mean your tunnel is not
    functioning as configured.

    IP packets vary in size. The only packets that will be fragment are
    those that exceed the Path MTU (smallest link MTU along the path). A
    simple ping is not a large packet (unless you configured it to be so),
    and would not be subject to fragmentation.

    Encryption policy is defined separately for ISAKMP (phase 1) and (IPSec
    phase 2).
    You want to use encryption during "both" phases.

    An example of ISAKMP encryption policy would be:

    crypto isakmp policy 1
    encr 3des

    An example of IPSec encryption policy would be:

    crypto ipsec transform-set site2site-3d esp-3des esp-sha-hmac

    crypto map site2site-cry-map 10 ipsec-isakmp
    set transform-set site2site-3d

    Best regards,
    News Reader
    News Reader, Mar 23, 2008
  10. Elia Spadoni

    Elia Spadoni Guest

    Oh sorry.

    I established an IPSec tunnel lan to lan, but it worked in a single
    direction, and have weird problems, pinged all hosts ok.

    When I did gre + ipsec, mtu 1400 and mss 1360 (as use now) everything works
    Elia Spadoni, Mar 23, 2008
  11. Elia Spadoni

    News Reader Guest

    Its been a while since I needed to addressed these issues.

    I'm using IPSec + GRE in ESP "Transport" mode between sites. When I
    researched these issues I concluded that changing the MSS was not
    required. An appropriate MTU on the Tunnel interface is all that is

    An MTU setting of 1440 should be sufficient for "Transport" mode, and
    1420 should be sufficient for "Tunnel" mode. The two modes have
    different protection boundaries. A packet is larger when sent in
    "Tunnel" mode due to encapsulation of the original IP header.

    I have used an MTU of 1400 for years, and have not encountered any
    fragmentation issues.

    interface Tunnel0
    ip mtu 1400

    When setting up a "non-GRE" IPSec tunnel between sites, you would want
    to be using an ESP transform in "Tunnel" mode.

    If you encountered issues in only one direction, you would want to
    review your crypto ACLs to be sure that they were mirrored, without any
    exceptions. A network sniffer on the WAN port is very useful in
    identifying asymmetric operation caused by non-mirrored crypto ACLs.

    Best regards,
    News Reader
    News Reader, Mar 23, 2008
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.