Site-To-Site VPN Cisco 877

Answered Question
Apr 21st, 2010

Hi,

I am attempting to set up a site-to-site VPN on a cisco 877 which is connecting to an ISA Server.

It fails on Phase 2 with the following error:

000320: *Apr 21 12:11:07.028 PCTime: IPSEC(validate_proposal_request): proposal

part #1,

  (key eng. msg.) INBOUND local= 83.X.X.X, remote= 87.X.X.X,

   local_proxy= 172.16.25.0/255.255.255.0/0/0 (type=4),

   remote_proxy= 87.x.x.x/255.255.255.255/0/0 (type=1),

   protocol= ESP, transform= NONE  (Tunnel),

   lifedur= 0s and 0kb,

   spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0

00323: *Apr 21 12:11:07.028 PCTime: map_db_find_best did not find matching map

00324: *Apr 21 12:11:07.028 PCTime: IPSEC(ipsec_process_proposal): proxy identi

ies not supported

As per the above, it seems to being using the public IP address of the peer for "Remote_Proxy" and not the local lan: 10.0.0.0, 255.0.0.0

In my crypto map definition I have "match address 104" which is an access-list which reads:

access-list 104 permit ip 172.16.25.0 0.0.0.255 10.0.0.0 0.255.255.255
access-list 104 deny ip 172.16.25.0 0.0.0.255 any

Does anyone know what may be the issue?

Regards,

Simon

I have this problem too.
0 votes
Correct Answer by slmansfield about 6 years 7 months ago

If you can, try pinging from another device on the 172.16.25.x subnet.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
slmansfield Wed, 04/21/2010 - 10:12

The error message indicates that the access-lists for your interesting traffic do not match on your VPN peers.

You do not need a deny statement in your access list, as there is an implicit deny of all other traffic except what is permitted.

The access-lists should be mirror images of each other, for example:

ROUTER 1

access-list 104 permit ip 172.16.25.0 0.0.0.255 10.0.0.0 0.255.255.255

ROUTER 2

access-list 104 permit ip 10.0.0.0 0.255.255.255 172.16.25.0 0.0.0.255

HTH

ICT-Support Thu, 04/22/2010 - 03:51

Hi,

I fixed the subnet mask: it should have been 0.0.31.255 - the connection then came up, but only when issued from the peer end. The connection then dropped and now won't connect again and now comes up with the same incorrect remote_proxy address per my first post. This is what I have:

crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
lifetime 28800
crypto isakmp key address 87.X.X.X no-xauth

crypto ipsec transform-set BR-3DES-SHA1 esp-3des esp-sha-hmac
!
crypto map SITE1 1 ipsec-isakmp
set peer 87.X.X.X
set security-association lifetime kilobytes 100000
set transform-set BR-3DES-SHA1
set pfs group2
match address 104
!

ip nat pool INTERNET netmask 255.255.255.252
ip nat inside source route-map nonat pool INTERNET overload

access-list 104 permit ip 172.16.25.0 0.0.0.255 10.0.0.0 0.0.31.255
access-list 104 deny   ip 172.16.25.0 0.0.0.255 any
access-list 105 remark No NAT Rules
access-list 105 deny   ip 172.16.25.0 0.0.0.255 10.0.0.0 0.0.31.255
access-list 105 permit ip 172.16.25.0 0.0.0.255 any

route-map nonat permit 10
match ip address 105

Any ideas?

Cheers,

Simon.

slmansfield Thu, 04/22/2010 - 05:56

ACL 104 should not have a deny statement.  It only specifies the networks you want to encrypt.  Any networks that are not listed are implicitly denied.  Please remove that statement.

Do you have the IPSEC configuration on the other device?  The ACL on the remote device that corresponds to 104 on this router should be what is listed below.  The subnets should be the traffic you want to encrypt, which is usually local inside networks at each site:

access-list 104 permit ip 10.0.0.0 0.0.31.255 172.16.25.0 0.0.0.255

ICT-Support Fri, 04/23/2010 - 03:12

Hi,

The reason I am trying to use 10.0.0.0 / 255.0.0.0 is that I have another subnet on my internal lan (10.0.128.0 / 255.255.224.0 which is a Vlan on a switch and the routing between Vlans is done by the switch) which I want to get to also over the VPN, is this not the correct way of doing it?

Also, if i use the correct wildcard mask 0.0.31.255 it will connect randomly, but other times the debug tells me it's trying to use the public IP for dest_proxy. If i use the wildcard mask of 0.255.255.255 it will do the same - random connections and other times the dest_proxy is the public IP.

