ACL Problem

[rodonohu1]

Hi Guys,

My issues is this:

I have a home office router and a core router. The following is the config. I'm using crypto maps to create it. But there seems to be an issue with the ACLS. I can ping both public IP address but after that, nothing. Any help is great. Any good ACL troubleshooting methods?

Main Router to Home office Router:

crypto isakmp policy 1

authentication pre-share

group 2

lifetime 3600

crypto isakmp key RODONOHU-VPN address 213.94.219.249

crypto ipsec transform-set 60GMAC esp-3des esp-md5-hmac

crypto map COGENT_VPN 60 ipsec-isakmp

description RODONOHU-HOME-TEST

set peer 213.94.219.249

set transform-set 60GMAC

match address RODONOHUE_HOME

ip route 172.17.25.16 255.255.255.240 66.28.244.17 name RobODonohueHomeTest

ip route 213.94.219.249 255.255.255.255 66.28.244.17 name RODONOHU-TUNNEL

ip access-list extended RODONOHUE_HOME

permit ip host 66.28.244.18 host 213.94.219.249

permit ip 172.16.0.0 0.0.255.255 172.17.25.16 0.0.0.15

permit ip 172.17.0.0 0.0.255.255 172.17.25.16 0.0.0.15

permit ip 192.168.0.0 0.0.255.255 172.17.25.16 0.0.0.15

permit ip 192.206.209.0 0.0.0.255 172.17.25.16 0.0.0.15

deny ip any any log

Home Office Router

crypto isakmp policy 1

encr 3des

hash md5

authentication pre-share

group 2

lifetime 3600

crypto isakmp key RODONOHU-VPN address 66.28.244.18

crypto ipsec transform-set 60GMAC esp-3des esp-md5-hmac

!

crypto map COGENT_VPN 60 ipsec-isakmp

set peer 66.28.244.18

set transform-set 60GMAC

match address Crypto_ACL

ip route 0.0.0.0 0.0.0.0 Dialer1

ip access-list extended Crypto_ACL

permit ip host 213.94.219.249 host 66.28.244.18

permit ip 172.17.25.16 0.0.0.15 172.16.0.0 0.0.255.255

permit ip 172.17.25.16 0.0.0.15 172.17.0.0 0.0.255.255

permit ip 172.17.25.16 0.0.0.15 192.168.0.0 0.0.255.255

permit ip 172.17.25.16 0.0.0.15 192.206.209.0 0.0.0.255

permit ip host 213.94.219.249 host 66.28.244.17

[rodonohu1]

Anyone have a look at the updated info i supplied for this issue? It seems to be an issue with the Crypto map not saying up.

See Below:

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 66.28.244.18, timeout is 2 seconds:

Feb 2 08:03:51.203: ISAKMP: received ke message (1/1)

Feb 2 08:03:51.203: ISAKMP: set new node 0 to QM_IDLE

Feb 2 08:03:51.203: ISAKMP (0:1): sitting IDLE. Starting QM immediately (QM_IDLE )

Feb 2 08:03:51.203: ISAKMP (0:1): beginning Quick Mode exchange, M-ID of -572399601

Feb 2 08:03:51.215: ISAKMP (0:1): sending packet to 66.28.244.18 my_port 500 peer_port 500 (I) QM_IDLE

Feb 2 08:03:51.215: ISAKMP (0:1): Node -572399601, Input = IKE_MESG_INTERNAL, IKE_INIT_QM

Feb 2 08:03:51.215: ISAKMP (0:1): Old State = IKE_QM_READY New State = IKE_QM_I_QM1

Feb 2 08:03:51.583: ISAKMP (0:1): received packet from 66.28.244.18 dport 500 sport 500 Global (I) QM_IDLE

Feb 2 08:03:51.595: ISAKMP (0:1): processing HASH payload. message ID = -572399601

Feb 2 08:03:51.595: ISAKMP (0:1): processing SA payload. message ID = -572399601

Feb 2 08:03:51.595: ISAKMP (0:1): Checking IPSec proposal 1

Feb 2 08:03:51.595: ISAKMP: transform 1, ESP_3DES

Feb 2 08:03:51.595: ISAKMP: attributes in transform:

Feb 2 08:03:51.595: ISAKMP: encaps is 1 (Tunnel)

Feb 2 08:03:51.595: ISAKMP: SA life type in seconds

Feb 2 08:03:51.595: ISAKMP: SA life duration (basic) of 3600

Feb 2 08:03:51.595: ISAKMP: SA life type in kilobytes

Feb 2 08:03:51.595: ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0

Feb 2 08:03:51.595: ISAKMP: authenticator is HMAC-MD5

Feb 2 08:03:51.599: ISAKMP (0:1): atts are acceptable.

