This is one of the few pix I have needed to config with a dmz and I have a few questions.
Basically I can setup the pix so the webserver is in the dmz. I have 2 legal ip, one on the router and one on external. I have a dmz with a different range to the internal network.
I can allow www traffic in to the dmz using [static tcp external_int_ip 80 server_in_dmz 80]
which gives me www publishing.
however if I do this I still need to add something like [nat (dmz) 1 ip mask] and [global outside 1 interface] to get internet access.
I also have a static from inside to dmz because I want to allow traffic from the server in the dmz to be collected from a server on the inside.
My questions (if you understood the above!) are:
1-Is there a better way of getting internet access for the dmz without using the nat and global commands. If I don't create the static with the port 80 and use just a static 1 to 1 then I assume I am taking all traffic to this dmz server and this would possibly deny me being able to create another server on the dmz that wants to collect port 25 for example?
2:Do I just need one route outside command? or do I need to create one for [route dmz 0 0 ???] etc?
3:I will need an access-list on the outside interface to allow port 80 no probs. However if I was to create an access-list on the dmz (for the static to inside) then would I need to allow traffic to the outside interface AND traffic to the inside in it? I am finding if I put in the acl then I get no translation error messages for all traffic trying to go inside.
How does the pix workout where to send the traffic and do acl's work with nat and global statements?
assuming 10.10.10.10 is a smtp mail server on the dmz - this would assign smtp from the pix's outside ip to the mail server.
2. Yes, the should suffice. Routing table is pix -wide, not interface specific. Thus a default route for the outside int applies for all interfaces.
3. Think of acls as applying to the entire pix. For the DMZ int, the acl you write applies to all traffic entering that interface, regardless of destination. You need to craft it to allow packets to go to the internet, as well as to the inside network (if that is the goal).
Let me try and add to this a bit and give some reasoning behind why you have to do some of this.
1. Because you are using a port forwarding for the WWW server on your DMZ, you need to configure the nat/global as you defined if you want to be able to initiate connections (e.g. open the browser on the WWW server itself) from the WWW server. The reason for this is that your static only effects (affects, I can never remember) TCP/80 traffic that is either destined to the DMZ server or TCP/80 traffic that is sourced from the DMZ server. When you initiate a connection from the DMZ server (again, opening a browser on the server console), your packet has a random source port > 1024. As a result, the port based static you have is not used and the PIX needs to find a translation for that packet. Hence the need for the nat/global. This solution should be fine.
2. Not sure why you would need this but one thing to keep in mind is that the PIX will only allow one default route (unless doing OSPF ECMP, then you can have 3 default routes pointing out the same interface). The PIX automatically adds "Connected" routes for the subnets configured on each interface. If you do have another L3 device on your DMZ with other subnets, then you can certianly add the routes as needed using the 'route dmz....' syntax.
3. One thing to keep in mind here is that you will not need to add an ACL entry to allow "return traffic" to pass. The PIX looks to see if a conn is built already and if so, bypasses the ACL check. For example, in your WWW server on the DMZ interface, you would not need to permit TCP/80 sourced from the DMZ server. All traffic that would be generated like this, should be response packets to established connections from the inside or outside. The only thing you need to have permitted in your interface ACL's is traffic that is to be initiated by hosts on the respective interfaces. Normally, the PIX does not require and ACL when traffic is initiated from the higher security interface and destined to a lower security interface (e.g. DMZ to outside) but if you add an ACL to the DMZ interface to permit traffic to the inside interface, you will then need to add access from the DMZ interface to the outside as well.
I think I understand Q1 now. Would I have any problems adding a nat command for the inside interface as well as for the dmz interface using [global (outside) 1 interface] and I assume [global (outside) 2 interface]?
Q2 - I should have worked this out but I never thought of another L3 at this point so I will remember the routes bit for later - thanks
Q3 - Am I right in this then.
Inside - internal network
DMZ - server
Outside - router
I have 80 traffic into the dmz server and port 25 and 1434 (I think thats SQL?) to come in from the inside.
I therefore need to create a static port 80 from dmserver to the outside ip. A static from inside to dmz mapping 25 and 1434 to this dmz server.
and that leaves an acl for outside with port 80 and and acl for dmz with 25 and 1434.
The only reason im questioning is because I think I had something similar but was getting no translation group messages?
Would I need maybe a nat global statement from inside to dmz or maybe just a static from inside to dmz with just the ip of the sql server and the dmz server (no ports) and then these access-lists?
Q1. Actually, the second global would not be necessary in this case since you are overloading to the same address with both proposed globals. You nat/global config could look like this:
global (outside) 1 interface
nat (dmz) 1 172.17.0.0 255.255.255.0
nat (inside) 1 10.0.0.0 255.255.255.0
Q2. Sounds good
Q3. Part 1 - If you are getting no translation messages, then ACL creation is not your problem. Remember, you need to create an xlate for the DMZ server to be able to get back to the inside hosts. Most people would use something like this (assuming addresses made up above)
This is essentially translating the 10.0.0.0/24 subnet onto the DMZ interface. This allows the inside hosts to access the DMZ server with their source addresses untranslated.
(assuming a subnet of 172.17.0.0/24 on your DMZ and 10.0.0.0/24 on your inside). Sounds like you are thinking of adding a static similar to the one needed for outside web access. Not sure that this is clear so please let me know.
Part 2 - The ACL you are prposing for the DMZ is probably not necessary. Remember that response traffic does not need to be permitted on the DMZ. So, if these inside hosts are initiating the TCP/25 connections to the DMZ server, the conn will already be built and ACL checking will be bypassed.
Q3 - I think I get you. I need to create a static from inside to dmz and then I just then needed acl's to allow the traffic from dmz to inside. The web server needs to pull the info rather than have it pushed.
Your static command - should it be [static (inside, dmz) 172.17.0.0 10.0.0.0 netmask 255.255.255.0 0 0]
rather than [static (inside, dmz) 10.0.0.0 10.0.0.0 netmask 255.255.255.0 0 0]?
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...