cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2036
Views
0
Helpful
20
Replies

traffic flow problem with tunnel created on network with an existing tunnel to a VPN concentrator

BIAAdvisor2009
Level 1
Level 1

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
encr 3des
hash md5
authentication pre-share
group 2
!
crypto isakmp policy 2
encr 3des
authentication pre-share
group 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

interface FastEthernet0/0
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 virtual-reassembly
ip route-cache flow
duplex auto
speed auto
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
        Transform sets={
                mytrans,
        }

20 Replies 20

Yep - policy based nat should do it.

Let me think about an example config that could apply.

only if that IP address is on the internal network of the remote end, the below is an example vpn tunnel

Site a external IP 1.1.1.1

Site a LAN IP 192.168.1.0/24

Site b external IP 2.2.2.2

Site b LAN IP 172.16.1.0 24

My interesting traffic (enable the VPN tunnel) acl would read

ip access-list 101 permit ip 192.168.1.0 0.0.0.255 172.16.1.0 0.0.0.255

My no-nat acl would read

ip access-list 201 deny ip 192.168.1.0 0.0.0.255 172.16.1.0 0.0.0.255 do not nat before encryption

ip access-list 201 permit ip 192.168.1.0 0.0.0.255 any nat anything else that leaves me

So the above means

anything from 192.168.1.x to 172.16.1.0 encrypt

anything from 192.168.1.x to 172.16.1.0 DO NOT NAT

What are YOUR IP networks?

What are the REMOTE IP networks?

FYI I posted my network info in the message above your last post.  I think that should cover it.  Hopefully that makes sense.

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)

Thanks so much for your help.  I just tested this and it works as you explained.  It looks like the other side had some type of configuration or hardware problem, so I am now working.  Your posted config is very educational.  Much appreciated!

np - glad to help.