|
|
 FAQ
 Search
 Memberlist
 Usergroups
 Register
 Profile
 Private messages
 Log in
|
|
| Author |
Message |
Natan
Guest
|
 Posted: Fri Apr 28, 2006 2:50 am Post subject: NAT/PAT not working in PIX 515 |
 |
|
Hi. We've got an old Cisco PIX 515 (not 515E) and I'm having a hard
time setting it up.
I have 3 interfaces, outside (sec 0) with a public address, dmz (sec
75) in 192.168.0.0/24 and inside (sec 100) with 192.168.10.0/24
I will access DMZ from inside with our current private ip address, so I
have this to make dmz range visible to inside:
static (dmz, inside) 192.168.0.0 192.168.0.0 netmask 255.255.255.0
access-list acl-dmz permit ip 192.168.10.0 255.255.255.0 any
access-group acl-dmz in interface dmz
And some servers in DMZ will be accessible from outside using static
PAT, so I have:
static (dmz,outside) tcp <public ip> www 192.168.0.12 www netmask
255.255.255.255
access-list acl-out permit tcp any host <public ip> eq www
access-list acl-out permit icmp any any
access-group acl-out in interface outside
Wel.. It is not working. I cannot ssh or ping any host from inside to
dmz (although i can ping from pix to any place). And I cannot connect
to my web server from outside.
Is this enough? What am I doing wrong?
Thanks. |
|
| Back to top |
|
 |
