DMZ web server --> inside database server

[otnj2ee]

Assume a network topology is like this:

A PIX with 3 interfaces:

<inside> interface (private static IP of 10.10.10.1)

<outside> interface (public static IP of 69.110.38.35)

<DMZ> interface (private static IP of 30.30.30.1)

--------------------------------------------

The internal network has a {database server} with the IP of 10.10.10.2.

The DMZ has a {web server} with the IP of 30.30.30.2.

I'll allow any external (outside) hosts to access the web server (30.30.30.2) via port 80.

This web server will, in turn, access the database server (10.10.10.2).

Assume all the other commands are issued. Next, I'll create an access-list that permits DMZ WWW Server to communicate with inside Database server.

access-list dmz-to-inside permit tcp host 30.30.30.2 host 10.10.10.2 eq 1521

Do I need to issue the following, too:

1)access-list dmz permit tcp host 30.30.30.2 any eq 80

2)access-group dmz in interface dmz

3)static (inside,dmz) 10.10.10.0 10.10.10.0 netmask 255.255.255.0

4)clear xlate

If so, what are each of them doing?

Thanks to help.

Scott

[jackko]

access-list dmz2inside permit tcp host 30.30.30.2 host 10.10.10.2 eq 1521

access-group dmz2inside in interface dmz

static (inside,dmz) 10.10.10.0 10.10.10.0 netmask 255.255.255.0

clear xlate

the acl is required as the traffic is originated from the dmz and destined for the inside. i.e. traffic from lower security level to higher security level.

the static is required as the pix will need to translate the request from dmz to the inside, without the static, pix can't complete the translation and forward the traffic to 10.10.10.2. the command "clear xlate" forces the pix to refresh the existing ip translation, as 10.10.10.2 may have some other existing ip translation that prevents the new static to work.

[otnj2ee]

Thanks for the response.

For the statement: static (inside,dmz) 10.10.10.0 10.10.10.0 netmask 255.255.255.0

where, source and destination are the same, i.e., 10.10.10.0

1) Is this for disabling the translation of the IP? If so, --why need to disable the NAT?

2) How could the static statement above, with the source and destination of the same 10.10.10.0, will complete the "translate the request from dmz to the inside" and " forward the traffic to 10.10.10.2"? I mean could you explain a bit more, how does this static statement work to achieve the said (Usually the source and destination IP are not the same)?

3)clear xlate

In general, after a static statement or a set of static statements, must I follow up with a "clear xlate"? Or it is used for this case (from DMXZ to DB server) only?

Thanks to help.

Scott

[jackko · Accepted solution]

1. yes, the static statement "static (inside,dmz) 10.10.10.0 10.10.10.0 netmask 255.255.255.0" will disable nat. although it's not necessary to disable nat, however, it saves money and simply to manage. the reason being the traffic between dmz and inside is private, thus there is no need to apply public ip.

2. pix receives the packet from 10.10.10.2 destined for 30.30.30.2. pix examines the static statement and base on the static statement above, pix will not nat the packet (i.e. pix will leave the soruce address as it is) and forward it to 30.30.30.2 via dmz interface.

e.g.

original packet - source 10.10.10.2, destination 30.30.30.2

after pix - source 10.10.10.2, destination 30.30.30.2

3. the command "clear xlate" should be issued whenever the nat/global or static has been added/deleted/modified. this command is to force the pix to clear the existing ip translation.

e.g. before you add the command "static (inside,outside) 1.1.1.1 192.168.1.100 netmask 255.255.255.255", the pix may already have an ip translation for 192.168.1.100 (it may come from the nat/global). now, after applying the static command, the pix will keep the existing translation for a certain time of period. thus "clear xlate" is required to clear the old translation and sort of activate the new static statement.

[otnj2ee]

Thanks for the response.

For the same case, if I want the web server in DMZ (10.10.10.2) to access the database server ( 30.30.30.2 )'s port 1521 only, what should be the statements to achieve so?

Thanks to help.

Scott

[jackko · Accepted solution]

with your original post, you mentioned "access-list dmz-to-inside permit tcp host 30.30.30.2 host 10.10.10.2 eq 1521"

pix by default denies any inbound traffic, which is traffic originated from lower security level to higher security level; unless there is an inbound acl.

e.g.

access-list dmz-to-inside permit tcp host 30.30.30.2 host 10.10.10.2 eq 1521

access-group dmz-to-inside in interface dmz

the host 30.30.30.2 will only have access to host 10.10.10.2 with tcp port 1521, and absolutely nothing else.

[otnj2ee]

Thanks for the response.

I have some further questions. But first, briefly review the case:

PIX firewall with 3 interfaces: outside, DMZ (web server), and inside (database server). Will allow any outside users to access the web server. The web server, in turn, will access the database server.

(I) If from the web server (in DMZ) to the database server (inside) needs:

(1)static (inside,DMZ) netmask 0 0

Now, do I need the following statement:

(2)static (DMZ,inside) netmask 255.255.255.255 0 0

--I mean the statement (2) is optional or a MUST?

(II) For the above said case, the statements below:

access-list 101 permit tcp host WWW-DMZ-IP any eq 80

access-group 101 in interface dmz

--Are these statements optional or a MUST?

Thanks to help.

Scott

[jackko · Accepted solution]

static (dmz,inside) netmask 255.255.255.255

this is a must. without this static statement, pix will not be able to determine what the ip translation for traffic originated from the webserver and destined for the database server.

further, the acl is a must-do too. the reason being the traffic originated from the webserver and destined for the database server is traffic from lower security level to higher security level.

however, the one you posted seems inaccurate and it should be:

access-list 101 permit tcp host host eq

access-group 101 in interface dmz

[superdave913]

I believe I have a similar problem and have followed the steps described in the thread. However, once it is configured, the dmz machine ONLY has access to the inside server... and no longer has access to the outside.

relevant info...

access-list acl-dmz-in permit tcp host 192.168.A.11 host 10.101.x.15 eq www

access-list acl-dmz-in permit tcp host 192.168.A.11 host 10.101.x.51 eq ldaps

static (inside,dmz) 192.168.B.0 192.168.B.0 netmask 255.255.255.0 0 0

static (inside,dmz) 10.101.0.0 10.101.0.0 netmask 255.255.0.0 0 0

static (dmz,inside) 192.168.A.11 192.168.A.11 netmask 255.255.255.255 0 0

access-group acl-dmz-in in interface dmz

Please let me know if I need to provide more data.

Thanks,

Dave

[jackko]

once the acl "acl-dmz-in" applied on the dmz interface, since all acl has an implicit deny at the end, thus the only traffic permitted from the dmz is originated from host 192.168.a.11 to host 10.101.x.15 (and .51).

to resolve the issue:

access-list acl-dmz-in permit tcp host 192.168.A.11 host 10.101.x.15 eq www

access-list acl-dmz-in permit tcp host 192.168.A.11 host 10.101.x.51 eq ldaps

access-list acl-dmz-in deny ip 192.168.a.0 255.255.255.0 10.101.0.0 255.255.255.0

access-list acl-dmz-in permit ip 192.168.a.0 255.255.255.0 any

due to the fact the acl works in order, the third line will deny all other traffic originated from the dmz and destined for the inside, and the last will permit all traffic originated from dmz to anywhere (except to the inside as pix will deny this traffic by reading line 3).