I am attempting to establish a site-to-site VPN to an ISA Server if this helps.

Any ideas?

Cheers,

SImon.

slmansfield Fri, 04/23/2010 - 06:34

The access list that defines interesting traffic can be as broad or as narrow as you want.  If you configure a broader range of addresses that means that any device whose address is within that range can send traffic through the VPN tunnel.  Sometimes an engineer may want to define a narrow range for security reasons.  The key is that the access lists on both VPN endpoints be mirror images of each other.  That is very critical.  The range is not critical except that it includes the traffic that you want to have encrypted, and excludes the traffic that you don't want to have encrypted.

Could you post sanitized versions of the configs?  Also, what type of central site ISA server are you using, and how much memory does it have?

Thanks

ICT-Support Fri, 04/23/2010 - 06:59

So for example my access-list says:

access-list 104 permit ip 172.16.25.0 0.0.0.255 10.0.0.0 0.0.31.255 how do i say for traffic destined for 10.0.128.x go over the VPN?

Cheers,

Simon.

slmansfield Fri, 04/23/2010 - 07:18

The subnet mask you are using will not include that subnet.  You will need a 16 bit mask or less, e.g., 10.0.0.0 0.0.255.255.

At the site that includes the 10.0.128.x subnet, set up an interesting traffic access list like this:

access-list 104 permit ip 10.0.0.0 0.0.255.255 172.16.25.0 0.0.0.255

At the site that includes the 172.16.25.0/24 subnet, set up and interesting traffic access list like this:

access-list 104 permit ip 172.16.25.0 0.0.0.255 10.0.0.0 0.0.255.255

If you could post sanitized configs it will be easier to assist you.

ICT-Support Fri, 04/23/2010 - 08:03

This is what I have:

This is what I have:

crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
lifetime 28800
crypto isakmp key address 87.X.X.X no-xauth

crypto ipsec transform-set BR-3DES-SHA1 esp-3des esp-sha-hmac
!
crypto map SITE1 1 ipsec-isakmp
set peer 87.X.X.X
set security-association lifetime kilobytes 100000
set transform-set BR-3DES-SHA1
set pfs group2
match address 104
!
ip nat pool INTERNET netmask 255.255.255.252
ip nat inside source route-map nonat pool INTERNET overload

access-list 104 permit ip 172.16.25.0 0.0.0.255 10.0.0.0 0.0.255.255
access-list 105 remark No NAT Rules
access-list 105 deny ip 172.16.25.0 0.0.0.255 10.0.0.0 0.0.255.255
access-list 105 permit ip 172.16.25.0 0.0.0.255 any

route-map nonat permit 10
match ip address 105

Would I need to add a route saying ip route 10.0.128.0 netmask 255.255.224.0 via vpn tunnel ?

I can't do much configuration on the ISA Server, except setting up peers and encryption. There are rules in place allowing the traffic at the ISA end.

slmansfield Fri, 04/23/2010 - 08:08

If you have a default route pointing to your next hop router then you don't need a separate static route to the remote LAN.  If not, then you can add

that static route.

What you are showing me looks fine, but if the settings don't match what's on your central site device then your VPN tunnel won't come up.

ICT-Support Fri, 04/23/2010 - 08:14

I have "ip route 0.0.0.0 0.0.0.0 dialer0" - does that sound right?

The tunnel is up fine, I can get to hosts on my 10.0.0.0 network, but not anything to 10.0.128.0 (which is a VLAN). If i try and ping anything on the 10.0.128.0 network it doesn't hit the ISA Firewall, so I assume it's not going over the tunnel. If I traceroute it hits 172.16.25.254 (the cisco) and then times out.

Sorry for being such a newbie!

slmansfield Fri, 04/23/2010 - 08:16

Every experience is a learning experience for all of us.

It sounds like the 10.0.128.x network is not in the interesting traffic access list on the headend device.  Is there any way to check this?

ICT-Support Mon, 04/26/2010 - 08:34

Still no joy I'm afraid. Each time I ping from the peer (ISA Server) to the CISCO's internal IP (172.16.25.254) I get the following when running "debug crypto ipsec":

