Basic IPSec Problem - Arrrgghhh - Page 2

john.pepper · ‎06-29-2004

Could anyone please help with this IPSec problem pls..?

Summary - 2 sites

==================

HQ site = 1721 vpn/k9 bundle - (192.168.1.0)

Remote site = 837 vpn/k9 - (192.168.2.0)

have configured Internet access which works fine but cannot get the site-to-site IPSec VPN active. Debug crypto isakmp output below which seems to indicate a problem with the pre-share authentication or keys.?

I have triple checked both of these but still no joy. the two sites don't seem to find a common policy but they are configured the same.. Desparate to get working by end of tomorrow..!!!

CENTRAL SITE CONFIG (1721)

==========================

!

crypto isakmp policy 1

hash md5

authentication pre-share

crypto isakmp key xxxxx address xx.xxx.xxx.xxx

!

crypto ipsec transform-set ans esp-des

!

crypto map anmap 1 ipsec-isakmp

set peer xx.xxx.xxx.xxx

set transform-set ans

match address 110

!

interface ATM0

no ip address

no ip mroute-cache

no atm ilmi-keepalive

pvc 0/38

encapsulation aal5mux ppp dialer

dialer pool-member 1

!

dsl operating-mode auto

hold-queue 224 in

!

interface FastEthernet0

description AN Supplies LAN

ip address 192.168.1.168 255.255.255.0

ip nat inside

ip tcp adjust-mss 1452

no ip mroute-cache

speed auto

hold-queue 100 out

!

interface Dialer1

ip address negotiated

ip mtu 1492

ip nat outside

encapsulation ppp

dialer pool 1

dialer-group 1

ppp chap hostname xxxxxxx

ppp chap password 0 xxxxxxx

crypto map anmap

!

ip nat inside source route-map nonat interface Dialer1 overload

ip classless

ip route 0.0.0.0 0.0.0.0 Dialer1

no ip http server

ip http authentication local

ip http secure-server

!

access-list 110 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

access-list 130 deny ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

access-list 130 permit ip 192.168.1.0 0.0.0.255 any

dialer-list 1 protocol ip permit

!

route-map nonat permit 10

match ip address 130

REMOTE SITE CONFIG (837)

==========================

!

crypto isakmp policy 1

hash md5

authentication pre-share

crypto isakmp key 0 xxxxx address xx.xxx.xxx.xx

!

crypto ipsec transform-set ans esp-des

!

crypto map anmap 1 ipsec-isakmp

set peer xx.xxx.xxx.xx

set transform-set ans

match address 110

!

interface Ethernet0

ip address 192.168.2.168 255.255.255.0

ip nat inside

ip tcp adjust-mss 1452

no ip mroute-cache

hold-queue 100 out

!

interface ATM0

no ip address

no ip mroute-cache

no atm ilmi-keepalive

pvc 0/38

encapsulation aal5mux ppp dialer

dialer pool-member 1

!

dsl operating-mode auto

hold-queue 224 in

!

interface Dialer1

ip address negotiated

ip mtu 1492

ip nat outside

encapsulation ppp

dialer pool 1

dialer-group 1

ppp chap hostname xxxxxxxxxxx

ppp chap password 7 xxxxxxxxxx

crypto map anmap

!

ip nat inside source route-map nonat interface Dialer1 overload

ip classless

ip route 0.0.0.0 0.0.0.0 Dialer1

ip http server

no ip http secure-server

!

access-list 110 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

access-list 130 deny ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

access-list 130 permit ip 192.168.2.0 0.0.0.255 any

dialer-list 1 protocol ip permit

route-map nonat permit 10

match ip address 130

!

end

Debugs to follows:

john.pepper · ‎07-06-2004

Hi,

both routers have 'static' Public IP addresses as the IPSec endpoints (peers) - these were puchased from our ISP and never change so that's not the problem.

