Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Webcast-Catalyst9k
New Member

ACL Problem

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

40 REPLIES
Hall of Fame Super Blue

Re: ACL Problem

Hi Robert

Could you send the full configs minus any sensitive info. What youy have sent looks alright but i suspect there may be some NAT issues going on.

Jon

New Member

Re: ACL Problem

Sure thing John,

Thanks for looking at this.

Rob.

Hall of Fame Super Blue

Re: ACL Problem

Hi Robert

Could you send me an e-mail asap at

jon.marshall@networkrail.co.uk

Thanks

Hall of Fame Super Blue

Re: ACL Problem

Hi Robert

Still sifting through 7206 config :-). Couple of questions

1) Do the VPN setups for RConway & PKearney work ?. These seem to be setup the same as yours.

2) When you try and connect from home how far does the VPN negotiation get, if anywhere.

3) When you say you can access the peer ip addresses with ping have you confirmed this is bringing up the VPN tunnel or is it just going out in cleartext.

The only thing i did notice which is why i aksed 1) is that you have a route not only for your home public ip address but also for your home subnet. This should not be needed on the 7206 as the crypto map access-list should see this as interesting traffic and know it has to be sent down a VPN tunnel. But if the others are working then i guess it makes no difference.

Jon

New Member

Re: ACL Problem

Hi Jon,

Thanks for looking at this.

To answer:

1) The Rconway one worked but it has since been removed so i can't test. I set up the Pkearney one last week and have the same problem as my own one.

2) When i connect from home, the Dialer interface comes up and I can ping the peer address. but how do i verify that the VPN tunnel is up? what debug commands do I need? There is no explicit tunnel created like in the other ones where I use BGP routing and a gre tunnel. I'd do all these the same as that only for two users have wireless routers that don't support BGP.

Do you think I should take out the static route altogether?

Re: ACL Problem

Looks like you have mismatched isakmp policies on the peering routers. Your ISAKMP SA is probably not established and you can verify that by doing 'show crypto isakmp sa'. The default isakmp encryption is DES & hash is SHA and that's what you are using on the core router. Can you remove the hash & encryption from the home office router.

On the Home Office Router:

crypto isakmp policy 1

no encr 3des

no hash md5

If you are still having issues, can you post the output of 'show crypto isakmp policy' from both routers.

HTH

Sundar

New Member

Re: ACL Problem

Hi

I will try this but I have other Home office routers using the same set up with "Policy 1" but they can route. They were using BGP but the router I'm trying to configure this using static route and access lists.

Still no luck.

Hall of Fame Super Blue

Re: ACL Problem

Hi Robert / Sundar

Sundar, there is actually an isakmp policy on the core router that matches but it's just not included in the original post. It's isakmp policy 4 and it should be picked up i would have thought.

I'm still not sure about the route for the remote subnet. Sundar, do you know if this would stop it working ?

Robert - it wouldn't do any harm to temporarily remove the route to see what happens.

If you could also run the commands Sundar sent - best run them on your home router rather than the 7206, there's a lot going on with that router :-)

HTH

Jon

New Member

Re: ACL Problem

Hi guys,

I've removed the route on the core router and also made the checks and changes to the policy on the home office but still no luck:

See output below from the "sh crypto policy"

Output:

RODONOHU-HOME#sh crypto isakmp policy

Global IKE policy

Protection suite of priority 1

encryption algorithm: Three key triple DES

hash algorithm: Message Digest 5

authentication method: Pre-Shared Key

Diffie-Hellman group: #2 (1024 bit)

lifetime: 3600 seconds, no volume limit

Default protection suite

encryption algorithm: DES - Data Encryption Standard (56 bit keys).

hash algorithm: Secure Hash Standard

authentication method: Rivest-Shamir-Adleman Signature

Diffie-Hellman group: #1 (768 bit)

lifetime: 86400 seconds, no volume limit

RODONOHU-HOME#

Global IKE policy

Protection suite of priority 1

encryption algorithm: DES - Data Encryption Standard (56 bit keys).

hash algorithm: Secure Hash Standard

authentication method: Pre-Shared Key

Diffie-Hellman group: #2 (1024 bit)

lifetime: 3600 seconds, no volume limit

Default protection suite

encryption algorithm: DES - Data Encryption Standard (56 bit keys).

hash algorithm: Secure Hash Standard

authentication method: Rivest-Shamir-Adleman Signature

Diffie-Hellman group: #1 (768 bit)

lifetime: 86400 seconds, no volume limit

Any reason why this wouldn't work? is there an easier way of doing it? Normally I'd use Bgp but its not support on the IOS for the HO. What is set up should work, thats what is bugging me.

Hall of Fame Super Blue

Re: ACL Problem

Rob

From the configs i can't see a huge lot wrong with what you have. Can you try these commands on your home router when you try to connect

1) debug crypto isa

2) debug crpyto ipsec

3) sh crypto isa sa

4) sh crypto ipsec sa

This should give us an idea of how far it is getting

Jon

New Member

Re: ACL Problem

I'll check it out.

Just a thought - where do I apply the COGENT_VPN map on the 7206 seeing that i'm not using a tunnel. Is there an interface I apply it to?

Hall of Fame Super Blue

Re: ACL Problem

Rob

I must have missed that. it will need to applied on the interface with 62.88.x.x address on your 7206 (sorry i've shredded the config now). If it isn't applied it definitely won't work.

Jon

New Member

Re: ACL Problem

sorry I checked it again there. its there on the interface alright. just skipped it. AHH this thing is frustrating.!

New Member

Re: ACL Problem

Jon,

I've run those debugging commands. You might find the output interesting.

please see attached.

Rob.

New Member

Re: ACL Problem

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

Hall of Fame Super Blue

Re: ACL Problem

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

New Member

Re: ACL Problem

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?

Hall of Fame Super Blue

Re: ACL Problem

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

New Member

Re: ACL Problem

Hi,

Please find the attached text file from the commands above.

Hall of Fame Super Blue

Re: ACL Problem

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

New Member

Re: ACL Problem

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

New Member

Re: ACL Problem

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?

New Member

Re: ACL Problem

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.

New Member

Re: ACL Problem

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

Hall of Fame Super Blue

Re: ACL Problem

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

New Member

Re: ACL Problem

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

Hall of Fame Super Blue

Re: ACL Problem

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

New Member

Re: ACL Problem

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?

Hall of Fame Super Blue

Re: ACL Problem

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

215
Views
0
Helpful
40
Replies
CreatePlease to create content