topic Re: ACL Problem in Switching

ACL Problem

rodonohu1 — Tue, 05 Mar 2019 22:03:32 GMT

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

Re: ACL Problem

Jon Marshall — Tue, 30 Jan 2007 10:09:29 GMT

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

Re: ACL Problem

rodonohu1 — Tue, 30 Jan 2007 10:24:39 GMT

Sure thing John,

Thanks for looking at this.

Rob.

Re: ACL Problem

Jon Marshall — Tue, 30 Jan 2007 10:51:14 GMT

Hi Robert

Could you send me an e-mail asap at

jon.marshall@networkrail.co.uk

Thanks

Re: ACL Problem

Jon Marshall — Tue, 30 Jan 2007 18:27:59 GMT

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

Re: ACL Problem

rodonohu1 — Tue, 30 Jan 2007 18:52:02 GMT

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

sundar.palaniappan — Tue, 30 Jan 2007 18:55:22 GMT

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

Re: ACL Problem

rodonohu1 — Tue, 30 Jan 2007 19:19:15 GMT

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.

Re: ACL Problem

Jon Marshall — Tue, 30 Jan 2007 21:07:11 GMT

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

Re: ACL Problem

rodonohu1 — Wed, 31 Jan 2007 00:05:22 GMT

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.

Re: ACL Problem

Jon Marshall — Wed, 31 Jan 2007 07:19:30 GMT

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

Re: ACL Problem

rodonohu1 — Wed, 31 Jan 2007 09:39:22 GMT

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?

Re: ACL Problem

Jon Marshall — Wed, 31 Jan 2007 11:14:16 GMT

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

Re: ACL Problem

rodonohu1 — Wed, 31 Jan 2007 11:32:50 GMT

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

Re: ACL Problem

rodonohu1 — Wed, 31 Jan 2007 15:22:20 GMT

Jon,

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

please see attached.

Rob.

Re: ACL Problem

rodonohu1 — Wed, 31 Jan 2007 22:50:45 GMT

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

Re: ACL Problem

Jon Marshall — Thu, 01 Feb 2007 08:39:24 GMT

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

Re: ACL Problem

rodonohu1 — Thu, 01 Feb 2007 09:12:41 GMT

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?

Re: ACL Problem

Jon Marshall — Thu, 01 Feb 2007 10:22:08 GMT

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

Re: ACL Problem

rodonohu1 — Thu, 01 Feb 2007 21:22:41 GMT

Hi,

Please find the attached text file from the commands above.