part #1,

  (key eng. msg.) INBOUND local= 83.X.X.X, remote= 87.X.X.X,

    local_proxy= 172.16.25.0/255.255.255.0/0/0 (type=4),

    remote_proxy= 87.X.X.X/255.255.255.255/0/0 (type=1), ---- shouldn't this be the private range, e.g, 10.0.0.0/255.255.0.0 ? Why does it NAT?

    protocol= ESP, transform= NONE  (Tunnel),

    lifedur= 0s and 0kb,

    spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0

000178: *Apr 26 10:41:24.812 PCTime: Crypto mapdb : proxy_match

        src addr     : 172.16.25.0

        dst addr     : 87.X.X.X

        protocol     : 0

        src port     : 0

        dst port     : 0

000179: *Apr 26 10:41:24.812 PCTime: Crypto mapdb : proxy_match

        src addr     : 172.16.25.0

        dst addr     : 87.X.X.X

        protocol     : 0

        src port     : 0

        dst port     : 0

000180: *Apr 26 10:41:24.812 PCTime: map_db_find_best did not find matching map

000181: *Apr 26 10:41:24.812 PCTime: IPSEC(ipsec_process_proposal): proxy identi

ties not supported

It would appear that remote_proxy is using the public IP (the ISA Server) and not the internal range of the remote network. Is there something wrong with my NAT rules? Is it ignoring my access-lists?

Access-list 104 (permitting the interesting traffic says):

Extended IP access list 104

    10 permit ip 172.16.25.0 0.0.0.255 10.0.0.0 0.0.255.255 (1642 matches)

Access-list 105 (the NO NAT rule) says:

Extended IP access list 105

    10 deny ip 172.16.25.0 0.0.0.255 10.0.0.0 0.0.255.255 (530 matches)

    20 permit ip 172.16.25.0 0.0.0.255 any (3253 matches)

On the ISA end, the only things you can do is specify the remote network range, the encryption settings and the public IPs of the peers.

Regards,

Simon.

P.S, sometimes it will randomly connect if you remove and re-add the access-list 104 (the interesting traffic) as the debug will say 10.0.0.0/255.255.0.0 for remote_proxy, but this occurs completely randomly when you initiate a ping from the peer (ISA). Also I have noticed that id i change the subnet mask as i did earlier for 10.0.0.0 to 0.255.255.255 (on rule 104) it then connects, but then if you reboot the cisco it fails again.

Also, oddly enough, if I ping 172.16.25.254 (the CISCO) from a server on my main site I get a reply and if I issue the following from the CISCO I get:

IPv4 Crypto ISAKMP SA

dst                                          src                   state                  conn-id slot status

83.X.X.X (Public IP of CISCO)    87.X.X.X (ISA)    QM_IDLE           2010    0 ACTIVE

However, when I was at the remote site and tried to ping the HQ (10.0.0.0 range) I receive as per the beginning of the post (crypto debug) - before changing or updating any rules.

When I was also at the remote site I initiated and client-to-site VPN, remoted into the ISA Server and tried to initiate a ping to the CISCO (172.16 address) and I also received the debug error as per the start of this message, and yet if I ping from a server on the main site back to the CISCO (to the 172 address) it goes through fine.

I am confused!

slmansfield Mon, 04/26/2010 - 12:02

Sorry Simon!  The output of the debug indicates that the remote peer (the ISA) is using its IPSEC peer address to initiate the VPN connection.  The interesting traffic access list on the ISA looks like it refers to that host address, reflected by the label of "(type=1)" in the remote_proxy statement.

It is very critical for the interesting traffic access list on the ISA to be a mirror image of what is on your 877.  I truly believe that the answer to your dilemma lies in a discrepancy between the interesting traffic access lists on the ISA and your 877.

Your 877 VPN configuration looks fine, as does your NAT configuration.

ICT-Support Mon, 04/26/2010 - 12:21

Hrm, well, it seems strange that you can ping from the main network (the 10.0.0.0 range) to 172.16.25.254 (the 877) to establish the tunnel, but you can't establish the connection when pinging from the 172.16.25.0 range back to the 10.0.0.0 range - surely if there is an issue between the peers with the 'interesting' traffic rules, the connection would not establish from any end?

Is the above reason (interesting traffic mismatch) why the debug output randomly change the remote_proxy from 10.0.0.0 / 255.255.0.0 to 87.X.X.X (public IP of ISA) / 255.255.255.255 ?

Like for example when viewing "debug crypto ipsec" you may get:

part #1,

  (key eng. msg.) INBOUND local= 83.X.X.X, remote= 87.X.X.X,

    local_proxy= 172.16.25.0/255.255.255.0/0/0 (type=4),

    remote_proxy= 87.X.X.X/255.255.255.255/0/0 (type=1), -- public IP of the ISA Server

