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