Feb 2 08:03:51.599: ISAKMP (0:1): processing NONCE payload. message ID = -572399601

Feb 2 08:03:51.599: ISAKMP (0:1): processing ID payload. message ID = -572399601

Feb 2 08:03:51.599: ISAKMP (0:1): processing ID payload. message ID = -572399601

Feb 2 08:03:51.647: ISAKMP (0:1): Creating IPSec SAs

Feb 2 08:03:51.647: inbound SA from 66.28.244.18 to 213.94.219.249 (f/i) 0/ 0

(proxy 6.!!!!

Success rate is 80 percent (4/5), round-trip min/avg/max = 108/111/112 ms

RODONOHU-HOME#6.28.244.18 to 213.94.219.249)

Feb 2 08:03:51.647: has spi 0x4D8354B6 and conn_id 202 and flags 2

Feb 2 08:03:51.647: lifetime of 3600 seconds

Feb 2 08:03:51.647: lifetime of 4608000 kilobytes

Feb 2 08:03:51.647: has client flags 0x0

Feb 2 08:03:51.647: outbound SA from 213.94.219.249 to 66.28.244.18 (f/i) 0/ 0 (proxy 213.94.219.249 to 66.28.244.18 )

Feb 2 08:03:51.647: has spi 873654110 and conn_id 203 and flags A

Feb 2 08:03:51.647: lifetime of 3600 seconds

Feb 2 08:03:51.647: lifetime of 4608000 kilobytes

Feb 2 08:03:51.647: has client flags 0x0

Feb 2 08:03:51.651: ISAKMP (0:1): sending packet to 66.28.244.18 my_port 500 peer_port 500 (I) QM_IDLE

Feb 2 08:03:51.655: ISAKMP (0:1): deleting node -572399601 error FALSE reason ""

Feb 2 08:03:51.655: ISAKMP (0:1): Node -572399601, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH

Feb 2 08:03:51.655: ISAKMP (0:1): Old State = IKE_QM_I_QM1 New State = IKE_QM_PHASE2_COMPLETE

[Jon Marshall]

Hi Rob

Sorry i didn't look at this yesterday - had a bit of a load balancing crisis.

The interesting but from the debugs is

local ident (addr/mask/prot/port): (172.17.25.16/255.255.255.240/0/0)

remote ident (addr/mask/prot/port): (192.206.209.0/255.255.255.0/0/0)

current_peer: 66.28.244.18:500

PERMIT, flags={origin_is_acl,}

#pkts encaps: 41, #pkts encrypt: 41, #pkts digest 41

#pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0

#pkts not decompressed: 0, #pkts decompress failed: 0

#send errors 1, #recv errors 0

Can you identify what traffic generated this ie. what machine you were using from home and which machine you were trying to contact. Cleary there was traffic being sent down the tunnel but nothing coming back.

Jon

[rodonohu1]

No problem at all.

I just tried to ping a server on the other end. it just timed out. Could numbered ACLs be better to use than Named? I know probably not but i'm clutching at straws. the machine from home was just a desktop.

Are there any other debugs or show commands i could use to show more details?

[Jon Marshall]

Rob

No i don't think it's going to make any difference what type of acl you use.

Can you confirm that if you try and contact a server at work from your home subnet that the debugging showed nothing ?

What i would like is the following

1) Turn on debug crypto isa

2) turn on debug crypto ipsec

Try to connect from home to a server at work. As it is trying to connect

1) sh crypto isa sa

2) sh crypto ipsec sa

I don't normally add in the peer IP addresses to the crypto maps when i do site-to-site VPNs but it should be okay.

Apologies if you have already done this but it is a bit unclear from the debugging.

Jon

[rodonohu1]

Hi,

Please find the attached text file from the commands above.

[Jon Marshall]

Rob

Sorry to be a pain but i don't think i explained myself properly. We know that the tunnel comes up when you ping the 7206 router public ip address from home. But what i'm trying to establish is what happens if you try and ping one of the servers from home but not after you have pinged the 7206 public ip address.

If you ping the public ip address of the 7206 then it will bring up the tunnel. What i want to know is what happens when there is no tunnel and you try and ping one of the servers/hosts at work. If you have debugging on you should see some activity.

If not then we can narrow it down to a problem with your home router recognising the traffic needs to be sent down the VPN.

Jon

[rodonohu1]

Hi Jon

I can safely say I'm the pain so far. Thanks again for looking at this. I'm attaching my results.looks like nothing is happening when i ping the server. Note, i did have bgp set up on this router and it worked with the 7206 fine. Reason i'm testing this with the ACL is that i need to set it up in the same way for another cisco router that doesn't support Bgb.

Have a look at the doc and let me know,

Cheers

[rtanner]