and then:

part #1,

  (key eng. msg.) INBOUND local= 83.X.X.X, remote= 87.X.X.X,

    local_proxy= 172.16.25.0/255.255.255.0/0/0 (type=4),

    remote_proxy= 10.0.0.0/255.255.0.0/0/0 (type=4),

And so on... Each attempt doesn't alternate though, it just randomly switches the remote_proxy.

Cheers,

Simon.

slmansfield Mon, 04/26/2010 - 12:27

You've provided a lot of information, which is great, but I thought I understood that the result of pinging 172.16.25.254 from the ISA was the debug output showing the remote of 87.x.x.x and a failed VPN tunnel establishment.

Is it possible to provide sanitized configurations of both sites?  That would take a lot of the guesswork out of the troubleshooting effort.  Thanks

ICT-Support Mon, 04/26/2010 - 12:41

Thats what I don't get, when I was at the remote site and I had a remote session onto the ISA Server and pinged the 877 it generated those logs, however later on when I had returned to the main site and pinged from another server on that site (other than the ISA Server) to the 877 it was pinging fine.

I'll see what else I can paste here. The other thing I thought about is I have some additional acls filtering outbound traffic and inbound traffic which are access-groups on Vlan1 (acl 103) and Dialer0 (acl 101) - could these be breaking the connection?

Regards,

Simon.

slmansfield Mon, 04/26/2010 - 12:52

Since the 877 does not have the 87.x.x.x address in its interesting traffic ACL, the tunnel will not come up.  The device on a 10.x.x.x/16 subnet is in your interesting traffic, so it should bring up the tunnel.

The ISA may have multiple ACL rules in the interesting traffic definition for your site.  There may be other lines in the ACL for 10.x.x.x/16 range subnets.

If you can sanitize the configs and include the outside access-lists on the 877 that would be helpful.  You should be allowing ESP and UDP 500 traffic into the 877 from the ISA peer address.  I don't think this is the problem, but it would help to just rule them out.

ICT-Support Tue, 04/27/2010 - 07:43

An update (if it helps!)

I went to the remote site this morning, changed the access-list 104 (the interesting traffic) rule to the following:

access-list 104 permit ip 172.16.25.0 0.0.0.255 10.0.0.0 0.0.255.255

The VPN tunnel came up and worked, but now I note that the connection has dropped (I am not at the remote site to trouble-shoot) but have noticed that the remote_proxy changes to 10.0.128.0 (the voice network - and have seen this before).

I feel that the the interesting traffic rule will have to be "access-list 104 permit ip 172.16.25.0 0.0.0.255 10.0.0.0 0.0.31.255" as our net mask is 255.255.224.0, however if I do this, how would I get to the voice network (10.0.128.0) from the remote site?

Can I simply add an "ip route 10.0.128.0..." command and get it to tunnel down the VPN? To access the voice network from the main network, the gateway is 10.0.0.50.

Cheers,

Simon.

slmansfield Tue, 04/27/2010 - 08:09

access-list 104 permit ip 172.16.25.0 0.0.0.255 10.0.0.0 0.0.255.255

This ACL includes the voice subnet 10.0.128.0.  This ACL is what defines the traffic that will be sent through the VPN tunnel.  A static route alone will not send traffic destined for this network over the VPN tunnel.

The definition 10.0.0.0/19 does not include the 10.0.128.0 subnet.  You need the minimum of a 16 bit mask to include this subnet, as you now have it configured.

The VPN tunnel will drop after a configurable period of inactivity, as a security measure.  The question is whether it fires up whenever there is interesting traffic to send in either direction.

ICT-Support Wed, 04/28/2010 - 03:42

Hi again!

I went to the remote site this morning and noticed the following repeating over and over again on the logging:

1. 004025: Apr 28 11:21:03.992 BST: IPSEC(validate_proposal_request): proposal part

#1

004026: Apr 28 11:21:03.992 BST: IPSEC(validate_proposal_request): proposal part

#1,

  (key eng. msg.) INBOUND local= 83.X.X.X, remote= 87.X.X.X,

    local_proxy= 172.16.25.0/255.255.255.0/0/0 (type=4),

    remote_proxy= 87.X.X.X/255.255.255.255/0/0 (type=1),

    protocol= ESP, transform= NONE  (Tunnel),

    lifedur= 0s and 0kb,

    spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0

