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/26/2001
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]


See inline....

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 10:03 a.m.
To: Menga, Justin
Cc: ccielab@xxxxxxxxxxxxxx
Subject: RE: Another IPSec question: VPN client to Router


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/icrwps
k.htm
<http://www.cisco.com/univercd/cc/td/doc/product/iaabu/csvpnc/csvpnsg/icrwps
k.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) 
 
NO - THE ACCESS-LIST ALWAYS READS FROM THE SOURCE TO THE DESTINATION (THE
RETURN TRAFFIC IS IMPLICITLY ACCEPTED).  THE CRYPTO MAP IS ALWAYS APPLIED TO
THE EXIT INTERFACE OF THE IPSEC/ISAKMP TRAFFIC. 




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? 
 
SINCE YOU HAVE THE SAME ADDRESSING ON EITHER SIDE AND NO PUBLIC ADDRESS
SPACE AVAILABLE, YOU'LL JUST NEED TO DO THE NAT AS I'VE DESCRIBED BUT WITH
PRIVATE ADDRESSES AND THEN ENCRYPT BETWEEN THE TWO ENDPOINTS. 




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. 
 
TO GET AROUND THE ADDRESSINGISSUE YOU MUST HAVE STATIC NAT CONFIGURED ON THE
ROUTER SIDE AS THE VPN CLIENT INITIATES THE CONNECTION AND CANNOT CONNECT TO
A HIDE NAT OR TO THE INTERNAL ADDRESSING SINCE IT IS THE SAME.  USE A STATIC
NAT POOL THAT USES PRIVATE ADDRESSING.  



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?
 
NO - A BIT CONFUSED I THINK - THE ISAKMP PRE-SHARED KEY IS NOT AN ADDRESS
ASSIGNMENT MECHANISM.  THE GATEWAY MATCHES THE PRE-SHARED KEY BASED ON THE
SOURCE IP ADDRESS OF THE INITIAL ISAKMP PACKET.  AFTER INITIAL ISAKMP
AUTHENTICATION (I.E. PRE-SHARED KEYS MATCH), YOU CAN OPTIONALLY ASSIGN A
VIRTUAL IP ADDRESS TO THE CLIENT WHICH IS USED AS THE SOURCE ADDRESS FOR
TRAFFIC BEFORE ENCRYPTION - INSTEAD OF USING THE REAL IP ADDRESS OF THE
CLIENT.  I AM SAYING TO USE A VIRTUAL IP ADDRESS BECAUSE OF THE ADDRESS
CONFLICT - THE DECRYPTED TRAFFIC ON THE ROUTER WOULD HAVE A SOURCE OF
192.168.1.105 AND THE SERVER WOULD ARP FOR THAT ADDRESS ON THE RETURN PATH
RATHER THAN SEND BACK TO THE ROUTER.  BY USING A VIRTUAL IP ADDRESS, THE
DECRYPTED TRAFFIC WOULD HAVE A SOURCE OF THE VIP.


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. 
 
DEPENDS ON THE CABLE ROUTER - ESP TRAFFIC IS NOT LIKE TCP OR UDP WHERE A
SESSION ID CAN BE GENERATED FOR A CLIENT-SERVER INTERACTION (ESP DOESN'T
HAVE PORTS) - SO IF YOU HAD MULTIPLE ESP TRAFFIC FLOWS FROM BEHIND THE CABLE
ROUTER, HOW WOULD IT DISTRIBUTE THE RETURN TRAFFIC TO THE CORRECT SOURCE?
ANSWER, YOU NEED A ONE-TO-ONE MAPPING PER VPN CLIENT AND CAN'T USE HIDE NAT
(UNLESS YOUR HIDE NAT TREATS THE SINGLE ESP FLOW AS A ONE-TO-ONE STATIC).
SINCE YOUR CABLE ROUTER HAS DYNAMIC ADDRESSING, YOU CAN'T SPECIFY A SPECIFIC
ISAKMP KEY ON THE CISCO ROUTER, YOU MUST USE
 
crypto isakmp key 12345678 address 0.0.0.0 0.0.0.0
 
THIS ACCEPTS THE ISAKMP KEY FROM ANY PEER ADDRESS - UNSECURE AND SHOULD USE
EXTENDED AUTHENTICATION (XAUTH) AS WELL TO PROVIDE ADDITIONAL
AUTHENTICATION. 




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