From: David Tran (davidtran_mclean@yahoo.com)
Date: Thu May 24 2007 - 07:37:36 ART
R1---Pix----R2 (pix is version 6.3(5) and IOS is 12.2(15)T17)
for VPN to work between R1 and R2 with NAT-T, you need the following:
Pix: static (i,o) public private net /32
access-list outside permit udp host R2 host R1_public eq 500 log
access-list outside permit udp host R2 host R1_public eq 4500 log
access-group outside in interface outside
R1 & R2:
crypto ipsec nat-t udp-encap
NAT-T is enable on routers, by default. That's all you need. VPN will work.
Now if you want to make VPN to work with ESP instead of udp/4500:
Pix: static (i,o) public private net /32
access-list outside permit udp host R2 host R1_public eq 500 log
access-list outside permit esp host R2 host R1_public log
access-group outside in interface outside
R1 & R2:
NO crypto ipsec nat-t udp-encap
Now your VPN will work with ESP
Under NO situation that you should do this:
access-list outside permit udp host R2 host R1_public eq 500 log
access-list outside permit esp host R2 host R1_public log
access-list outside permit udp host R2 host R1_public eq 4500 log
If you do this in the lab, you will fail because it demonstrates that you do not
understand how VPN works. In both situation that I mentioned above, you either
use ESP or UDP/4500 but NOT both at the same time. Therefore, in either case,
you only need 2 ACL lines, not 3.
David
Peter Svidler <doubleccie@yahoo.com> wrote: 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 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.
---------------------------------
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
This archive was generated by hypermail 2.1.4 : Fri Jun 01 2007 - 06:55:22 ART