VPN Lan-to-lan via Wireless Link

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

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.

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 connection. GRE+IPSEC

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?

"stephen" ha scritto nel messaggio news:NwtFj.41481$ snipped-for-privacy@newsfe2-gui.ntli.net...

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

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

something that is secure, but cripples the use of the link isnt likely to be popular no matter how much money you save....

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

Site A:

1280/512 ADSL LINK C837

Site B:

640/256 ADSL LINK C2611

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%

BUT:

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"

"stephen" ha scritto nel messaggio news:gWvFj.17386$% snipped-for-privacy@newsfe3-gui.ntli.net...

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

Elia Spad> Here I am.

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?

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

Elia Spad> I have not been able to use ipsec straight, because I established tunnel,

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

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

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

Elia Spad> Oh sorry.

Hello sorry for reopening of this very old topic

but I have never solved my issue

I am not able to make a straight ipsec tunnel because i met frag problems for sure.

net A to net B pings everything, I can access a remote web page but not a RDP connection. From B to A all works perfect

"News Reader" ha scritto nel messaggio news: snipped-for-privacy@domain.null...

Add a ip tcp adjust-mss line to your tunnel interface, this will solve a lot of problems (that are really caused by blocking icmp somewhere)

The number after ip tcp adjust-mss should be 40-50 less than your mtu.