From: Tarun Pahuja (pahujat@gmail.com)
Date: Wed May 23 2007 - 23:13:21 ART
Samarth,
IKE Phase 1 only detects, Phase 2 makes a decision if peers on
both ends would use Nat-T or not. Please look at the following link.
http://cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide0918
6a0080110bca.html#1040760
Hope this Helps.
Thanks,
Tarun Pahuja
CCIE#7707(R&S,Security,SP,Voice,Storage)
On 5/23/07, sam s <samarth_04@hotmail.com> wrote:
>
> Hi Tarun,
>
> Thank you again...i am sorry for the many questions...
>
> I wanted to know, when a peer had detected a nat device in the midde
> during
> IKE phase 1, will the ports be changed from udp 500 be to udp 4500 in the
> phase 1?
>
> Best Wishes,
> SAMARTH
>
>
>
> >From: "Tarun Pahuja" <pahujat@gmail.com>
> >Reply-To: "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 17:52:24 -0400
> >
> >Samarth,
> >
> >
> > In order for IPsec to work through a NAT the following
> >ports are recommended to be opened:
> >Internet Key Exchange (IKE) - User Datagram Protocol (UDP) port 500
> >IPsec NAT-T - UDP port 4500
> >Encapsulating Security Payload (ESP) - Internet Protocol (IP) protocol 50
> >
> >Thanks,
> >Tarun Pahuja
> >CCIE#7707(R&S,Security,SP,Voice,Storage)
> >
> >
> >
> >On 5/23/07, sam s <samarth_04@hotmail.com> wrote:
> > >
> > > 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.10arriving
> > > >>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
> >
> >_______________________________________________________________________
> >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