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]


Justin,

Thanks for all your help.  I have some additional information that may 
confuse the issue.  See comments inline.

Craig

At 05:07 AM 9/25/2001 +0800, you wrote:
>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)

I thought about this, but according to the Cisco VPN Client configuration 
documentation 
(http://www.cisco.com/univercd/cc/td/doc/product/iaabu/csvpnc/csvpnsg/icrwpsk.htm) 
it appears that the access-list should be applied to the inside interface 
(ethernet) in the form "permit ip source=outside addresses 
destination=inside addresses)

>
>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

In this case, there are no other public IPs available on either side of the 
equation.  The NAT statement is doing an overload to the ATM interface IP 
on the gateway side and, likewise, the cable router is overloading a single 
IP on the public side.
So, the access-list would be "access-list 101 permit host 1.1.1.2 host 
192.168.1.105", no?

>
>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....

Again, since all inside traffic is overloaded to the outside interface IP 
address, on both gateway side and client side, there are no inside source 
statics.

>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
>

I was under the impression that a pool is only necessary if dynamic 
addressing is used; for static addressing the client would obtain its IP 
based upon the pre-shared key.  In other words, the client sends the 
pre-shared key that corresponds to an IP address.  The gateway then matches 
the pre-shared key using the crypto isakmp key statement and assigns the 
static IP.  Only if you were using a certificate or wildcard key would you 
need to define a dynamic pool.  No?

>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)

I'm not sure I follow this one.  The cable router passes all 
inside-to-outside traffic and all established outside-to-inside 
traffic.  Since the VPN Client will always establish the session, wouldn't 
all correspondence from the gateway be established?  Also, the IP address 
on the outside is not virtual; it will always be a single overloaded static 
assigned by the ISP at session initiation.  Is this a problem for 
Cisco?  VPN1 seems to behave better in this type of situation.

>
>6.  Your VPN Client destination traffic should be 1.1.1.100 and so on, NOT 
>the internal addressing.

1.1.1.100 being the outside nat statics on the cable side?  Again, because 
the ATM IP is overloaded, it would only be 1.1.1.2 in my example.

>
>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
**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