004027: Apr 28 11:21:03.992 BST: Crypto mapdb : proxy_match

        src addr     : 172.16.25.0

        dst addr     : 87.X.X.X

        protocol     : 0

        src port     : 0

        dst port     : 0

004028: Apr 28 11:21:03.992 BST: Crypto mapdb : proxy_match

        src addr     : 172.16.25.0

        dst addr     : 87.X.X.X

        protocol     : 0

        src port     : 0

        dst port     : 0

004029: Apr 28 11:21:03.992 BST: map_db_find_best did not find matching map

004030: Apr 28 11:21:03.992 BST: IPSEC(ipsec_process_proposal): proxy identities

not supported

As you can see from the above, the remote_proxy = 87.X.X.X (the public IP of my ISA Server) and it should equal 10.0.0.0/255.255.0.0

I then typed the following in:

#no access-list 105

#no access-list 104

And then typed in:

access-list 104 permit ip 172.16.25.0 0.0.0.255 10.0.0.0 0.255.255

access-list 105 Remark NO NAT Rules

access-list 105 deny ip 172.16.25.0 0.0.0.255 10.0.0.0 0.0.255.255

access-list 105 permit ip 172.16.25.0 0.0.0.255 any

It then connected immediately without my intervention. The rules I removed (104, 105) were already stored in the configuration and I typed the exact same rules back in.  Do you think this is a bug?

Simon.

slmansfield Wed, 04/28/2010 - 06:16

Do you know which version of IOS is running on the 877 and the ISA?

If I could get a look at the configs of both devices that would really help.   

ICT-Support Thu, 04/29/2010 - 05:22

Hi,

I've done some more digging, and have taken a look at my "Internal" network object on the ISA Server which defines the local networks and I have:

10.0.0.0 - 10.0.28.255

10.0.0.30 - 10.0.30.255

10.0.31.0 - 10.0.31.255

10.0.128.0 - 10.0.159.255

We use 10.0.29.0 for other purposes, hence why the above is split up.

I am assuming that the proxy identities on the ISA do not match the 104 access-list.

We also have other VPNs on this ISA Server which use other subnets too which may affect things.

We have tried connecting to the ISA Server with a site-to-site VPN using a netgear VPN device and have had no problems, hence why I am confused.

Cheers,

Simon.

slmansfield Thu, 04/29/2010 - 07:03

I can't say why the Netgear works differently without seeing the configurations of the Netgear and the ISA server. 

You can alter your access-list 104 to match the subnets on the ISA.  It doesn't matter which networks are chosen.   They just have to match as mirror images of each other.

I'm wondering whether your 877 should be set up differently.  Maybe your 877 should look like a VPN client using EZVPN?  Maybe you should use GRE tunnels so that your interesting traffic ACL would just be the GRE tunnel endpoints?  Here are some links to look at.  Maybe one of these more closely matches what you are trying to do?

http://www.cisco.com/application/pdf/paws/69352/easyvpn-7200svr-871remote.pdf

http://www.cisco.com/application/pdf/paws/9221/quicktip.pdf

ICT-Support Thu, 04/29/2010 - 07:08

Hi,

Sorry if it's obvious, but what would the access-list look like to cover these networks:

10.0.0.0 - 10.0.28.255

10.0.0.30 - 10.0.30.255

10.0.31.0 - 10.0.31.255

10.0.128.0 - 10.0.159.255

ISA Says the following:

    Subnet: 10.0.28.0/255.255.255.0

    Subnet: 10.0.24.0/255.255.252.0

    Subnet: 10.0.16.0/255.255.248.0

    Subnet: 10.0.0.0/255.255.240.0

    Subnet: 10.0.30.0/255.255.254.0

    Subnet: 10.0.128.0/255.255.224.0

I'll have a look into the other options.

Simon.

slmansfield Thu, 04/29/2010 - 07:26

The access-list you have configured with 10.0.0.0/16 includes all of these subnets, so you really don't have to change it as long as you never try to access a device on a subnet that is not included in the list on the ISA.

If you want to match the access-lists exactly, which is still not a bad idea, you'd just need to list those networks with your network, 172.16.25.0/24 as the destination.

I think I have these subnetted correctly!  ;-)

