GroupStudy.com GroupStudy.com - A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
RE: Another IPSec question: VPN client to Router posted 09/24/2001
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]


If you have the same private IP addressing on both ends, you'll need to
definitely use NAT and you'll also need to send a virtual IP address to the
VPN client.  The reasons being:
 
Remember the four different entities - src_proxy, dst_proxy,
src_tunnel_endpoint, dst_tunnel_endpoint - the src_proxy and
src_tunnel_endpoint can be the same, as can the dst side, but the src side
MUST differ from the dst side from each sides perspective.
 
So you would get a virtual IP address for the VPN client to represent the
src_proxy, the src_tunnel_endpoint is then NAT'ed at the Cable router, the
dst_tunnel_endpoint is the ATM interface, and the Cisco router also would
present virtual IP addresses for the dst_proxy, which are NAT'ed back to the
destination private IP addresses (this NAT will be one-to-one static) - this
is from the VPN client perspective, the roles are reversed from the routers
perspective (e.g. NAT Virtual IP addresses are src_proxy, etc...)
 
If the Cisco router side is only initiating connections to the VPN client
(VERY UNLIKELY) then you can get away with your hide NAT, and just use that
as the VIRTUAL IP in your access list.
 
So:
 
1.  Crypto map applied to wrong interface - should be applied to ATM
interface (after all, you specify the gateway on your VPN client as being
1.1.1.2 - the ATM interface)
 
2.  Your ACL should read -
access-list 101 permit VIRTUAL_IPS host x.x.x.x (where VIRTUAL_IPS
represents your static NATs and x.x.x.x is the VPN virtual client address)
e.g using what I've done below:
access-list 101 permit host 1.1.1.100 host 10.1.1.1
 
3.  You'll need NAT statement for one-to-one NATs
e.g.   ip nat inside source static 192.168.1.100 1.1.1.100
etc....
 
4.  You'll need to send a virtual IP address:
crypto isakmp client configuration address-pool local VPN_CLIENT
ip local pool VPN_CLIENT 192.168.10.1 192.168.10.1
 
5.  You'll need to ensure that your Cable router can NAT ESP (IP Prot 50)
and ISAKMP (UDP Port 500) to your VPN client.  Whatever this virtual IP
address is, this is the peer that you define the isakmp key for (crypto
isakmp key 12345678 address x.x.x.x)
 
6.  Your VPN Client destination traffic should be 1.1.1.100 and so on, NOT
the internal addressing.
 
Hope this makes sense!

Regards 
Justin Menga CCIE #6640
Network Solutions Architect
Wireless & E-Infrastructure
Compaq Computer New Zealand
DDI: +64-9-918-9381 Mobile: +64-21-349-599
mailto: justin.menga@xxxxxxxxxx
web:  <http://www.compaq.co.nz/> http://www.compaq.co.nz 

-----Original Message-----
From: Craig Columbus [mailto:Craig.Columbus@xxxxxxxxxxxxxxxxxxxxxx] 
Sent: Tuesday, 25 September 2001 5:06 a.m.
To: Menga, Justin
Cc: ccielab@xxxxxxxxxxxxxx
Subject: Another IPSec question: VPN client to Router


Hi all,

I'm new to the Cisco VPN client and am experimenting with it.  I'm setting
up a VPN Client 1.1 to 3DES Cisco router.  The setup looks like:

VPN Client PC (Private) -------LinkSys Cable Router (NAT to
public)--------Cisco 3DES Router (NAT to public)----------Internal Network
(Private)

The tunnel is between the VPN Client and the Cisco router.  I can't seem to
get the tunnel to establish.  When doing "debug crypto" commands on the
Cisco router, nothing at all shows up.  Is it somehow related to the double
NAT?  Is it a problem since both private ranges are 192.168.1.0/24?  I'd
think that I'd see errors or failures in the debug, but there's no traffic
at all.  The access-list looks a bit funny to me, but I'm going by the Cisco
VPN configuration guide.

Sanitized Configs are:

Cisco Router:

crypto isakmp policy 3
 encr 3des
 authentication pre-share
crypto isakmp key 12345678 address 192.168.1.105
!
crypto ipsec transform-set vpn-transform esp-3des esp-sha-hmac
!
crypto dynamic-map vpn-dynamic 1
 set transform-set vpn-transform
 match address 101