Sorry, I'll just stop lurking for a sec...

My understanding is that the access-list applied to the crypto map is used to determine what is encrypted over the tunnel. If so, I would question the entry with the local-peer/remote peer in the named access -list you match. Can you try removing this entry?

[rodonohu1]

This ACL issue will Kill me. To clarify, I'm trying to set up a IPsec tunnel and put an acl on each end to allow traffic pass from one subnet to the others. at this stage i can ping either end of the tunnel but no further. please see below: Any help or ideas would be greatly appreciated:

The core router config:

7206 side of Tunnel

crypto isakmp policy 4

encr 3des

hash md5

authentication pre-share

group 2

lifetime 3600

crypto isakmp key xxx address 213.x.219.249

crypto ipsec transform-set 60GMAC esp-3des esp-md5-hmac

crypto map COGENT_VPN 60 ipsec-isakmp

description RODONOHU-HOME-TEST

set peer 213.94.219.249

set transform-set 60GMAC

match address 160

ip route 213.94.219.249 255.255.255.255 66.28.244.17 name RODONOHU-TUNNEL

access-list 160 permit ip 172.16.0.0 0.0.255.255 172.17.25.16 0.0.0.15

access-list 160 permit ip 172.17.0.0 0.0.255.255 172.17.25.16 0.0.0.15

access-list 160 permit ip 192.168.0.0 0.0.255.255 172.17.25.16 0.0.0.15

access-list 160 permit ip 192.206.209.0 0.0.0.255 172.17.25.16 0.0.0.15

The 1700 side is attached.

[rtanner]

so, we know:

the crypto maps establish the association.

traffic goes one way at least ( based on jon's observations)

Given it was working with BGP, and not knowing your network, is there a route back to the home network (from the server) - since you have moved to a static environment from a dynamic one...

[Jon Marshall]

Hi Rob

Sorry i haven't responded, i was being a but dense. This thread now takes 2 pages but i didn't realise so i kept checking it only to see my message at the end of page one. Bit dense i know :-)

Unfortunately i couldn't open your .doc file. Based on your observations

1) Did the tunnel come up at all when you tried to ping the server

2) Did you see any debugging output on your home router when the tunnel came up.

3) It is certainly worth checking out the routing as suggested by other poster.

Jon

[rodonohu1]

No problem Jon. To answer your questions:

- when i tried to ping the server from my home router, nothing happened. I had debugging on but nothing was outputted to the screen. I can ping the tunnel end but no internal address.

- Following on from rtanners post - There is a static router from the 7206 to the home office router as follows:

ip route 213.94.219.249 255.255.255.255 66.28.244.17 name RODONOHU-TUNNEL

but not one for my internal network. should I add one for as follows:

ip route 172.17.25.16 255.255.255.240 66.28.244.17

[Jon Marshall]

Rob

if nothing happened it does sound like your home router does not recognise the traffic as needing to go down the VPN.

Could you let me know where you are pinging from and what you are pinging in terms of IP addresses.

From within your corporate network if you do a traceroute to 172.17.25.16 does it go to the 7206 router ?.

If not then yes you will need to add a route but not to 66.28.244.17. You need to add a route within your coporate network that sends traffic to the INTERNAL interface of your 7206. The VPN config will take care of it from there.

Jon

[rodonohu1]

Jon,

When I traceroute on the 7206 i get the following:

1 192.168.31.205 0 msec 0 msec 0 msec

2 192.168.142.118 4 msec 0 msec 0 msec

3 192.168.0.254 92 msec 96 msec 96 msec

4 172.17.2.17 [AS 65203] 100 msec 96 msec 96 msec

5 172.17.4.4 [AS 65203] 92 msec 92 msec 96 msec

6 * * *

7 * * *

this is because on anohter router we have the 172.17.25.0 subnet advertised using BGP. So I think I need to add the static route to ensure that the traffic goes out statically. The internal interface has an address of 192.168.31.206 - is this the correct interface? I see other static routes pointing to the 66.28.244.17 address with i guess is the other end of the external interface. Why not this?

[Jon Marshall]

Rob

You usually only have to get the traffic to the device that is doing the VPN. The crypto map access-list is used to determine where to send the traffic.

So the packet arrives at the 7206 and it consults the crypto maps, finds a match, encrypts it and routes it down the VPN tunnel. I've never had to configure a static route on the VPN device for the remote device.

Having said that what might be happening in your network is that all the statics routes are done on the 7206 and so you would need to point it somewhere.

What i generally do is step one router back, so in your case the router that connects to the 7206 from the inside. Add the static there and then redistribute it into your IGP if that is hwo your internal network routing works.

However this may not apply in your network so if you are applying the route on the 7206 you should make the next hop 66.28.244.17 as you say.

Jon