access-list 104 permit ip 10.0.28.0 0.0.0.255 172.16.25.0 0.0.0.255
access-list 104 permit ip 10.0.24.0 0.0.3.255 172.16.25.0 0.0.0.255
access-list 104 permit ip 10.0.16.0 0.0.7.255 172.16.25.0 0.0.0.255
access-list 104 permit ip 10.0.0.0 0.0.15.255 172.16.25.0 0.0.0.255
access-list 104 permit ip 10.0.30.0 0.0.1.255 172.16.25.0 0.0.0.255
access-list 104 permit ip 10.0.128.0 0.0.31.255 172.16.25.0 0.0.0.255

The debugs you most recently posted indicate that the ISA is initiating the VPN connection using a rule that has its host address, 87.x.x.x, going to your LAN, 1772.16.25.0/24.  This is not covered in the rules above.  Are you certain there are no other rules on the ISA that have your LAN, 172.16.25.0/24 as the destination network?

ICT-Support Thu, 04/29/2010 - 07:40

Thanks for all your help, I will put your subnets in, should they be from 172.16.25.0 > 10.0.0.0 as your examples are the other way around?

Interestingly enough, I've not put them in yet and I get this (still have the 10.0.0.0 / 255.255.0.0 mask in the config), how come it fails first and then decides to use 10.0.128.0 ?

router#clear cry isa

000482: Apr 29 15:28:47.296 BST: IPSEC(key_engine): got a queue event with 1 KMI message(s)

000483: Apr 29 15:30:50.756 BST: IPSEC(validate_proposal_request): proposal part #1

000484: Apr 29 15:30:50.756 BST: IPSEC(validate_proposal_request): proposal part #1,

  (key eng. msg.) INBOUND local= 83.x.x.x, remote= 87.x.x.x,

    local_proxy= 172.16.25.0/255.255.255.0/0/0 (type=4),

    remote_proxy= 87.x.x.x/255.255.255.255/0/0 (type=1),

    protocol= ESP, transform= NONE  (Tunnel),

    lifedur= 0s and 0kb,

    spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0

000485: Apr 29 15:30:50.760 BST: Crypto mapdb : proxy_match

        src addr     : 172.16.25.0

        dst addr     : 87.x.x.x

        protocol     : 0

        src port     : 0

        dst port     : 0

000486: Apr 29 15:30:50.760 BST: Crypto mapdb : proxy_match

        src addr     : 172.16.25.0

        dst addr     : 87.x.x.x

        protocol     : 0

        src port     : 0

        dst port     : 0

000487: Apr 29 15:30:50.760 BST: map_db_find_best did not find matching map

000488: Apr 29 15:30:50.760 BST: IPSEC(ipsec_process_proposal): proxy identities not supported

router#config term

Enter configuration commands, one per line.  End with CNTL/Z.

beachroad(config)#

000489: Apr 29 15:31:27.292 BST: IPSEC(validate_proposal_request): proposal part #1

000490: Apr 29 15:31:27.292 BST: IPSEC(validate_proposal_request): proposal part #1,

  (key eng. msg.) INBOUND local= 83.x.x.x, remote= 87.x.x.x,

    local_proxy= 172.16.25.0/255.255.255.0/0/0 (type=4),

    remote_proxy= 10.0.128.0/255.255.224.0/0/0 (type=4),

    protocol= ESP, transform= NONE  (Tunnel),

    lifedur= 0s and 0kb,

    spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0

000491: Apr 29 15:31:27.292 BST: Crypto mapdb : proxy_match

        src addr     : 172.16.25.0

        dst addr     : 10.0.128.0

        protocol     : 0

        src port     : 0

        dst port     : 0

000492: Apr 29 15:31:27.340 BST: IPSEC(key_engine): got a queue event with 1 KMI message(s)

000493: Apr 29 15:31:27.340 BST: Crypto mapdb : proxy_match

        src addr     : 172.16.25.0

        dst addr     : 10.0.128.0

        protocol     : 0

        src port     : 0

        dst port     : 0

000494: Apr 29 15:31:27.340 BST: IPSEC(policy_db_add_ident): src 172.16.25.0, dest 10.0.128.0, dest_port 0

000495: Apr 29 15:31:27.340 BST: IPSEC(create_sa): sa created,

  (sa) sa_dest= 83.x.x.x, sa_proto= 50,

    sa_spi= 0x80EB8596(2162918806),

    sa_trans= esp-3des esp-sha-hmac , sa_conn_id= 5

000496: Apr 29 15:31:27.344 BST: IPSEC(create_sa): sa created,

  (sa) sa_dest= 87.x.x.x, sa_proto= 50,

    sa_spi= 0x6C302D4B(1815096651),

    sa_trans= esp-3des esp-sha-hmac , sa_conn_id= 6