!
crypto map vpnclient 1 ipsec-isakmp dynamic vpn-dynamic
!
interface Ethernet0
 ip address 192.168.1.75 255.255.255.0
 ip nat inside
 crypto map vpnclient
!
interface ATM0.2 point-to-point
 ip address 1.1.1.2 255.255.255.252
 ip nat outside
!
ip nat inside source list 1 interface ATM0.2 overload
ip classless
ip route 0.0.0.0 0.0.0.0 1.1.1.1
!
access-list 101 permit ip 1.1.1.0 0.0.0.3 host 192.168.1.105

Client configs:

Connection Security: Secure
Remote Party Identity and Addressing:
        ID Type: IP Subnet
        Subnet: 192.168.1.0
        Mask:   255.255.255.0
        Protocol: All
        Connect Using Secure Gateway Tunnel: Yes
                ID Type: IP Address
                Address: 1.1.1.2
Identity:
        Certificate: None
        ID Type: IP address
        Internet Interface: Any
        IP Address: Any
        Preshared Key: 12345678

Security Policy:
        Phase1 Negotiation: Main Mode
        Enable Perfect Forward Secrecy: No
        Enable Replay Detection: Yes
        Authentication (Phase 1):
                Authentication Method: Pre-shared Key
                Encrypt Alg: 3DES
                Hash Alg: SHA-1
                SA Life: Unspecified
                Key Group: Diffie-Hellman Group 1
        Key Exchange (Phase 2):
                SA Life: Unspecified
                Encapsulation Protocol: ESP
                Encrypt Alg: 3DES
                Hash Alg: SHA-1
                Encapsulation: Tunnel
                Authentication Protocol (AH): Not Checked

Thanks in advance for any help or advice!

Craig


At 07:54 PM 9/24/2001 +0800, you wrote:


Basics of tunnel mode IPSec:

You have source traffic that you are protecting - this is known as the
source proxy
You have destination traffic to which the source traffic is sending and is
protected - this is known as the destination proxy
You have a source tunnel endpoint - this terminates the VPN connection from
the source side
You have a destination tunnel endpoint - this terminates the VPN connection
from the destination side

In a simple diagram:

src_proxy----clear
text----src_tunnel_endpoint----encrypted----dst_tunnel_endpoint----clear
text----dst_proxy

Of course, the above is from the point of view of the src_tunnel_endpoint.
The roles are reversed if you look at the dst_tunnel_endpoint point of view.

In this example from the point of view of the router:

Src_Proxy = 10.10.10.0/24 (The loopback)
Src_Tunnel_Endpoint = 129.100.101.71 (The router eth interface)
Dst_Tunnel_Endpoint = 129.100.101.73 (The VPN Client eth interface)
Dst_Proxy = 10.10.1.0/24 (The ISAKMP 'virtual' Client Configuration Address)

When you configure your IPSec access list you are defining what the src to
dest PROXY flow is so that the router knows when to invoke the crypto
process....In this example, the flow from the point-of-view of the router is
10.10.10.0/24 <----> 10.10.1.0/24.   From the point-of-view of the client
the flow is 10.10.1.0/24 <---->10.10.10.0/24.

Hence on your router you must define the access-list as follows:

access-list 101 permit ip 10.10.10.0 0.0.0.255 10.10.1.0 0.0.0.255

FYI - IPSec Transport mode does not have src or dst proxy - these are in
effect the same as the tunnel endpoints.  You could define and use transport
mode by NOT downloading an address to the client and using the 'crypto map
test local-interface loopback 0' command.  Then your current ACLs will at
least work!

Regards 
Justin Menga CCIE #6640 
Network Solutions Architect 
Wireless & E-Infrastructure 
Compaq Computer New Zealand 
DDI: +64-9-918-9381 Mobile: +64-21-349-599 
mailto: justin.menga@xxxxxxxxxx 
web: http://www.compaq.co.nz <http://www.compaq.co.nz/>  
**Please read:http://www.groupstudy.com/list/posting.html
_______________________________________________________
To unsubscribe from the CCIELAB list, send a message to
majordomo@xxxxxxxxxxxxxx with the body containing:
unsubscribe ccielab