From: sam s (samarth_04@hotmail.com)
Date: Wed May 23 2007 - 18:07:16 ART
Hi Tarun,
Thank you for the clarification..
if a firewall is present in the middle(its the nat device too), i should
allow udp 4500 and udp 500 for the phase 1 to be completed if the connection
is originating from the outside....is my understanding right?
Best Wishes,
SAMARTH
>From: "Tarun Pahuja" <pahujat@gmail.com>
>To: "sam s" <samarth_04@hotmail.com>
>CC: ffhaniff@gmail.com, graham@cisco-engineer.com, ccielab@groupstudy.com,
>security@groupstudy.com
>Subject: Re: Ipsec L2L and NAT-T
>Date: Wed, 23 May 2007 16:44:00 -0400
>
>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