000497: Apr 29 15:31:27.392 BST: IPSEC(key_engine): got a queue event with 1 KMI message(s)

000498: Apr 29 15:31:27.392 BST: IPSEC(key_engine_enable_outbound): rec'd enable notify from ISAKMP

000499: Apr 29 15:31:27.392 BST: IPSEC(key_engine_enable_outbound): enable SA with spi 1815096651/50

slmansfield Thu, 04/29/2010 - 07:50

Yes, sorry I did transpose the access list rules.  The ones on the 877 should list 172.16.25.0/24 as the source in each of those entries.

Those debugs are being generated by the ISA server, not by the 877.  The 877 is not establishing the VPN tunnel when traffic is initiated by the 87.x.x.x host because that address is not ACL 104.  It is not interesting traffic.

However, when the ISA sends traffic from 10.0.128.0 as the source network the VPN tunnel is established because the 877 has that network in ACL 104.  You can see that the IPSEC SA is created between 10.0.128.0 and 172.16.25.0.

There must be some traffic, maybe a ping, that is being generated by the 87.x.x.x address?  If you take out this rule from the interesting traffic access list on the ISA then these failed attempts will stop.  Or the ISA could stop sending this traffic, for whatever reason it is being generated. 

ICT-Support Thu, 04/29/2010 - 08:12

Hrm, if i ping 172.168.25.254 (the CISCO) from my ISA Server, I get the following immediately generated on the CISCO.

I use 172.16.5.0 as a local LAN for another VPN using another device, but cant see 172.16.25.0 used anywhere else on ISA.

000675: Apr 29 16:07:29.655 BST: IPSEC(validate_proposal_request): proposal part #1,

  (key eng. msg.) INBOUND local= 83.X.X.X, remote= 87.X.X.X,

    local_proxy= 172.16.25.0/255.255.255.0/0/0 (type=4),

    remote_proxy= 87.X.X.X/255.255.255.255/0/0 (type=1),

    protocol= ESP, transform= NONE  (Tunnel),

    lifedur= 0s and 0kb,

    spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x0

000676: Apr 29 16:07:29.659 BST: Crypto mapdb : proxy_match

        src addr     : 172.16.25.0

        dst addr     : 87.X.X.X

        protocol     : 0

        src port     : 0

        dst port     : 0

000677: Apr 29 16:07:29.659 BST: Crypto mapdb : proxy_match

        src addr     : 172.16.25.0

        dst addr     : 87.X.X.X

        protocol     : 0

        src port     : 0

        dst port     : 0

000678: Apr 29 16:07:29.659 BST: Crypto mapdb : proxy_match

        src addr     : 172.16.25.0

        dst addr     : 87.X.X.X

        protocol     : 0

        src port     : 0

        dst port     : 0

000679: Apr 29 16:07:29.659 BST: Crypto mapdb : proxy_match

        src addr     : 172.16.25.0

        dst addr     : 87.X.X.X

        protocol     : 0

        src port     : 0

        dst port     : 0

000680: Apr 29 16:07:29.659 BST: Crypto mapdb : proxy_match

        src addr     : 172.16.25.0

        dst addr     : 87.X.X.X

        protocol     : 0

        src port     : 0

        dst port     : 0

000681: Apr 29 16:07:29.659 BST: Crypto mapdb : proxy_match

        src addr     : 172.16.25.0

        dst addr     : 87.X.X.X

        protocol     : 0

        src port     : 0

        dst port     : 0

000682: Apr 29 16:07:29.659 BST: Crypto mapdb : proxy_match

        src addr     : 172.16.25.0

        dst addr     : 87.X.X.X

        protocol     : 0

        src port     : 0

        dst port     : 0

000683: Apr 29 16:07:29.659 BST: map_db_find_best did not find matching map

000684: Apr 29 16:07:29.659 BST: IPSEC(ipsec_process_proposal): proxy identities not supported

000685: Apr 29 16:07:52.990 BST: %CRYPTO-4-IKMP_NO_SA: IKE message from 87.X.X.X has no SA and is not an initialization offer

slmansfield Thu, 04/29/2010 - 08:24

