From: Volkov, Dmitry (IDS Canada) (dmitry_volkov@ca.ml.com)
Date: Mon Jun 02 2003 - 10:53:09 GMT-3
Vilmos,
Just click on the link:
http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_63/config
/bafwcfg.htm#1113519
and/or apply config below to any PIX running 6.2/.3
Dmitry Volkov
CCIE # 10292
> -----Original Message-----
> From: Szabo, Vilmos [mailto:VS183600@exchange.UnitedKingdom.NCR.COM]
> Sent: Monday, June 02, 2003 5:42 AM
> To: 'Volkov, Dmitry (IDS Canada)'; 'Scott Morris'
> Cc: ccielab@groupstudy.com; security@groupstudy.com
> Subject: RE: PIX NAT?? - It works
>
>
> I think Dong gave the definite answer.
>
> ... that means dynamic NAT/PAT does not work when traffic comes from
> LowerSec intf. to HigherSec intf. (alias INBOUND). If this
> would be the
> requirement then STATIC NAT + ACL( or CONDUIT) must be used.
>
> ... and because using PAT on INSIDE interface would mean
> DYNAMIC NAT for
> INBOUND traffic therefore simply it should not work, in other
> words it is
> not supported.
>
> Vilmos
>
> P.S. It is just for curiosity a question. Why must we add the
> 'outside'
> option at the end of the nat definition when we already defined the
> interface in the 'if_name' parameter?
>
>
>
> -----Original Message-----
> From: Volkov, Dmitry (IDS Canada) [mailto:dmitry_volkov@ca.ml.com]
> Sent: 01 June 2003 23:35
> To: 'Scott Morris'
> Cc: ccielab@groupstudy.com; security@groupstudy.com
> Subject: RE: PIX NAT?? - It works
>
>
> > -----Original Message-----
> > From: Scott Morris [mailto:swm@emanon.com]
> > Sent: Saturday, May 31, 2003 10:56 PM
> > To: 'Volkov, Dmitry (IDS Canada)'; 'Dong Lin'
> > Cc: ccielab@groupstudy.com; michael625@cox.net;
> > security@groupstudy.com
> > Subject: RE: PIX NAT??
>
> Scott,
>
> I didn't quite understand You. Could You please explain it ?
> Maybe some
> example ?
>
> > Order of NAT... Traffic must come in prior to NAT xlate
> existing. A
> > static command will pre-populate. Try static on your
> inside guys and
> > then the outside should work. At that point, your local host would
> > think it were being ping'ed by the PIX.
>
> Actually I did a few tests and that's what I found:
>
> We know that for traffic flows from High Sec to the Lower Sec
> interface -
> nat and global should be configured or static nat (conduit as well)
> In case we don't want NAT we have to use "nat (inside) 0"
> The principle is - to be able to pass traffic via PIX we HAVE
> to configure
> NAT in some way.
> Here it's said:
> http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_
> sw/v_63/config
> /bafwcfg.htm#1113519
> "Use a natid of 0 with the outside option to disable address
> translation of
> hosts residing on the lower security interface. Use this
> option only if
> outside dynamic NAT is configured on the interface. By
> default, address
> translation is automatically disabled for hosts connected to the lower
> security interface."
>
> We don't see "nat (outside) 0" but it's there. On Higher Sec
> interface it
> should be define explicitly (if we want it)
> In normal setup we have internal networks PAT'd behind
> outside and returning
> packets are not additionally
> translated (because : "By default, address translation is
> automatically
> disabled for hosts connected to the lower security interface") and
> translated back using PAT we configured.
> PIX will veryfy if translation already exists and if it
> doesn't it will
> check "nat (interface) 0" if packet match it will proceed.
>
> So I added "nat (inside) 0 acl" and "nat (outside) 0 acl
> outside" and I got
> 2 PATs working both ways.
> The Idea here - Packets going through PIX and being PAT'd
> should come back
> without any additional translation:
> we have to use "nat (interface) 0"
> If we have network(s) A and we PAT it in one way and we have
> network(s) B
> and we PAT them in the other way,
> these networks : A and B will not be able to talk to each other.
> I believe it's true for any firewall. Checkpoint works the same way.
>
> Here is config:
> Test-Host(172.16.50.100)------(in)PIX(out)-----Test-Host(172.1
> 6.10.100)
> Net 172.16.50.64/26 is PAT'd on outside interface and accesses Net
> 172.16.10.0/29
> Net 172.16.10.64/26 is PAT'd on inside interface and accesses Net
> 172.16.50.0/29
>
> access-list 2-OUTSIDE permit ip 172.16.50.0 255.255.255.192 any
> access-list 2-INSIDE permit ip 172.16.10.0 255.255.255.192 any
> ip address outside 172.16.10.10 255.255.255.0
> ip address inside 172.16.50.1 255.255.255.0
> global (outside) 1 interface
> global (inside) 2 interface
> nat (outside) 0 access-list 2-INSIDE outside
> nat (outside) 2 172.16.10.64 255.255.255.192 outside 0 0
> nat (inside) 0 access-list 2-OUTSIDE
> nat (inside) 1 172.16.50.64 255.255.255.192 0 0
> conduit permit ip any any
>
> ping from 172.16.50.100 to 172.16.10.1
> 609001: Built local-host inside:172.16.50.100
> 305011: Built dynamic ICMP translation from
> inside:172.16.50.100/768 to
> outside:172.16.10.10/6
>
> ping from 172.16.10.100 to 172.16.50.5
> 609001: Built local-host inside:172.16.50.5
> 609001: Built local-host outside:172.16.10.100
> 305011: Built dynamic ICMP translation from
> outside:172.16.10.100/512 to
> inside:172.16.50.1/67
> sh xlate
> 2 in use, 20 most used
> PAT Global 172.16.50.1(67) Local 172.16.10.100 ICMP id 512
> PAT Global 172.16.10.10(6) Local 172.16.50.100 ICMP id 768
>
> a few more telnet sessions:
> PAT Global 172.16.50.1(1024) Local 172.16.10.100(4593)
> PAT Global 172.16.50.1(1026) Local 172.16.10.100(4608)
> PAT Global 172.16.10.10(1025) Local 172.16.50.100(1077)
> PAT Global 172.16.10.10(1) Local 172.16.50.100(137)
> PAT Global 172.16.10.10(1024) Local 172.16.50.100(1075)
>
> As far as I understand 6.3 allows to use ACL with nat
> statement other than
> "0":
> "nat interface natid access-list acl-name outside" - It seems
> to be mach
> more flexible.
>
> Dmitry
>
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
> > Behalf Of
> > Volkov, Dmitry (IDS Canada)
> > Sent: Saturday, May 31, 2003 10:15 PM
> > To: 'Dong Lin'
> > Cc: ccielab@groupstudy.com; 'michael625@cox.net';
> > 'security@groupstudy.com'
> > Subject: RE: PIX NAT??
> >
> >
> > http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_
> > sw/v_62/co
> > nfig
> > /bafwcfg.htm#1063701
> > Starting with PIX Firewall version 6.2, NAT and PAT can be
> applied to
> > traffic from an outside or less secure interface to an inside (more
> > secure) interface. This functionality is called Outside NAT
> > However I just tried it with 6.21 - no luck :(
> >
> > ip address outside 172.16.10.10 255.255.255.0
> > ip address inside 172.16.50.1 255.255.255.0
> > global (inside) 1 interface
> > nat (outside) 1 172.16.10.64 255.255.255.192 outside 0 0
> > conduit permit
> > ip any any No translation group found for icmp src
> > outside:172.16.10.100
> > dst inside:172.16.50.5 (type 8, code 0)
> >
> > > -----Original Message-----
> > > From: Dong Lin [mailto:dlin22@comcast.net
> > > Sent: Saturday, May 31, 2003 8:10 PM
> > > To: ccielab@groupstudy.com
> > > Subject: Re: PIX NAT??
> > >
> > >
> > > The answer to your question is no.
> > >
> > > nat and global is used to let traffic from high security
> > > interface to low
> > > security interface.
> > >
> > > You need to use static and acl to let traffic from the
> > > outside interface to
> > > the inside interface (nat is performed by static command)
> > >
> > >
> > > ----- Original Message -----
> > > From: "Michael Popovich" <michael625@cox.net>
> > > To: <ccielab@groupstudy.com>
> > > Sent: Saturday, May 31, 2003 4:19 AM
> > > Subject: PIX NAT??
> > >
> > >
> > > > Can you NAT from the Outside interface to the Inside interface?
> > > >
> > > > I have:
> > > >
> > > > nat (outside) 1 0.0.0.0 0.0.0.0
> > > > global (inside) 1 interface
> > > >
> > > > This doesn't seem to work for me, now I am wondering if it
> > > is possible.
> > > >
> > > > MP
This archive was generated by hypermail 2.1.4 : Fri Jul 04 2003 - 11:10:51 GMT-3