IPSec tunnel is breaking http managment session to printers

[gschertz]

Both remotes connect to the hub via frame-relay. No direct dlci map remote to remote. But data communications work through the Hub. At this time I am only encrypting data communications from lan to lan and not encrypting communications router to router. So all traffic generated on a lan segment and destined for the hub or other remote lan is encrypted.

The symptoms I am seeing. Ping, telnet, traceroute. all work fine. www access to the Internet works fine. But from remote 2 and using a web browser ( current updates done) http:// ip address of printer at remote 1, the http managment session times out or never properly opens. The same happens in reverse a http manament session from remote 1 to remote 2 printer web interface the page will not open or sometimes will just hang. telnet works from both directions to a telnet managment session. This works great.

Also Apple remote desktop does not work, the status bar never moves the session starts then just never proceeds.

When I turn off IPSec all of these problems go away. http managment sessions work in both directions. So does apple remote.

From another remote off of the hub location, http managment sessions work great. so it appears that the issue is between remote 1 and remote 2.

I dont have apple remote at remote x.

remotex-<------hub-------remote 1

\-----hub--------remote 2

Basic setup. remote 1-----HUB------ remote 2

remote 1 IP

lan 10.33.29.1/24

wan 10.33.129.2/24

remote 2

lan 10.33.127.1/24

wan 10.33.128.2/24

Hub

lan 10.1.1.1/24

wan 1 10.33.129.1/24

wan 2 10.33.128.1/24

remote 1 IPSec settings

crypto isakmp policy 20

encr 3des

authentication pre-share

group 2

crypto isakmp key xxxxxx address 10.33.129.1

crypto ipsec transform-set 20 esp-3des esp-sha-hmac

crypto map may 10 ipsec-isakmp

set peer 10.33.129.1

set transform-set 20

match address 110

access-list 110 permit ip 10.33.29.0 0.0.0.255 10.33.127.0 0.0.0.255

access-list 110 permit ip 10.33.29.0 0.0.0.255 10.1.1.0 0.0.0.255

remote 2 IPSec settings

crypto isakmp policy 20

encr 3des

authentication pre-share

group 2

crypto isakmp key xxxxxx address 10.33.128.1

crypto ipsec transform-set 20 esp-3des esp-sha-hmac

crypto map may 10 ipsec-isakmp

set peer 10.33.128.1

set transform-set 20

match address 110

access-list 110 permit ip 10.33.127.0 0.0.0.255 10.33.29.0 0.0.0.255

access-list 110 permit ip 10.33.127.0 0.0.0.255 10.1.1.0 0.0.0.255

HUB IPSec settings

crypto isakmp policy 20

encr 3des

authentication pre-share

group 2

crypto isakmp key xxxxxx address 10.33.129.2

crypto isakmp key xxxxxx address 10.33.128.2

crypto ipsec transform-set 20 esp-3des esp-sha-hmac

crypto map may 10 ipsec-isakmp

set peer 10.33.129.2

set transform-set 20

match address 110

crypto map may 11 ipsec-isakmp

set peer 10.33.128.2

set transform-set 20

match address 111

access-list 110 permit ip 10.1.1.0 0.0.0.255 10.33.29.0 0.0.0.255

access-list 110 permit ip 10.33.127.0 0.0.0.255 10.33.29.0 0.0.0.255

access-list 111 permit ip 10.1.1.0 0.0.0.255 10.33.127.0 0.0.0.255

access-list 111 permit ip 10.33.29.0 0.0.0.255 10.33.127.0 0.0.0.255

Can anyone give me an Idea as to why only the http managment sessions will not work? Internet access is through the hub and that works fine.

[s-doyle]

Did you try any debugs, did you get any error messages?

[rmihalcin]

gschertz,

Two ways to solve your problem. The crypto maps are

causing the sporatic outages. Some traffic is considered interesting while return traffic is not. Anyway DMVPN is one way to solve the problem. The other is to build a "full mesh" to all peers. Obviously, you only have 2 physical links but the spoke routers will send the traffic down the physical link.

Do a show access-lists and see if all the access lists have hits on them. Also I would run a dynamic

routing protocol to keep the ipsec tunnels up all the time.

Hope that helps.

Bob

[mrueckbr]

I think a GRE Tunnel environment would solve the problem.

Configure a GRE-Tunnel from the spokes to the hub and enable ospf on it.

Set the "ip tcp adjust-mss 1300" on the tunnel interface and your problem is solved.

I think http to the internet is working because you are using a proxy-server in the hub.

[gschertz]

Hey thanks all. I do appreicate the feed back.

I linaly found the problem. The IOS has a bug! It has to do with packets that are close to the MTU. When they are the decrpting end does not put the packets back in the right order. I used the command crytpo ipsec fragment-after encryption and Yahoooooo. Problem solved. I am going to upgrade the IOS to fix the bug.\

Thanks all