Inside to DMZ communication

In summation: What?

How can I map an address to itself? Or is that not what that command is doing. If I relate NAT to the way I implemented it from the outside interface, I would NAT an outside interface to an internal IP address. Is what you are doing different?

The static command is telling the PIX that any traffic originating from the internal network with an address of 10.10.10.xxx and a destination of the dmz to map the address to 10.10.10.xxx and permit the traffic.

It's not different. Instead of mapping an internal address to an external address your mapping an internal address with a dmz address.

Just what i thought, not too sure i like the idea of the static used in that scenario since its allowing all traffic back into the inside from the DMZ. If you use Policy NAT-0 to allow traffic flow from the inside to the dmz then surely thats more secure since there is no way to allow DMZ traffic back into the inside network. Its not always necessary to allow traffic from the DMZ directly to the inside unless its for something like a webserver server doing internal SQL queries but even in that case you would only allow that webserver to the internal sql srever only.

Interesting stuff though which i didn't know

The static command is telling the PIX that any traffic originating from the internal network with an address of 10.10.10.xxx and a destination of the dmz to map the address to 10.10.10.xxx and permit the traffic.

It's not different. Instead of mapping an internal address to an external address your mapping an internal address with a dmz address.

I think I understand. Are you saying that the command will take any traffic from the 10.10.10.0 network and map it to a specific 10.10.10.X address and allow the traffic? Because if it is already a 10.10.10.0 address, why couldn't I simply allow the traffic? Is this for the return traffic? Does this change the traffic from the DMZ?

Could you give an example?

DMZ Server: 172.16.0.3
Internal Client: 10.10.10.5

If the Internal Client sends information to the DMZ server, what happens to the address? What about packets sent from the DMZ to the Internal Client?

Thanks!

Just what i thought, not too sure i like the idea of the static used in that scenario since its allowing all traffic back into the inside from the DMZ. If you use Policy NAT-0 to allow traffic flow from the inside to the dmz then surely thats more secure since there is no way to allow DMZ traffic back into the inside network. Its not always necessary to allow traffic from the DMZ directly to the inside unless its for something like a webserver server doing internal SQL queries but even in that case you would only allow that webserver to the internal sql srever only.

Interesting stuff though which i didn't know

It doesn't allow traffic from the dmz to the inside network. If I didn't have an access-list at all on the dmz interface the DMZ network wouldn't be able to initiate any traffic to a computer outside of the dmz. The reason I added the "deny ip" statement in the access-list is because if I didn't I would allow the dmz hosts to have access to dns, http, https, and ntp to my internal network. I didn't want to do that.

You could add a static(dmz,inside) command that would allow the dmz host(s) to initiate a connection to the internal network, but why would you do that?

Issueing a nat0 command effectively does the same thing as the static command. The best current practice is to use the static command, per Cisco.

thats what i practise and preach on my network.

The static command is telling the PIX that any traffic originating from the internal network with an address of 10.10.10.xxx and a destination of the dmz to map the address to 10.10.10.xxx and permit the traffic.

It's not different. Instead of mapping an internal address to an external address your mapping an internal address with a dmz address.

I think I understand. Are you saying that the command will take any traffic from the 10.10.10.0 network and map it to a specific 10.10.10.X address and allow the traffic? Because if it is already a 10.10.10.0 address, why couldn't I simply allow the traffic? Is this for the return traffic? Does this change the traffic from the DMZ?

Could you give an example?

DMZ Server: 172.16.0.3
Internal Client: 10.10.10.5

If the Internal Client sends information to the DMZ server, what happens to the address? What about packets sent from the DMZ to the Internal Client?

Thanks!

If I add a static(inside,dmz) 10.10.10.0 10.10.10.0 netmask 255.255.255.0 statement to the PIX and assume that their are no access-lists on the dmz or inside interface here is what would happen.

If 10.10.10.5 initiated a remote desktop (tcp/3389) to 172.16.0.3, the firewall would build the connection allowing source address 10.10.10.5 with it's source port let's say tcp/9000 to the destination address 172.16.0.3 and destination port tcp/3389. 172.16.0.3 sees the source computer address as 10.10.10.5. That session would stay active until either the source computer disconnected or the PIX timers expired and at that point the firewall would tear down the session on the firewall.

Now let's keep the same rules, but change how the connection is initiated. Let's say that 172.16.0.3 tries to initiate a remote desktop connection to 10.10.10.5. By default the connection will be blocked by the firewall. This is because the default access-list on the dmz and outside interfaces are "deny ip any any", even if you don't physically see the access-list in the configuration.

You can create an access-list on your dmz interface like:

access-list dmz-inbound permit tcp host 172.16.0.3 host 10.10.10.5 eq 3389

That would allow 172.16.0.3 to initiate a remote desktop session to 10.10.10.5.

The static(inside,dmz) 10.10.10.0 10.10.10.0 netmask 255.255.255.0 statement allows any computer on the internal network with a 10.10.10.xx address to access any device in your dmz, unless you create an access-list that specifies what the computers can access.

You can also further refine your static list by doing:

static(inside,dmz) 10.10.10.5 10.10.10.5 netmask 255.255.255.255

That would allow only the 10.10.10.5 address to access your computers in the dmz.