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 www 192.168.0.12 www netmask

255.255.255.255 access-list acl-out permit tcp any host 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.

Reply to
Natan
Loading thread data ...

Which software version do you run?

I would say it is: static( inside, dmz ) 192.168.10.0 192.168.10.0 netmask 255.255.255.0

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

Reply to
Christoph Gartmann

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.

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.

255.255.255.255

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.

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 is the IP of the outside interface. The form you show is valid provided that 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

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.]

Reply to
Walter Roberson

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?

  1. 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?

  2. 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?

Reply to
Natan

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.