cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6001
Views
0
Helpful
37
Replies

Site-To-Site VPN Cisco 877

ICT-Support
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

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

View solution in original post

37 Replies 37

slmansfield
Level 4
Level 4

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

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.

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

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.

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

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.

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.

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.

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.

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!

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?

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!

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.

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: