Basic IPSec Problem - Arrrgghhh

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 · ‎06-29-2004

Debug crypto isakmp on REMOTE router

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

03:32:00: ISAKMP (0:0): received packet from xx.xxx.xxx.xx dport 500 sport 500 G

lobal (N) NEW SA

03:32:00: ISAKMP: local port 500, remote port 500

03:32:00: ISAKMP: Find a dup sa in the avl tree during calling isadb_insert sa =

816DDFD4

03:32:00: ISAKMP (0:2): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH

03:32:00: ISAKMP (0:2): Old State = IKE_READY New State = IKE_R_MM1

03:32:00: ISAKMP (0:2): processing SA payload. message ID = 0

03:32:00: ISAKMP (0:2): processing vendor id payload

03:32:00: ISAKMP (0:2): vendor ID seems Unity/DPD but major 157 mismatch

03:32:00: ISAKMP (0:2): vendor ID is NAT-T v3

03:32:00: ISAKMP (0:2): processing vendor id payload

03:32:00: ISAKMP (0:2): vendor ID seems Unity/DPD but major 123 mismatch

03:32:00: ISAKMP (0:2): vendor ID is NAT-T v2

03:32:00: ISAKMP: Looking for a matching key for xx.xxx.xxx.xx in default

03:32:00: ISAKMP (0:2): No pre-shared key with xx.xxx.xxx.xx!

03:32:00: ISAKMP : Scanning profiles for xauth ...

03:32:00: ISAKMP (0:2): Checking ISAKMP transform 1 against priority 1 policy

03:32:00: ISAKMP: encryption DES-CBC

03:32:00: ISAKMP: hash MD5

03:32:00: ISAKMP: default group 1

03:32:00: ISAKMP: auth pre-share

03:32:00: ISAKMP: life type in seconds

03:32:00: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80

03:32:00: ISAKMP (0:2): Preshared authentication offered but does not match poli

cy!

03:32:00: ISAKMP (0:2): atts are not acceptable. Next payload is 0

03:32:00: ISAKMP (0:2): Checking ISAKMP transform 1 against priority 65535 polic

y

03:32:00: ISAKMP: encryption DES-CBC

03:32:00: ISAKMP: hash MD5

03:32:00: ISAKMP: default group 1

03:32:00: ISAKMP: auth pre-share

03:32:00: ISAKMP: life type in seconds

03:32:00: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80

03:32:00: ISAKMP (0:2): Hash algorithm offered does not match policy! 03:32:00: ISAKMP (0:2): atts are not acceptable. Next payload is 0

03:32:00: ISAKMP (0:2): no offers accepted!

03:32:00: ISAKMP (0:2): phase 1 SA policy not acceptable! (local 80.176.243.241

remote xx.xxx.xxx.xx)

Message on Central router is as follows:

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

%CRYPTO-4-IKMP_BAD_MESSAGE: IKE message from xx.xxx.xxx.xx

1 failed its sanity check or is malformed

jeff.bankston · ‎06-29-2004

I just got done designing and engineering a new ipsec solution for one of my customers along these lines, here's some tips for you.

1. make sure your mtu settings don't cause ipsec negotiations to fail by exceeding the mtu on the dsl lines before ipsec can negotiate. Try letting them run at default settings first.

2. You need to exclude your WAN IP addresses from the ipsec process so the wan IPs can find one another

3. don't forget to add static routes on each end to point to the other across the dialer

4. your config indicates you're using extended authentication - make sure your user names and passwords match on each end, and that your AAA setup for this matches the network access permissions

5. did you ping each end before ipsec comes up? i take it they're reachable.

Hope this helps.

-Jeff

john.pepper · ‎06-29-2004

Jeff,

Thanks for you tips. In answer to your questions:

1. The mtu adjustments I made were taken from other configs which I assumed were correct as follows:

interface FastEthernet0

ip tcp adjust-mss 1452

interface Dialer1

ip mtu 1492

I'll try these back to the defaults & test.

2. The WAN IP addresses are provided by the ISP and are Public addresses. The Crypto ACL on looks at 192.168.1.0 & 192.168.2.0 so shouldn't be processed by this ACL.

3. Static routes - both routers have a default route via Dialer 1 = ip route 0.0.0.0 0.0.0.0 Dialer1

4. Extended Auth - The IPSec config I'm using worked on a previous router. I don't see how the usernames & passwords are relevant. Am I missing something..?

5. Both routers can Ping each other (public) addresses without using IPSec

Any further tips would be a help. Cheers...John

john.pepper · ‎06-29-2004

Fixed my own problem here...!!!!

It appears (after reading many Cisco docs), that you need to have a specific static route in the routing table for the site-to-site VPN to work. Putting a default route (e.g. ip route 0.0.0.0 0.0.0.0 Dialer1 ) is not sufficient, you need to have a qualified route via your ISP's next hop router..

I managed to find this by doing a simple 'show ip route' and you can see a second IP address directly connected to Dialer 1.

I then added the following static route fro the remote site:

ip route 192.168.2.0 255.255.255.0 xx.xx.xxx.142 (isp router)

I then clear the crypto sa and restarted a ping and BINGO....

Now we have what we want - Internet access with internal devices NAT/PAT'd to Public ISP address and site-to-site VPN using Private addressing...

Hope this helps anyone else implementing this type of solution...

Cheers....John

john.pepper · ‎06-30-2004

It appears I was a bit quick saying I had a fix to this probelm...

