From: sam s (samarth_04@hotmail.com)
Date: Wed May 23 2007 - 16:55:13 ART
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