04-21-2010 08:30 AM
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
Solved! Go to Solution.
04-29-2010 02:13 PM
If you can, try pinging from another device on the 172.16.25.x subnet.
04-21-2010 10:12 AM
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
04-22-2010 03:51 AM
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
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
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.
04-22-2010 05:56 AM
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
04-23-2010 03:12 AM
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.
04-23-2010 06:34 AM
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
04-23-2010 06:59 AM
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.
04-23-2010 07:18 AM
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.
04-23-2010 08:03 AM
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
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
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.
04-23-2010 08:08 AM
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.
04-23-2010 08:14 AM
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!
04-23-2010 08:16 AM
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?
04-26-2010 08:34 AM
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!
04-26-2010 12:02 PM
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.
04-26-2010 12:21 PM
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.
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: