PIX DMZ to Outside

[amontema]

I have a intranet with 3 interace PIX 515 6.3 Firewall, Outside, Inside and DMZ.

I want inside and Outside to access DMZ w/o NAT, but want NAT for Inside.

addresses are

Inside 192.168.10.xx

DMZ 197.28.10.xx

Outside 197.28.8.xx

Need help.

Have Web, FTP,and DNS servers on DMZ that need to be available for Ouside and Inside.

[ddawson]

Here's how I would do it, though there are other possibilities. This way seems the simplest to me, however:

global (outside) 1 interface

nat (inside) 1 0 0

static (DMZ,outside) 197.28.10.0 197.28.10.0 netmask 255.255.255.0

static (inside,DMZ) 192.168.10.0 192.168.10.0 netmask 255.255.255.0

The "global" and "nat" commands define PAT for the inside hosts when they go to the Internet. The two "static" commands essentially disable NAT between the specified interfaces by translating the entire networks to themselves.

You'll also need to define an access-list to allow incoming traffic from the Internet to your DMZ servers and apply it to the outside interface, but that's not a NAT issue. This config also assumes that the hosts on the DMZ don't need to initiate any traffic to the inside. If that's not the case, you'll need to create an access-list for the DMZ interface as well, but that's more subtle than it seems because you need to make sure you allow just the things you want to the inside without breaking DMZ access to the outside. That's a topic for a different thread...

Good luck!

[amontema]

DDawson,

I tried the settings, butI could still not access my DMZ web server from outside or inside using their non-NAT addresses. I put two acces-lists/groups for the DMZ on both the Outside and inside interfaces to complement the static & nat commands. Did I need an access-list/group statements for the inside interface?

[ddawson]

It sounds like you might be seeing a routing problem. As Doug mentioned in his post, to access the DMZ from the outside you'll probably need to add a static route for the DMZ network which points at the PIX's outside interface address, since the PIX won't advertise the DMZ network by default (it can run OSPF in the newer code, but you almost certainly don't want to do that). Inside hosts, on the other hand, will probably already have the PIX configured as their default gateway (if they don't, they should), so they should already send any traffic addressed to the DMZ to the PIX's inside interface. Similarly, the DMZ hosts should also have the PIX's DMZ interface address configured as their default gateway. This should be all that's needed for the inside hosts to communicate to the DMZ, except that the PIX doesn't forward ping replies by default. For trouble shooting purposes it's often useful to create a simple "permit ip any any" access-list and apply it to the lower security interfaces just to eliminate the security policy as a possible cause, and to allow ping and any other traffic you might be using to test. There's already a similar "implied" list on the inside interface, so you don't need to put an ACL on that interface. Another very useful thing is logging. I always do these two commands in a PIX to enable a basic level of logging:

logging on

logging buffered warnings

You can then do a "show log" in the PIX and look at the messages. The PIX is very good about telling you if it's unhappy about something, including dropping packets for ACL reasons, NAT reasons, and other firewall-type things.

Also, and this might seem obvious but it can be easy to miss, make sure none of your interfaces are still shutdown (none of them should have the "shutdown" keyword at the end of the "interface" commands at the top of the config).

If none of this helps and you're willing to do so, you could post your config here and we'll take a look at it. Maybe there's something else in there we're forgetting about.

[amontema]

Here is the run config with the recommended commands.

I do get a address over lap message when I enter the "Global(outside) 1 interface" command. I took out the access-list for the inside interface since it was implied. I still cant get browser access to the DMZ Web server from inside and outside.

[ddawson]

I'm not seeing anything obviously wrong with the config - it's pretty generic and looks correct. Did you happen to do a "clear xlate" after making the changes? Existing xlates take priority over everything else, so it's important to clear them out so the new nat config will take effect. The only thing to be careful about is that clearing the xlates will also terminate any existing sessions, so if it's a production PIX that's important to know. User just doing web surfing probably won't notice, but longer-lived sessions such as large FTP's or telnet connections will be dropped. Also, are you seeing anything in the PIX log when you do your tests? How about in the "show xlate"? If traffic is going through the PIX it will create xlates you can see, which is a good indication that the PIX isn't dropping it. Finally, it is sometimes necessary to reboot a PIX (or a router, or a switch, or anything else with any kind of electronic brains in it). I usually see this with more complex VPN configs, but if nothing else work it would be worth a try if that's possible.

Good luck, and let us know how it goes.

[amontema]

Partial success. I can ping and access my Unix Email Server on the DMZ from outside and inside.

But I cannot access my ftp or Web servers.

[ddawson · Accepted solution]

Can you ping the ftp and web servers, from either the inside or outside? How about from the PIX itself? If not, I'd look at the routing config (i.e. default gateway) on each of them, and verify that you don't have any duplicate IP addresses configured. Also check for any firewall software on the servers.

Sounds like you're getting closer...

[amontema]

Thanks to you it finally worked!! Somehow, the gateway address on the Web servers got erased (a topic of a different thread). I just re-entered them and everything clicked. I can access my DMZ servers w/ Non-Nat address from Inside and Outside. Thanks a bunch for your Patience, Persistance, and Precision!!!!!

[dougz]

The static commands may work but this is closer to how the PIX configuration guide would do it:

nat(inside) 1 192.168.10.0 255.255.255.0

nat(dmz) 0 197.28.10.0 255.255.255.0

The nat (name_if) 0 command tells the PIX not to do any address translation. The nat (name_if) 1 command tells the PIX which address are coming through this interface to be translated.

The global (name_if) 1 statments allow users on a higher security interface to start connections on lower security interfaces.

global (outside) 1 interface

You can have all of your connections that originate in your network go out on your interface address

or

You can assign a range of addresses:

global (outside) 1 197.28.8.50

global (outside) 1 197.28.8.51-150

This allows you to start connections from your inside interface to your dmz:

global (dmz) 1 197.28.10.50-197.28.10.75

Then you need to create an access list:

access-list inbound permit tcp any host 197.28.10.2 eq www

access-list inbound permit tcp any host 197.28.10.3 eq ftp

DNS is a little tricky. Somebody may have to correct me if I am too far off-base but I believe it is something like this:

access-list inbound permit tcp any gt 1023 host 197.28.10.4 eq 53

access-list inbound permit udp any eq 53 host 197.28.10.4 eq 53

Note: Replace the last octet with the real octet.

Of course don't forget to apply the access-list:

access-group inbound in interface outside

And finally,

In your outside router, you need to put the following entry into the routing table:

ip route 197.28.10.0 255.255.255.0 197.28.8.xx (xx=the last octet of your firewall outside address.)

This is so packets can get to your firewall and route to their destinations in your DMZ.

That should do it. I put the extra explanation in because I think it is a better solution than the static addresses and is less susecptible to spoofing.

Let me know how it turns out.

Doug.

[ddawson]

The only problem with Doug's config is that the "nat (dmz) 0 197.28.10.0 255.255.255.0" command won't create the "xlates" necessary for incoming traffic to consistently work to hosts on the DMZ. The "nat 0 access-list" variant of this command does have that side-effect, but that requires an additional access-list. Also, the original requirement was that there be no nat between the inside and dmz interfaces, so the correct alternative to the static I used would be yet another "nat 0 access-list" command with associated access-list. I know there are people who prefer this approach to the static approach I used, but I still find my solution simpler (and it used to be the only solution before the "nat 0 access-list" command was added).

Doug did also mention the need for a static route in the router outside the PIX, which is critical (and an easy thing to forget - I did).