[c-nsp] question about natting ipsec traffic on pix 506E

Dave Weis djweis at internetsolver.com
Thu Dec 1 06:21:28 EST 2011


Check the list archives, I configured basically the same thing 6-12 months ago, probably for the same telco. If you don't find it I'll see if I can track down my functional config.

Dave

 

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net 
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Peter Rathlev
> Sent: Thursday, December 01, 2011 2:29 AM
> To: dalton
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] question about natting ipsec traffic on pix 506E
> 
> On Wed, 2011-11-30 at 20:01 -0500, dalton wrote:
> > access-list client1 permit ip host 209.1.1.157 host 200.1.1.2 
> > access-list client1 permit ip host 209.1.1.158 host 200.1.1.2 
> > access-list EXCLUDE-NAT permit ip host 209.1.1.157 host 200.1.1.2 
> > access-list EXCLUDE-NAT permit ip host 209.1.1.158 host 200.1.1.2
> > 
> > nat (inside) 0 access-list EXCLUDE-NAT
> 
> Here you're saying that traffic coming in on the "inside" 
> interface with a source address of 209.1.1.{157,158} destined 
> to 200.1.1.2 should not be translated.
> 
> Those source addresses are globally routable addresses. Are 
> you sure you would expect to see those coming in on the 
> inside interface? If so, the next "static" statements don't 
> make sense to me:
> 
> > static (inside,outside) 209.1.1.157 10.0.0.129 dns netmask 
> > 255.255.255.255 0 0 static (inside,outside) 209.1.1.158 
> 10.0.0.130 dns 
> > netmask 255.255.255.255 0 0
> 
> These statics translate traffic coming in on the "inside" 
> interface with source addresses 10.0.0.{129,130} to 
> 209.1.1.{157,158}. And vice versa.
> This configuration isn't impossible, but it's not highly 
> intuitive either.
> 
> > crypto map statmap 120 ipsec-isakmp
> > crypto map statmap 120 match address client1 crypto map statmap 120 
> > set peer 200.1.1.1 crypto map statmap 120 set pfs group2 crypto map 
> > statmap 120 set transform-set strong
> >    
> > I want to nat the 10.0.0.129 and 130 traffic to 
> 209.1.1.157/158 before 
> > it goes through the tunnel.
> > 
> > In the acl for interesting traffic do i want he real (private ips -
> > 10.0.0.129) here? or the natted ips (209.1.1.157)?
> 
> Assuming the crypto map is applied to the "outside" 
> interface, you would use the translated IP addresses 
> (209.1.1.{157,158}). The crypto stuff happens after the NAT 
> stuff (both static and global).
> 
> > Also, for my nat 0 list, do i want the that natted ip in 
> there? or the 
> > real ips.
> 
> Why do you need the NAT-0 at all?
> 
> If you can accept that the hosts 10.0.0.{129,130} always have 
> the 209.1.1.{157,158} addresses when trying to reach things 
> on your outside
> (Internet?) you just delete the policy-NAT related lines.
> 
> Or do these globally routable addresses belong to the other 
> end of the tunnel, so you need to only ever use them for 
> traffic traversing the tunnel?
> 
> By the way: Are these addresses the real ones? Or examples? 
> If the latter, you should generally try to use 192.0.2.0/24 
> (there are a few others too) for examples. Otherwise the 
> holders of 209.1.0.0/16 or
> 200.1.0.0/22 might find it strange to see their addresses 
> used here. :-)
> 
> --
> Peter
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 


More information about the cisco-nsp mailing list