From: Kenny Sallee (kenny@xxxxxxxxxxxxxx)
Date: Tue Feb 05 2002 - 19:23:01 GMT-3
In the case study mentioned below, they were beginning the encrypted tunnel
on the same device that was performing NAT. And Cisco NAT'd the packet
before the IPSec process took over. So it's a little different then
allowing an IPsec tunnel 'through' a NAT device. It'd be more like
"Allowing and IPSec tunnel to 'begin' on the NAT device." Big diff...
Actually the way I understand this issue is that the encrypted packet
doesn't have TCP/UDP headers that NAT (specifically PAT) processes need to
manipulate in order to change the source address and port to the NAT'd
address. And, the IP protocol is esp/ahp or 50/51. NAT only plays with 4
(ip). So the NAT'ing device gets a packet with an 'unknown' protocol type
and pukes. Also, in order for ISAKMP to work, in a NAT situation you have
to port forward udp/500 to the encrypting host. So in short, to do IPSec
through nat you need to have a NAT gateway that recognizes IPSec and port
forwarding to the encrypting host. I know you can configure a Linux kernel
to support IPSec pass-thru and port forward ISAKMP ( which is what I do @
home ).
Some of the newer client ( Cisco VPN3000 client to concentrator come to mind
) let you basically tell it that it's behind NAT and to not encapsulate the
entire packet, just the packet data. Here's a link with a quick explantion
of the problem and how the 3000 concentrator addresses the problem:
http://www.cisco.com/warp/public/471/nat_trans.html
Hope this makes sense...
Kenny
-----Original Message-----
From: Scott Morris [mailto:swm@emanon.com]
Sent: Tuesday, February 05, 2002 10:32 AM
To: RSiddappa@NECBNS.com; tkc9789@hotmail.com; ccielab@groupstudy.com;
jkaberna@netcginc.com; erickbe@yahoo.com; signal@shreve.net;
cchurch@MAGNACOM.com; ben@kesslerconsulting.com
Subject: RE: IPSec & NAT (Does this)
Because you're trying to validate the packet and say "it hasn't been changed
or manipulated". Then you go through NAT, and change/manipulate the IP
address. :)
That's one reason, but likely the most obvious.
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
RSiddappa@NECBNS.com
Sent: Tuesday, February 05, 2002 11:33 AM
To: tkc9789@hotmail.com; ccielab@groupstudy.com; jkaberna@netcginc.com;
erickbe@yahoo.com; signal@shreve.net; cchurch@MAGNACOM.com;
ben@kesslerconsulting.com
Subject: RE: IPSec & NAT (Does this)
I understnd that.
But now the question is more than that.
WHY DOES IPSec does not work with NAT. I guess both in tunnel and transport
mode.
Rajeev.
-----Original Message-----
From: tom cheung [mailto:tkc9789@hotmail.com]
Sent: Tuesday, February 05, 2002 9:38 AM
To: Siddappa, Rajeev; ccielab@groupstudy.com; jkaberna@netcginc.com;
erickbe@yahoo.com; signal@shreve.net; cchurch@MAGNACOM.com;
ben@kesslerconsulting.com
Subject: Re: IPSec & NAT (Does this)
This sample config is for "encrypt traffic between between two private
networks (10.50.50.x and 10.103.1.x) using IP Security (IPSec). The networks
know each other by their private addresses." They talk to each other using
the *private addresses*, not the NATted addresses.
>From: RSiddappa@NECBNS.com
>To: tkc9789@hotmail.com, ccielab@groupstudy.com, jkaberna@netcginc.com,
>erickbe@yahoo.com, signal@shreve.net, cchurch@MAGNACOM.com,
>tkc9789@hotmail.com, ben@kesslerconsulting.com
>Subject: IPSec & NAT (Does this)
>Date: Tue, 5 Feb 2002 08:26:28 -0700
>
>
>Hi Guys
>
>I am coming back with the same doubt again, but little different.
>
> >> >http://www.cisco.com/warp/customer/707/overload_private.shtml
>
>In the above link the packets which have to be encrypted is denied from
>getting any NATed address.
>
>But why does IPSec really does not work when u NAT ?
>
>In this above example if I Add one more access-list which says,
>permit all the traffic going out to internet to be NATed and also one more
>access-list to encrypt all the traffic going to destination 10.X.X.x (
>Private address) after NTAing.
>
>WILL THE IPSec will work after this.
>
>Pls do respond.
>
>www.agilent.com/comms/casestudies
>
>I guess all the other vendors are having the same problem.
>
>Thank you,
>
>Rajeev.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>-----Original Message-----
>From: tom cheung [mailto:tkc9789@hotmail.com]
>Sent: Saturday, February 02, 2002 9:02 PM
>To: Siddappa, Rajeev; ccielab@groupstudy.com
>Subject: RE: IPSec & NAT
>
>
>Correction, in transport mode, depending whether you're using ESP or AH,
>the payload will or will not be encrypted.
>
>
> >From: "tom cheung" <tkc9789@hotmail.com>
> >Reply-To: "tom cheung" <tkc9789@hotmail.com>
> >To: RSiddappa@NECBNS.com, ccielab@groupstudy.com
> >Subject: RE: IPSec & NAT
> >Date: Sat, 02 Feb 2002 20:48:06 -0600
> >
> >Hummm, in transport mode, the IPSec header is inserted between the
> >original
> >header and the payload. Everything gets authenticated but not encrypted.
> >It should still work router to router, but I'm not sure the PIX supports
> >transport mode. Somebody correct me if I'm wrong.
> >
> >Tom
> >
> >>From: RSiddappa@NECBNS.com
> >>To: tkc9789@hotmail.com, erickbe@yahoo.com, ccielab@groupstudy.com,
> >>erickbe@yahoo.com, signal@shreve.net, cchurch@MAGNACOM.com,
> >>jkaberna@netcginc.com, tkc9789@hotmail.com, ben@kesslerconsulting.com
> >>Subject: RE: IPSec & NAT
> >>Date: Sat, 2 Feb 2002 20:41:20 -0600
> >>
> >>
> >>
> >>Tom
> >>
> >>U are absolutely right.
> >>
> >>Little more work for evry one:
> >>
> >>what happens if this was an transport mode ?
> >>
> >>Rajeev.
> >>
> >>
> >>
> >>-----Original Message-----
> >>From: tom cheung [mailto:tkc9789@hotmail.com]
> >>Sent: Saturday, February 02, 2002 8:38 PM
> >>To: Siddappa, Rajeev; erickbe@yahoo.com; ccielab@groupstudy.com
> >>Subject: RE: IPSec & NAT
> >>
> >>
> >>I'll take a crack at this.
> >>Typically, gateway to gateway IPSec tunnel are in tunnel mode, with the
> >>original IP header encapsulated with a new IPSec header. The address of
> >>new
> >>IPSec header will be the tunnel endpoint you defined. Therefore,
> >>depending
> >>on how you have the IPSec tunnel setup, it may or may not have the
> >>registered addresses. To your second point, if you allow everything to
>be
> >>natted, then nothing will be sent over IPSec as nothing matches
> >>access-list
> >>115.
> >>
> >>
> >> >From: RSiddappa@NECBNS.com
> >> >Reply-To: RSiddappa@NECBNS.com
> >> >To: erickbe@yahoo.com, signal@shreve.net, cchurch@MAGNACOM.com
> >> >CC: ccielab@groupstudy.com
> >> >Subject: RE: IPSec & NAT
> >> >Date: Sat, 2 Feb 2002 19:11:11 -0700
> >> >
> >> >Erick,
> >> >
> >> >I got you.
> >> >
> >> >But One more doubt, what will be the destination address of the packet
> >> >address from private to a private network.
> >> >Will the encrypted packet will have a public IP address assigned to it
>?
> >> >and
> >> >then gets decrypted at the other end.
> >> >
> >> >What will happen if I allow that packet to get NATed and after that
> >>IPSec.
> >> >(Private addressed traffic)
> >> >
> >> >Rajeev.
> >> >
> >> >
> >> >
> >> >
> >> >-----Original Message-----
> >> >From: Erick B. [mailto:erickbe@yahoo.com]
> >> >Sent: Saturday, February 02, 2002 8:04 PM
> >> >To: Siddappa, Rajeev; signal@shreve.net; cchurch@MAGNACOM.com
> >> >Cc: ccielab@groupstudy.com
> >> >Subject: Re: IPSec & NAT
> >> >
> >> >
> >> >Hi,
> >> >
> >> >Traffic from network 10.50.50.x/24 to network
> >> >10.103.1.x/24 will not be NAT'd. Traffic from network
> >> >10.50.50.x/24 to any other network besides
> >> >10.103.1.x/24 will be NAT'd. Vice versa for other
> >> >router.
> >> >
> >> >This way the 2 private 10.x networks can communicate
> >> >with each other, and traffic from/to other networks
> >> >will get a 99.99.99.x address which is public IP
> >> >space.
> >> >
> >> >HTH, Erick
> >> >
> >> >--- RSiddappa@NECBNS.com wrote:
> >> > > hi Guys,
> >> > >
> >> > > Can some one explain me what's happing with the
> >> > > following 110 access-list.
> >> > >
> >> > >
> >> >http://www.cisco.com/warp/customer/707/overload_private.shtml
> >> > >
> >> > >
> >> > >
> >> > > Rajeev.
> >> > >
This archive was generated by hypermail 2.1.4 : Thu Jun 20 2002 - 13:46:12 GMT-3