Hi, I have been working with Cisco and the vendor for 2 weeks on this.II am hoping the issue we are seeing will ring a bell with someone.
Some background information:
I am working a vendor who requires a site to site tunnel. My network currently has 1 site to site with the vendor using a Juniper SSG which works without incident. I am transitioning to Cisco 2811 routers and am set up a new tunnel with the vendor for the 2800 using another public ip in my address range. So my network has 2 tunnels with the vendor who is using a Cisco VPN concentrator. The hosts behind the tunnel use Public IP addresses 20x.x.x.x.
My Cisco router will create a tunnel, but I cannot get to the hosts on the vendor's network through the Cisco 2811, but I can through the Juniper tunnel. The Vendor sees my packets and the vendors' host replies to them and sends them to tunnel. They never reach the outside interface on my Cisco router.
I am NATing out of the outside interface so that my endpoint and peer are the same IP. (note, I tried doing a static NAT and having a the tunnel address and my host address different to the same result. Cisco confirmed that I do not require 2 different addresses and this setup has been successful with creating other successful tunnels toa different network.)
I had tested this setup on a staging network before moving the router to the production network and my Cisco 2811 was able to create the tunnel and ping the inside host. Once we moved the Router to the colo, we can no longer ping the host behind the vendor's tunnel. The vendor has assured me that the tunnel setup is exactly the same and that he sees his host sending traffic to the tunnel. The vendor does seem well versed with the VPN concentrator and successfully manages connections for many clients.
The vendor has a second VPN concentrator on a separate network and I can connect to that VPN concentrator successfully from the Cisco 2811 that is having issues with the Concentrator that also has a tunnel with the Juniper.
Here is what we have done so far:
1) Confirm the 2811 config with Cisco support. The tunnel is up. sh cyrpto ipa sa shows the tunnel up.
2) Enable Nat-T on the VPN Contrator side of the tunnel
3) Confirm that the trafiic flows properly from a tunnel on another network (which would indicate the Cisco config is ok)
4) Successfully tunnel and reach hosts on a different config
5) Confirm all tunnel settings with the vendor
6) The vendor confirmed that the host on his side has no routes and points to the default gateway
7) Rebuild the tunnel from scratch
8) Confirm with our ISP that no routes are diverting the traffic else where. My lSP gateway sees my outside address as directly connected.
9) Confirm that the ACL matches with the vendor
10) I can not pull down the Juniper as it is in production and in constant use
Is there any known issue with using a VPN concentrator to connect to 2 tunnels on the same /28 network range?
Any ideas or options are welcome. I have had countless webex sessions with Cisco, but do not have access to the Vendor's concentrator. I can pass along any suggestions.
Here is some code
crypto isakmp policy 1
crypto isakmp policy 2
crypto ipsec transform-set mytrans esp-aes esp-sha-hmac
crypto dynamic-map dynmap 30
set transform-set myset
crypto isakmp key <key here> address <vendor endpoint ip> no-xauth
description $ETH-LAN$$ETH-SW-LAUNCH$$INTF-INFO-FE 0/0$
ip address <my outside> 255.255.255.240
ip access-group 107 in
ip access-group 106 out
ip nat outside
ip route-cache flow
crypto map mymap
logging Access-lists (applied to outside to get a sense of what is coming in. No esp traffic comes in, there are never hits)
access-list 106 permit esp host <my public IP> host <vendor VPN endpoint> log
access-list 106 permit ip any any
access-list 107 permit esp host <vendor VPN host (is public IP)> host <my public IP> log
access-list 107 permit ip host <my public IP> host <vendor VPN host (is public IP)> log
access-list 107 permit ip host <my public IP> host <vendor VPN endpoint> log
access-list 107 permit ip any any
sh crypto isa sa
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
<vendor endpoint ip> <my public ip> QM_IDLE 1010 0 ACTIVE
Crypto Map "mymap" 1 ipsec-isakmp
Peer = <vendor endpoint IP>
Extended IP access list 116
access-list 116 permit ip host <my outside ip> host <vendor inside out IP> (which is a public IP))
Current peer: <vendor endpoint IP>
Security association lifetime: 4608000 kilobytes/2800 seconds
PFS (Y/N): N
OK - so I messed around in the lab for 20 mins and came up with the below (ip's are test IP's:-
(4) ip nat pool crypto-nat 10.1.1.1 10.1.1.1 prefix-length 30 <> this is the New NAT Address
(1) ip nat inside source list 102 interface FastEthernet0/0 overload <> This is the default interface NAT
ip nat inside source route-map crypto-nat pool crypto-nat overload <> This is the policy based NAT
(6) access-list 101 permit ip 172.16.1.0 0.0.0.255 172.16.2.0 0.0.0.255 <> Defines the source and destination IP traffic
(2) access-list 102 deny ip 172.16.1.0 0.0.0.255 172.16.2.0 0.0.0.255 <> Does not NAT the normal communication
(3) access-list 102 deny ip host 10.1.1.1 172.16.2.0 0.0.0.255 <> Does not re-NAT the NAT
(1) access-list 102 permit ip 172.16.1.0 0.0.0.255 any <> allows all else to use the interface IP for NAT
(5) route-map crypto-nat permit 5 <> The condition for the specific required NAT
match ip address 101 <> Match source and destination IP traffic required to be NAT'td
(7) access-list 103 permit ip host 10.1.1.1 172.16.2.0 0.0.0.255 <> crypto acl
So how the above works, when a packet with the source IP of 172.16.1.0/24 wants to leave the router to connect to say google, the source will change to the interface IP (1). When 172.16.1.0/24 wants to speak to172.16.2.0/24, it does not get translated (2). When the traffic the remote end has matched the next NAT clause - the already NAT'td IP will not be touched again(3) When a host 172.16.1.0/24 wants to communicate with 172.16.2.20/24 we have to NAT to a specific NAT pool is required (4). We need to define a method of matching specific traffic to apply the NAT using a route map (5) which is only applied when specific traffic is in play (6) Then you just need to define the interesting traffic for the VPN to initiate and allow comms(7)