The problem seems to be that the HQ router will not route packets through the tunnel unless it has a Static route pointing to the remote subnets (192.168.x.x) via the ISP 'next hop'. The next hop address is allocated by the ISP and binds itself to the Virtual-Access interace connected to the Dialer. You can only see this by issuing a 'show ip route' command.

The remote routers (837) seem to work ok with a default route via Dialer 1 - 0.0.0.0 0.0.0.0 dialer 1

I would like the same configuration for the HQ router (1721) but this doesn't seem to work.

Hope this helps..

Thanks,,,John

aacole · ‎07-06-2004

John,

I've just had a look at a config I used for a 1721, it uses a default route that points to the interface as the next hop. I'll try and find out what IOS the router is using, I dont have remote access so will have to make a phone call.

Andy

ryan.chapman · ‎07-06-2004

John,

I had the same problem with an 837<->2651 VPN I

recently configured. I was specifing the Dialer1

interface as the default next hop, but VPN traffic

never seemed to pass, as the next-hop address needed

to be added to the routing table from the routers

DHCP-client.

Try doing this (you may have to do it on both HQ and

site routers)...

=====================================================

! Remove the default route statement:

no ip route 0.0.0.0 0.0.0.0 Dialer1

! Tell the dhcp-client to make the next-hop distance 1

ip dhcp-client default-router distance 1

=====================================================

You may then need to reboot or issue "shutdown"

then "no shutdown" on the Dialer1 interface so that

the DHCP-client will renegotiate with the DSLAM.

If it doesn't work, please post a "show ip route"

from both routers.

Ryan

john.pepper · ‎07-07-2004

Ryan / Andy,

Both, thanks for your input..

* Ryan - I'll have to wait until a suitable time to try this as the customer is undergoing testing at the moment so I am unable to make any changes. However, I will try and test this in the next few days and let you know.

I assume this fixed your problem which seems similar to what I'm getting - did you get the ISP next hop address appear in the routing table after doing this.?

John

ryan.chapman · ‎07-07-2004

John,

When I removed the "ip route 0.0.0.0 0.0.0.0 Dialer1" statement, then the next-hop address then appeared in the routing table, but the distance was very high (250 I think), causing the route to not be preferred. This is why I had to insert the "ip dhcp-client default-route distance 1" statement

aacole · ‎07-07-2004

John,

The IOS used on the 1721 I set up with the route pointing out via dialer 1 is 12.2(11)T10

However its not running IPSec, its just a DSL connected link. I didnt have any routing issues caused by this statement whilst I was testing the link, its been in for about 5 months now.

Andy

john.pepper · ‎07-08-2004

Andy,

cheers for this information.

The only routing problem I have is with the IPSec stuff.. The DSL / PAT config works absolutely fine.. Users get translated from their respective Private address into the Public Static IP address provided by the ISP with no problems. The issue is purely the IPSec routing between the 192.168.x.x LAN's via the tunnel..

It seems a few other people have had issues with the 1700 router using IPSec and have swapped them out for an 800 and all works ok..

All the best....John

john.pepper · ‎07-22-2004

****** RESULT ****** CISCO PLEASE ADVISE *****

I finally got to the bottom of this problem when I came to do another IPSec VPN for another customer using a 1721 K9 VPN router (this is the one the on-board hardware encryption module).

The entire problem seems to be down to the Hardware Enryption Module..!!!!

If I disable this with the command:

no crypto engine accelerator

everything works fine with a simple Default route via the Dialer interface... If I turn it on again - inconsistent tunnel connectivity occurs (i.e the tunnel comes up, normally routes 'one' packet and then nothing else). Turn the Hardware Engine Accelerator OFF again and all works ok...

CISCO Guys - Is this an IOS problem..?

Both 1721 routers I've had this problem on were using IOS 12.3(2) XE

Should I open a TAC case or is this a known problem..?

Thanks for everyones input. I hope the above helps anyone else having this problem.

Cheers...John