Yes, those are very similar to the other messages you posted.  I thought maybe it was because the ISA server was trying to ping a device, maybe the inside interface of the 877, and it was failing because the 87.x.x.x host is not in ACL 104.  You can add this rule if you need it.  My preference is to add a loopback interface on the 877 to use for network management purposes.  The loopback can be added to ACL 104 and also must be network reachable from the ISA server (e.g., static route pointing to the 877).

ICT-Support Thu, 04/29/2010 - 09:14

How would that work?

access-list 104 permit ip 127.0.0.1 0.255.255.255 10.0.28.0 0.0.0.255

access-list 104 permit ip 127.0.0.1 0.255.255.255 10.0.24.0 0.0.3.255

access-list 104 permit ip 127.0.0.1 0.255.255.255 10.0.16.0 0.0.7.255

access-list 104 permit ip 127.0.0.1 0.255.255.255 10.0.0.0 0.0.15.255

access-list 104 permit ip 127.0.0.1 0.255.255.255 10.0.30.0 0.0.1.255

access-list 104 permit ip 127.0.0.1 0.255.255.255 10.0.128.0 0.0.31.255

And then

route add 172.16.25.0 mask 255.255.255.0

Sound about right?

slmansfield Thu, 04/29/2010 - 09:25

Sorry Simon, I did not adequately explain how to configure a loopback interface on a router.

The loopback address you are referring to is an internal loopback that cannot be assigned to a router interface. 

Many times an enterprise will allocate a range of addresses to be used as loopbacks, then set up firewall rules, etc., so that any new device that's added to the network is accessible for network management purposes.  For example, if you want to set up SNMP access, NTP, TACACS+ authentication, FTP to update your IOS, etc., you can use this special loopback to represent the destination of the router itself.

Do you have such a range of addresses available from which you could assign a loopback to this router? 

The interesting traffic access list on the 877 should not be changed, but you can add a rule allowing the 87.x.x.x host to access your loopback address over the VPN tunnel if that is necessary for network management or troubleshooting.  You also need to ensure that the ISA has a route to the loopback address.

ICT-Support Thu, 04/29/2010 - 09:40

The thing I have noticed is that I cannot ping my 10.0.0.0 range from the console on the cisco, I get:

Type escape sequence to abort.

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

.....

Success rate is 0 percent (0/5)

Is this related to doing a loop back?

slmansfield Thu, 04/29/2010 - 10:02

That is because the outside interface of the 877 is not included in the interesting traffic access list.  If you run an extended ping from the inside interface on the router I think you will be successful.  Likewise, if you add the loopback to the interesting traffic access list you will be able to run an extended ping from that interface as well.  Here is an example of an extended ping.  Notice that I have selected the inside interface address on the 877.

#ping
Protocol [ip]:
Target IP address: 10.0.1.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 172.16.25.254
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.1.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.25.254
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/15/16 ms

I just want to see if your original issue was addressed.  We discussed the importance of having matching interesting traffic access lists on both VPN peers.  We also addressed why you see the debugs with inbound traffic initiated from 87.x.x.x.  I believe there is an interesting traffic access rule on the ISA server from host 87.x.x.x to 172.16.25.0/24.  You do not have the opposite rule on the 877 so the VPN tunnel does not come up with this traffic.  The tunnel is coming up when you generate traffic that is included in the interesting traffic access list.  If you want to create another rule to include this 87.x.x.x host if it is appropriate to encrypt this traffic you can just add a rule to ACL 104 on the 877.  You mentioned that your VPN tunnel drops after a time.  This is normal after a configurable period of time without any interesting traffic traversing the tunnel.  If the VPN tunnel is coming up when you do initiate traffic and it is not failing in the middle of transactions, then it is operating normally.

Cisco has a lot of great information on how to set up various VPNs.  I urge you to study the documentation on CCO to gain more knowledge of how this all is supposed to work.  It will save you a lot of time and frustration. 

ICT-Support Thu, 04/29/2010 - 14:09

Oddly enough, it looks like the tunnel is working, however when I try a ping from the cisco, none of the 5 packets get through. I can see the pings are allowed from the ISA Logs (as I can see connections from 172.16.25.254 to 10.0.1.1) but they don't seem to get through. There is a route back to the 172.16.25.0 network on that server. If i ping the router from that server, I get time outs, but ISA seems to allow the traffic through.

Correct Answer
slmansfield Thu, 04/29/2010 - 14:13

If you can, try pinging from another device on the 172.16.25.x subnet.

ICT-Support Fri, 04/30/2010 - 08:54

Well, looks like it's all fixed and working!

Thanks for your help!

Simon.

Actions

This Discussion