From: Tarun Pahuja (pahujat@gmail.com)
Date: Wed May 23 2007 - 17:44:00 ART
Samarth,
*IKE Phase 1 Negotiation: (NAT Detection)
*The peers sends a payload with hashes of the IP address and port of both
the source and destination address from each end. If both ends calculate the
hashes and the hashes match, each peer knows that a NAT device does not
exist on the network path between them. If the hashes do not match ,then
each peer needs to perform NAT traversal to get the IPSec packet through the
network.
*IKE Phase 2 Negotiation: (NAT Traversal Decision)*
IKE phase 2 decides whether or not the peers at both ends will use NAT
traversal. Quick Mode security association (SA) payload is used for NAT
traversal negotiation. Because the NAT device changes the IP address and
port number, incompatibilities between NAT and IPSec can be created. Thus,
exchanging the original source address bypasses any incompatibilities.
Hope this helps.
Thanks,
Tarun Pahuja
CCIE#7707(R&S,Security,Voice,SP,Storage)
On 5/23/07, sam s <samarth_04@hotmail.com> wrote:
>
> Hi Tarun,
>
> Can you plz give a clear view on how NAT-T negotiation is done for L2L
> tunnel (using preshare keys and tunnel mode) between 2 routers when one of
> the router (or a tunnel end point) is behind a nat device...
>
> Is nat t negotiated in the phase 1 IKE and the ports are changed in the
> phase 1 to udp 4500 (ie floating IKE) automatically ?
> What happens during phase 2 regarding the use of nat t?
> Does phase 1 automatically negotiate nat-t for phase 2?
>
> I appreciate your help for the above clarifications..
>
>
> Best Wishes,
> SAMARTH
>
> >From: "Tarun Pahuja" <pahujat@gmail.com>
> >Reply-To: "Tarun Pahuja" <pahujat@gmail.com>
> >To: ffhanif <ffhaniff@gmail.com>
> >CC: graham@cisco-engineer.com, ccielab@groupstudy.com
> >Subject: Re: Preventing Spoof Attacks
> >Date: Wed, 23 May 2007 15:14:48 -0400
> >
> >Graham,
> > uRPF Checks to See if the Source Address's Reverse Path
> >Matches the Input Port. Source Address Must Match the FIB and Adjacency
> >Information in the CEF Table.
> >
> >Source IP packets are checked to ensure that the route back to the
> source
> >uses the same interface
> >Requires CEF
> >Not always appropriate where asymmetric paths exist
> >
> >Hope this helps.
> >Tarun Pahuja
> >CCIE#7707(R&S,Security,SP,Voice,Storage)
> >
> >
> >
> >
> >On 5/23/07, ffhanif <ffhaniff@gmail.com> wrote:
> > >
> > > I thought this might be useful:
> > >
> > >
> > >
> >
>
http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapt
> >er09186a00804fdef9.html
> > >
> > > Unicast RPF with Inbound and Outbound Filters Example
> > >
> > > The following example uses a very simple single-homed ISP to
> demonstrate
> > > the
> > > concepts of ingress and egress filters used in conjunction with
> Unicast
> > > RPF.
> > > The example illustrates an ISP-allocated classless interdomain routing
> > > (CIDR) block 209.165.202.128/28 that has both inbound and outbound
> >filters
> > > on the upstream interface. Be aware that ISPs are usually not
> > > single-homed.
> > > Hence, provisions for asymmetrical flows (when outbound traffic goes
> out
> > > one
> > > link and returns via a different link) need to be designed into the
> > > filters
> > > on the border routers of the ISP.
> > >
> > > ip cef distributed
> > >
> > > !
> > >
> > > interface Serial 5/0/0
> > >
> > > description Connection to Upstream ISP
> > >
> > > ip address 209.165.200.225 255.255.255.252
> > >
> > > no ip redirects
> > >
> > > no ip directed-broadcast
> > >
> > > no ip proxy-arp
> > >
> > > ip verify unicast reverse-path
> > >
> > > ip access-group 111 in
> > >
> > > ip access-group 110 out
> > >
> > > !
> > >
> > > access-list 110 permit ip 209.165.202.128 0.0.0.31 any
> > >
> > > access-list 110 deny ip any any log
> > >
> > > access-list 111 deny ip host 0.0.0.0 any log
> > >
> > > access-list 111 deny ip 127.0.0.0 0.255.255.255 any log
> > >
> > > access-list 111 deny ip 10.0.0.0 0.255.255.255 any log
> > >
> > > access-list 111 deny ip 172.16.0.0 0.15.255.255 any log
> > >
> > > access-list 111 deny ip 192.168.0.0 0.0.255.255 any log
> > >
> > > access-list 111 deny ip 209.165.202.128 0.0.0.31 any log
> > >
> > > access-list 111 permit ip any any
> > >
> > > Unicast RPF with ACLs and Logging Example
> > >
> > > The following example demonstrates the use of ACLs and logging with
> > > Unicast
> > > RPF. In this example, extended ACL 197 provides entries that deny or
> > > permit
> > > network traffic for specific address ranges. Unicast RPF is configured
> >on
> > > interface Ethernet0 to check packets arriving at that interface.
> > >
> > > For example, packets with a source address of 192.168.201.10 arriving
> at
> > > interface Ethernet0 are dropped because of the deny statement in ACL
> >197.
> > > In
> > > this case, the ACL information is logged (the logging option is turned
> >on
> > > for the ACL entry) and dropped packets are counted per interface and
> > > globally. Packets with a source address of 192.168.201.100 arriving at
> > > interface Ethernet0 are forwarded because of the permit statement in
> ACL
> > > 197. ACL information about dropped or suppressed packets is logged
> > > (logging
> > > option turned on for the ACL entry) to the log server.
> > >
> > > ip cef distributed
> > >
> > > !
> > >
> > > int eth0/1/1
> > >
> > > ip address 192.168.200.1 255.255.255.0
> > >
> > > ip verify unicast reverse-path 197
> > >
> > > !
> > >
> > > int eth0/1/2
> > >
> > > ip address 192.168.201.1 255.255.255.0
> > >
> > > !
> > >
> > > access-list 197 deny ip 192.168.201.0 0.0.0.63 any log-input
> > >
> > > access-list 197 permit ip 192.168.201.64 0.0.0.63 any log-input
> > >
> > > access-list 197 deny ip 192.168.201.128 0.0.0.63 any log-input
> > >
> > > access-list 197 permit ip 192.168.201.192 0.0.0.63 any log-input
> > >
> > > access-list 197 deny ip host 0.0.0.0 any log
> > >
> > >
> > >
> > >
> > > On 5/17/07, graham@cisco-engineer.com <graham@cisco-engineer.com>
> wrote:
> > > >
> > > > With regards to preventing ip spoofing;
> > > >
> > > >
> > > >
> > > > Does the:
> > > >
> > > > ip verify unicast reverse-path
> > > >
> > > > serve the same function as a :
> > > >
> > > > Deny ip <inside ip's> <inside mask> any
> > > >
> > > >
> > > >
> > > > If asked in the lab to prevent spoof attacks on an a subnet from the
> > > > outside, which is the "most correct" method to use or are both
> >perfectly
> > > > valid methods
> > > >
> > > >
> > > > _____
> > > >
> > > > I am using the free version of SPAMfighter for private users.
> > > > It has removed 742 spam emails to date.
> > > > Paying users do not have this message in their emails.
> > > > Try SPAMfighter <http://www.spamfighter.com/len> for free now!
> > > >
> > > >
> >_______________________________________________________________________
> > > > Subscription information may be found at:
> > > > http://www.groupstudy.com/list/CCIELab.html
> > >
> > >
> _______________________________________________________________________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> >
> >_______________________________________________________________________
> >Subscription information may be found at:
> >http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Jun 01 2007 - 06:55:22 ART