From: Tarun Pahuja (pahujat@gmail.com)
Date: Wed May 23 2007 - 18:52:24 ART
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
This archive was generated by hypermail 2.1.4 : Fri Jun 01 2007 - 06:55:22 ART