All works ok while the router is 'up' and the IPS next hop router address is in the routing table and we have a route to it.. But when the router is rebooted we get a different next hop router IP address allocated by the ISP and the IPSec tunnel doesn't work... Have tried making the Static route point at Dialer 1 but this doesn't seem to make any difference - the tunnel will still not come up..

The ISP say they cannot speify the next hop IP address as it will change every time the router/ADSL circuit is negotiated..

Any suggestions welcome..?

aacole · ‎06-30-2004

John,

I dont see any way that you can reliably set this up. Both client and site to site VPN's both need at least one end to have a static address, so that the peer knows what address to connect to. The configurations you posted both have negotiated addresses on the DSL links.

You can use wildcard IP addresses in the pre-shared keys, but I dont see that helping any here, as which ever site has to establish the VPN has to know the IP address of the peer its to connect to. Also the Terminal Endpoint Discovery (TED) feature wont help either.

Andy

john.pepper · ‎06-30-2004

Andy,

thanks for your reply.

The IP address being allocated by the ISP is 'static' in as much that the ISP issues the same IP address to my Dialer interface everytime. Whilst this isn't ideal it does allow me to be sure that my IPsec Peer address is 'known' and consistent everytime. However, the ISP gateway IP address (next hop away from my router) is negotiated via the Dialer virtual-access interface (Vi2) and changes everytime the interface or router is restarted,

If I specify a static route to my remote site via this next hop - e.g. 192.168.2.0 255.255.255.0 via ISP router, I get a established vpn tunnel and can Ping between 192.168.0.0 networks. However, if I specify the same route via the Dialer interface (as I never know what next hop the ISP is going to give me) the vpn tunnel establishes (sometimes with a single ping response) but is unable to route any traffic and pings time-out.

The Peers seem to have a session established by no traffic routes between them. As I say, if I change the route to point at the ISP next hop router, all works ok...

Cheers for you input.....John

aacole · ‎07-02-2004

John,

Have just done this for a PIX customer a year or so ago, so I was suprised to find out that a similar feature for IOS has only just been introduced.

Have a look at this URL, describes a solution to the problem you are seeing:

http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a008022ad0a.html

As for the PC not sending traffic over the VPN, that is normally a routing problem within the host, have you set the host default gateway to the inside address of the router?

If you have, do the hosts have any other routes pointing to the remote network?

Andy

john.pepper · ‎07-02-2004

Andy,

thanks for this link..

Still investigating - I'll let you know

John

jcharur · ‎07-01-2004

What ISO version do you have running between

john.pepper · ‎07-01-2004

12.2(7r)XM2 - on the 1721

can't get onto the 837 at the moment but I think this was alos 12.2 - is there a probelem with this version of IOS..

My problem now is that I can establish a tunnel and ping between the routers (using and extended ping specifying the relevant LAN interface as the source). I can see the packets being encrypted & decrypted using the 'show crypto ipsec sa' - however, when I try a ping ffrom a connected pc on the 192.168.1.0 LAN (.10 address) I get nothing..

the ACL's show the packets going through them but the other end doesn't increment / decrement on either the ACL's or the 'show crypto ipsec sa'

Cheers for your input...

forsudhaji · ‎07-05-2004

Can u try applying crypto map to the Ethernet interfaces(at both ends - in 1721 and in 837), from where the traffic originates and check this..

Pls let me know

john.pepper · ‎07-05-2004

Hi there,

Thanks for your tip - unfortunately, I'm not in a position to change anything at the moment as the customer is testing tomorrow and everything seems to work by adding the static routes to the Private networks on the HQ router (1721).

Do you mean add the crypto map to the Ethernet interfaces as well as the Dialer interfaces or just the Ethernet,.? Do you have some experience of this problem.?

Just to summarise my problem:

1. By configuring just a Default route on the HQ router (1721) as follows: 0.0.0.0 0.0.0.0 dialer 1

The IPSec tunnel establishes but only routes 'one' packet from a Ping. You can see the tunnel is up but no traffic will route. Also, once this error occurs the only way to clear it is to add a Static route to the remote networks and reboot - adding the route(s) on their own and clearing the routing / arp table doesn't seem to be enough, it only works with a reboot. These are the routes I add to my remote Private networks:

192.168.2.0 0.0.0.255 xxx.xxx.xxx.xxx (ISP next hop)

192.168.3.0 0.0.0.255 xxx.xxx.xxx.xxx (ISP next hop)

etc. etc.

Obviously the problem here is that the ISP next hop router address is negotiated by the Virtual-Access interface bound to the Dialer and 'changes' evry time you reboot the router. My workaround has been to reboot the router multiple times and see how many different next hop IP addresses my router gets. By doing this I found that I consistantly get one of 3 differrent next hop addresses. Therefore, I have added static routes for each next hop and this seems to work... Not really ideal but I needed a fix ASAP.

It seems the 837 routers work happily with just the Default route via the Dialer. The above Static routes only need to be applied to the 1721 HQ router.

* Note - Also, I incorrectly stated the wrong IOS versions in a previous message.

For clarity the IOS versions I am using are as follows:

1721 - 12.3(2) XE

837 - 12.3(2) XC2

John

forsudhaji · ‎07-05-2004

Hi John..if both HQ and remote locations are getting dynamic IP from ISP, then what do u specify at both ends as IPSec peer IP's. IPSec peer end IP's should always be reachable for the end to end tunnel to be up. Are u specifying 192.168.2.x at HQ and 1.x at Remote?

If yes, is ur ISP routing the pvt IP's?

Pls let me know..