From: sam s (samarth_04@hotmail.com)
Date: Thu May 24 2007 - 04:41:42 ART
Hi Perer,
When i was working on a lab scenario which had a nat device in the middle
yesterday...I had to allow udp 4500 udp 500 for the phase 1 to
occur...however phase 2 was setup and esp was used...I think that this may
be the default behavior of phase 1...
So i allowed all the 3 for it to work. i did not choose to encapsulate the
esp packets with udp 4500..
http://www3.ietf.org/proceedings/02jul/I-D/draft-ietf-ipsec-nat-t-ike-03.txt
.
.
.
ISAKMP (0:1) : constructed HIS NAT-D
ISAKMP (0:1) : constructed MINE NAT-D
.
.
ISAKMP (0:1) : NAT does not match MINE hash
.
.
.
ISAKMP (0:1) : Detected NAT-D payload
.
.
.
ISAKMP (0:1) : sending packet to 192.1.112.10 my_port 4500 peer_port 4500
(I) MM_KEY_EXCH
.
.
.
ISAKMP (0:1) : received packet from 192.1.112.10 dport 4500 sport 4500
(I) MM_KEY_EXCH
Best wishes,
SAMARTH
>From: Peter Svidler <doubleccie@yahoo.com>
>To: sam s <samarth_04@hotmail.com>
>CC: ccielab@groupstudy.com, security@groupstudy.com
>Subject: Re: Ipsec L2L and NAT-T
>Date: Thu, 24 May 2007 00:18:10 -0700 (PDT)
>
>HI Sam ;
> According to my testing only and someone can correct me if i m wrong
>...if you are using IPSEC over UDP , the tunnel will come up even if you
>are not enabling port UDP 10000 across the FW , however you won't be able
>to exchange any information over that tunnel till that port is open , same
>will apply to NAT-T with port 4500
>
> if you are using IPSEC over TCP , the tunnel will not come up until you
>open port 10000 right from the start .
>
>
> this is based only on my testing ..not sure if it is documented anywhere
>
>
>therefore , you need to enable ESP ,ISAKMP and UDP 4500 all together for
>NAT-T to work
>
>
>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"
>
> >Reply-To: "Tarun Pahuja"
>
> >To: "sam s"
> >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 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"
>
> > > >To: "sam s"
> > > >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 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"
>
> > > >> >Reply-To: "Tarun Pahuja"
>
> > > >> >To: ffhanif
> > > >> >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 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
> > > >>wrote:
> > > >> > > >
> > > >> > > > With regards to preventing ip spoofing;
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > > Does the:
> > > >> > > >
> > > >> > > > ip verify unicast reverse-path
> > > >> > > >
> > > >> > > > serve the same function as a :
> > > >> > > >
> > > >> > > > Deny ip 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 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
>
>
>
>
>---------------------------------
>Don't get soaked. Take a quick peak at the forecast
> with theYahoo! Search weather shortcut.
This archive was generated by hypermail 2.1.4 : Fri Jun 01 2007 - 06:55:22 ART