|
|
Christoph Gartmann
Guest
|
| Posted: Fri Apr 28, 2006 6:57 am Post subject: Re: NAT/PAT not working in PIX 515 |
|
|
In article <1146192351.518774.7590@u72g2000cwu.googlegroups.com>, "Natan" <nvivo@mandic.com.br> writes:
| Quote: | Hi. We've got an old Cisco PIX 515 (not 515E) and I'm having a hard
time setting it up.
|
Which software version do you run?
| Quote: | I have 3 interfaces, outside (sec 0) with a public address, dmz (sec
75) in 192.168.0.0/24 and inside (sec 100) with 192.168.10.0/24
I will access DMZ from inside with our current private ip address, so I
have this to make dmz range visible to inside:
static (dmz, inside) 192.168.0.0 192.168.0.0 netmask 255.255.255.0
|
I would say it is:
static( inside, dmz ) 192.168.10.0 192.168.10.0 netmask 255.255.255.0
| Quote: | access-list acl-dmz permit ip 192.168.10.0 255.255.255.0 any
access-group acl-dmz in interface dmz
And some servers in DMZ will be accessible from outside using static
PAT, so I have:
static (dmz,outside) tcp <public ip> www 192.168.0.12 www netmask
255.255.255.255
|
Here it should be:
nat( dmz, 1 ) 192.168.0.0 255.255.255.0
nat( inside, 2 ) 192.168.10.0 255.255.255.0
And now something like this:
global( outside, 1 ) your.public.ip.address
global( outside, 2 ) your.second.ip.address
Regards,
Christoph Gartmann
--
Max-Planck-Institut fuer Phone : +49-761-5108-464 Fax: -452
Immunbiologie
Postfach 1169 Internet: gartmann@immunbio dot mpg dot de
D-79011 Freiburg, Germany
http://www.immunbio.mpg.de/home/menue.html |
|
| Back to top |
|
|
Walter Roberson
Guest
|
| Posted: Fri Apr 28, 2006 7:50 am Post subject: Re: NAT/PAT not working in PIX 515 |
|
|
In article <1146192351.518774.7590@u72g2000cwu.googlegroups.com>,
Natan <nvivo@mandic.com.br> wrote:
| Quote: | Hi. We've got an old Cisco PIX 515 (not 515E) and I'm having a hard
time setting it up.
I have 3 interfaces, outside (sec 0) with a public address, dmz (sec
75) in 192.168.0.0/24 and inside (sec 100) with 192.168.10.0/24
I will access DMZ from inside with our current private ip address, so I
have this to make dmz range visible to inside:
static (dmz, inside) 192.168.0.0 192.168.0.0 netmask 255.255.255.0
|
When you go from a higher security interface to a lower security
interface, by default the *destination* IPs do not get NAT'd but the source IPs
(the "inside" IP range) do. Therefore in order to access the DMZ from the
inside, all you need to do is to configure the NAT:
nat (inside) 1 192.168.10.0 255.255.255.0
global (dmz) 1 interface
The static that you have configured is a "reverse static" for "reverse NAT".
Normally in a static statement, the first interface listed is the higher security
interface and the second is the lower security interface; you have reversed
the order. Reversing the order is legal from 6.2 onwards, and what it
would mean in your case is that when sending traffic from inside to the dmz,
the *destination* IP would be examined and if it matched then the static
would take effect on the *destination* IP. But as the source and destination
ranges of this static are identical, the result would be to not change
anything, which is the same effect as if you had no static there -- and
you would -still- need to have a static or nat/global pair in order to
handle the *source* IPs in going from the inside to the dmz.
| Quote: | access-list acl-dmz permit ip 192.168.10.0 255.255.255.0 any
access-group acl-dmz in interface dmz
|
An access-group applied "in" the dmz interface controls the "new connections"
that are allowed to originate from the dmz. The access-list should be read
in the context of packets flowing from the dmz interface, with the source
and destination fields being what such packets would have. As your
dmz IP range is 192.168.0/24, no packets there are going to have source
192.168.10/24, so that acl is not going to match any packets, and hence
the dmz would not be allowed to initiate new connections to anything.
If you were to change the ACL to have 192.168.0.0 255.255.255.0
then that would match the packets coming from the dmz, but because the
destination is "any", it would allow connections to be originated to
everywhere outside -and- inside, with the ones towards outside going without
restriction and the ones towards inside being allowed to any inside host
for which the dmz could find an active translation facing the dmz.
That's probably not what you wanted.
| Quote: | And some servers in DMZ will be accessible from outside using static
PAT, so I have:
static (dmz,outside) tcp <public ip> www 192.168.0.12 www netmask 255.255.255.255
access-list acl-out permit tcp any host <public ip> eq www
access-list acl-out permit icmp any any
access-group acl-out in interface outside
|
Those lines are valid in themselves, though I would warn that you are
exposing yourself to icmp attacks such as someone sending you icmp redirects.
| Quote: | Wel.. It is not working.
|
The access-group applied to the dmz interface, because it has the wrong
source IP range, is not going to permit the DMZ host to perform any DNS
resolution. It -would- permit the dmz host to reply to www connections
from outside, because access-group is for controlling new connections,
with the PIX automatically permitting replies.
You do not show any static or nat for the dmz hosts in general, but the
static PAT you show would be sufficient for replies coming from the
web server http port to get back outside.
There is one case, though, where the static PAT you show would not work,
and that is if what you have marked as <public ip> is the IP of the
outside interface. The form you show is valid provided that <public ip> is
something in the same subnet as the outside interface IP, but if you are
trying use static PAT for the outside interface IP itself, you would need:
static (dmz,outside) tcp interface www 192.168.0.12 www netmask 255.255.255.255
access-list acl-out permit tcp any interface outside eq www
access-group acl-out in interface outside
| Quote: | I cannot ssh or ping any host from inside to
dmz (although i can ping from pix to any place). And I cannot connect
to my web server from outside.
Is this enough? What am I doing wrong?
|
My guess is that you do not have a static (inside,dmz) nor a
nat (inside) / global (dmz) pair, and so the PIX is not able to do the
source IP address translation that it needs to do when going from a
higher security interface towards a lower security interface. Exactly
what you should configure will depend on whether you want the dmz hosts
to see the original internal IP address as the source of packets,
or if you want the dmz hosts to see a translated IP that hides the
internal IP address (which would be more secure with that 'any' destination
you have on the dmz access-group.)
Also, I can tell that you from the commands you show that you have at least
PIX 6.2, probably at least 6.2(2), but I cannot tell if you have 6.3.
The fact that your PIX is a 515 non-E and that your configuration is somewhat
of a mess suggest to me that you might still be using 6.2. If that is the
case, then the PIX is fairly weak on automatically permitting ICMP echo-reply
packets in response to outgoing ICMP echo packets -- a situation that
is *improved* with 6.3 but still not particularily reliable. The work-around
for this is to explicitly permit icmp echo-reply to go from the dmz towards
the inside, in your ACL applied as your access-group "in" the dmz interface.
Your current such ACL does permit "ip" (which includes all ICMP) to "any",
but as it has the wrong source IP range the effect of the line is as a comment.
[Besides, if you do indeed not have an appropriate static or nat/global pair
then the icmp echo packets are not going to get out from the inside interface
towards the dmz anyhow.] |
|
| Back to top |
|
|
Natan
Guest
|
| Posted: Fri Apr 28, 2006 2:50 pm Post subject: Re: NAT/PAT not working in PIX 515 |
|
|
Thanks Walter.
I read my books again and understood your explanation. Here is some
more information about what i have and what I want to do.
I have a public /26 to test this pix. It is a PIX 6.3(4) with
unrestricted liscence.
Our private network uses many /24 ranges like 192.168.10.0/24,
192.168.20.0/24, 192.168.30.0/24, etc, each in a different site. But
10.0/24 is the NOC and there are only people that deal with the servers
and routers, no "users", so I would like this range to access freely
the DMZ to ssh and other things. But the DMZ should have no access to
"inside".
I would like the servers in DMZ to know the real IP of the inside host,
so I can log who logged in, not just one "nated" ip.
I will put 2 DNS, 1 mail, and 5 web servers in the DMZ. So they all
will all have static address translations to public addresses.
Now what I am confused is:
1. If I use static(inside, outside) out nat/global... do I still need
to ACLs to allow traffic?
2. If I want to allow traffic in a public ip 200.200.200.200:80 to an
server inside the dmz 192.168.0.200:80, should I make a static PAT +
ACL, or static NAT + ACL?
3. You said I could use:
nat (inside) 1 192.168.10.0 255.255.255.0
global (dmz) 1 interface
But this would make my range to appear to DMZ as a single IP right?
In my case, I want to allow traffic from 192.168.10.0/24 to DMZ freely,
should I use that "static (inside, dmz) 192.168.10.0 192.168.10.0
netmask 255.255.255.0" to allow this? |
|
| Back to top |
|
|
|
|
