From: Ron Royston (ccie6824@xxxxxxxxxxx)
Date: Mon Oct 15 2001 - 17:00:02 GMT-3
Encapsulation is when you wrap a header around an existing data unit, or IP
packet. NAT modifies the data unit itself by replacing the IP addressing
portion of the IP header. LAN-to-LAN packets get encapsulated, or tunneled,
not NATed. LAN-to-Internet packets get NATed, or modified.
-Ron
>From: Khalid Nafie <knafie@ncr.com.kw>
>To: Ron Royston <ccie6824@hotmail.com>, ccielab@groupstudy.com
>Subject: RE: IPSEC with NAT
>Date: Mon, 15 Oct 2001 21:55:25 +0300
>
>Ya this really help , but when u said :
> Once your config is setup, LAN-to-LAN packets
>will be encrypted, encapsulated in globally addressed IP headers, and sent
>via the Internet.
>this means that there is natting for this to happened, but the
>configuration
>on the WEB doesn't nat waht is going to be IPSECured, is this right?
>
>-----Original Message-----
>From: Ron Royston [mailto:ccie6824@hotmail.com]
>Sent: Monday, October 15, 2001 9:50 AM
>To: knafie@ncr.com.kw; ccielab@groupstudy.com
>Subject: RE: IPSEC with NAT
>
>
>NAT has a number of applications, but typically it is used to allow
>privately addressed hosts to communicate with the public Internet. NAT is
>necessary in this senario because Internet routers do not have knowledge of
>how to route packets back to private networks, so you've got to have a
>global address as the source IP address in your outbound packets. IPSec
>allows us to choose a subset of traffic to encrypt and tunnel to another
>router. Typically, it's the LAN-to-LAN traffic, privately addressed, that
>we want to encrypt. So, in your case, you want to allow hosts on a local
>private LAN Internet access, and you want to allow them to communicate
>securely with a remote private LAN. Finally, you want to allow 1 host on
>the local private LAN to get all packets addressed for a particular global
>IP address, i.e., to have a global address, or one that users can access
>from the public Internet. Once your config is setup, LAN-to-LAN packets
>will be encrypted, encapsulated in globally addressed IP headers, and sent
>via the Internet. LAN-to-Internet packets will have thier source IP NATed,
>actually PATed, to the global IP of your interface closest to your ISP.
>Remember, your access-lists will determine what packets get NATed (except
>for the static NAT entry), what packets get sent via the IPSec tunnel, and
>they will be employed by the policy routing function to determine what
>subset of traffic gets to bypass NAT. I hope that helps clear this senario
>up.
>
>-Ron
>
>
> >From: Khalid Nafie <knafie@ncr.com.kw>
> >Reply-To: Khalid Nafie <knafie@ncr.com.kw>
> >To: Ron Royston <ccie6824@hotmail.com>, ccielab@groupstudy.com
> >Subject: RE: IPSEC with NAT
> >Date: Mon, 15 Oct 2001 12:56:06 +0300
> >
> >Dear All,
> > Thx for ur replies, now i know the idea behind IPSEC with natting,
> >the idea is not to nat what ur securing through the IPSEC tunnel, in the
> >static natting u have certain procedure to do so, and dynamic natting
>from
> >private to private and from public to private each one has little bit
> >different procedure but all under the same concept, the thing is that
>this
> >is the 1st time that the public network knows about the private addresses
> >because its not natted.
> >I have only one concern i think this is not applicable in real life cos
>how
> >can we route the pakets from public network to private one through the
> >internet.
> >
> >-----Original Message-----
> >From: Ron Royston [mailto:ccie6824@hotmail.com]
> >Sent: Sunday, October 14, 2001 9:18 PM
> >To: knafie@ncr.com.kw; ccielab@groupstudy.com
> >Subject: Re: IPSEC with NAT
> >
> >
> >Unless there is something I am missing, you can get rid of the GRE
>tunnel.
> >Isn't there another active interface on this router, a privately
>addressed
> >one that you wish to NAT to a global? Anyway, NAT w/ IPSec will work
>fine.
> >
> >Use the access-list to specify what traffic gets encrypted and that
> >access-list must be mirrored identically on the IPSec peer. Because you
> >are
> >
> >statically NATing, you'll have some extra configuration. If you were
>just
> >doing NAT, or PATing to your globally addressed interface address, you
> >would
> >
> >simply exlude the LAN-to-LAN packets from the NAT process. But because
>you
> >said 'ip nat inside source static ...', you told the router to NAT a
> >particular internally addressed host to a global address. In that
>senario,
> >packets from the static NAT host destined for the far-end LAN would not
> >match your IPSec access-list, resulting in a packet destined for your
> >private remote network getting sent to the ISPs gateway, and dropped.
> >Create a loopback interface on the router that needs to static NAT, and
>use
> >policy routing on the privately addressed interface to set the ip
>next-hop
> >of statically NATed IP address to the same network (not the host address)
> >of
> >
> >the loopback interface that you created. This allows the router to
>bypass
> >that static NAT statement for those LAN-to-LAN packets only.
> >
> >CCO has a sample:
> >http://www.cisco.com/warp/customer/707/static.html
> >
> >Good luck.
> >
> >-Ron
> >
> >
> > >From: Khalid Nafie <knafie@ncr.com.kw>
> > >Reply-To: Khalid Nafie <knafie@ncr.com.kw>
> > >To: "Ccielab (E-mail)" <ccielab@groupstudy.com>
> > >Subject: IPSEC with NAT
> > >Date: Mon, 15 Oct 2001 02:39:45 +0300
> > >
> > >Dear all,
> > > I was trying IPSEC with NAting on the same router but it didn't
> > >work, its working without the natting but as i introduce natting into
>one
> > >router it doesn't work.
> > >any idea if there is change int the ACL on the nating router?
> > >any working examples?
> > >here is my config
> > >
> > >R7:
> > >
> > >!
> > >crypto isakmp policy 10
> > > authentication pre-share
> > >crypto isakmp key sh-key address 62.7.1.10
> > >!
> > >!
> > >crypto ipsec transform-set trans esp-des esp-md5-hmac
> > >!
> > > !
> > > crypto map toR2 10 ipsec-isakmp
> > > set peer 62.7.1.10
> > > set transform-set trans
> > > match address 110
> > >!
> > >interface Tunnel10
> > > ip address 10.10.1.1 255.255.0.0
> > > no ip directed-broadcast
> > > tunnel source 62.9.3.3
> > > tunnel destination 62.7.1.10
> > > crypto map toR2
> > >!
> > >!interface Ethernet2/0
> > > ip address 62.9.3.3 255.255.0.0
> > > no ip redirects
> > > no ip directed-broadcast
> > > crypto map toR2
> > >!
> > >access-list 110 permit ip host 62.9.3.3 host 62.7.1.10
> > >
> > >R2:
> > >
> > >!
> > >ip nat inside source static 2.2.2.1 62.7.1.10
> > >!
> > >!
> > >crypto isakmp policy 10
> > > authentication pre-share
> > >crypto isakmp key sh-key address 62.9.3.3
> > >!
> > >!
> > >crypto ipsec transform-set trans esp-des esp-md5-hmac
> > >!
> > > !
> > > crypto map toR7 10 ipsec-isakmp
> > > set peer 62.9.3.3
> > > set transform-set trans
> > > match address 110
> > >!
> > >!!
> > >interface Tunnel10
> > > ip address 10.10.1.2 255.255.0.0
> > > tunnel source 62.7.1.10
> > > tunnel destination 62.9.3.3
> > > crypto map toR7
> > >!
> > >interface Serial0
> > > ip address 62.7.1.2 255.255.255.0
> > > ip nat outside
> > > no ip mroute-cache
> > > no fair-queue
> > > clockrate 64000
> > > crypto map toR7
> > >!
> > >access-list 110 permit ip host 62.7.1.10 host 62.9.3.3
> > >================================================
> > >Yours,
> > >Khaled Nafie
> > >Network Engineer
> > >Customer Services
> > >MCSE,CCDP,CCNP VOICE ACCESS
> > >NCR Corporation, Kuwait
> > >Mob.: +965-9872046
> > >Tel : +965- 2412201, 2412203
> > >Fax : +965-2413075
This archive was generated by hypermail 2.1.4 : Thu Jun 20 2002 - 22:33:19 GMT-3