PIX inside to DMZ access and NAT questions

[wilson_1234_2]

I hope this is enough information to answer these questions:

Say I have a a mail server on the inside interface(10.1.10.1) and it is required to relay to a server on the DMZ interface (192.168.1.1).

With the below config parameters is the following tru:

1. The inside Network is going to nat anything to from the inside network to the 192.168.1.254 address.

2. Everything inbound to the DMZ server from the Inside interface will look like it is coming from the 192.168.1.254 address.

3. All traffic originating from the DMZ server will send to the 192.168.1.254 address.

4. the access list DMZ is not needed in this case to allow traffic to host 10.1.10.1

global (DMZ) 1 192.168.1.254

nat (inside) 0 access-list NO_NAT

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

access-list dmz permit tcp host 192.168.1.1 host 10.1.10.1

access-list dmz permit udp host 192.168.1.1 host 10.1.10.1

access-list NO_NAT permit ip host 10.1.10.1 host 192.168.1.1

access-list inside permit tcp host 10.1.10.1 host 192.168.1.1 eq smtp

[acomiskey]

1. You wrote "to from", which do you mean?

2. Unless it is traffic from 10.1.10.1 to 192.168.1.1.

4. If the server on the dmz is initiating the communication you do need the dmz acl. If not, then you do not.

[wilson_1234_2]

1. The inside Network is going to nat anything from the inside network to the 192.168.1.254 address.

Also, if I remove the no NAT, it should look like the traffic is coming from 192.168.1.254 from 10.1.10.1 on the inside network?

when I did a packet capture on the DMZ interface, prior to the NO_NAT entry

access-list NO_NAT permit ip host 10.1.10.1 host 192.168.1.1

I could see the packets hitting the DMZ server from 10.1.10.1, why didn't it look like they came from the 192 address?

[Jon Marshall]

Hi

Yes you are correct in that it should look like traffic from 10.1.10.1 is coming from 192.168.1.254.

Could you remove the NO_NAT access-list and the corresponding nat statement, clear the xlate table and try it again.

Caution, if you clear the entire xlate table you wil drop all existing connections.

Try "clear xlate global 10.1.10.1"

HTH

Jon

[wilson_1234_2]

Thanks for the reply,

The NAT exemption statement was added after I had done the packet captures.

So, I should have seen the traffic coming from the 192 address but I did not. It was sourced from 10.1.10.1 to the 192.168.1.1

Which corresponding NAT statement are you talking about?

I have not tried it since.

[acomiskey]

"Which corresponding NAT statement are you talking about?"

nat (inside) 0 access-list NO_NAT

Check if you have a static like this

static (inside,dmz) 10.0.0.0 10.0.0.0 ...

[wilson_1234_2]

It is there,

What is it doing?

[acomiskey]

Basically the same as your nat exemption, which is why your policy nat did not work.

If you remove the static it should work now.

[wilson_1234_2]

That is what i thought,

a PIX guy added the static for this reason, he tols me this:

The PIX will allow traffic from a higher security interface to a lower security interface as long as there is a connection slot created by translation or NAT exemption. The PIX is configured to dynamically NAT all traffic from the inside interface to 192.168.201.254 on the Brightmail interface, which is why the NAT exemption was needed.

I have some follow up questions on this is that ok?

[acomiskey]

sure.

[wilson_1234_2]

I get confused on this so bear with me:

These two statements here are conflicting in that this is saying to NAT everything on the inside to the DMZ to 192.168.1.254

AND it is saying to statically map everything so that the DMZ will see the 10.0.0.0 as the 10.0.0.0

Is this correct?

If so, then the static must take priority because I saw the source as being 10.1.10.1.

Also, could it be that the 10.0.0.0 is statically mapped and the NAT is for everyhting else?

And the PIX guy was wrong is adding the NAT exemption applied by the

nat (inside) 0

Is all that correct?

global (DMZ) 1 192.168.1.254

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

static (inside,DMZ) 10.0.0.0 10.0.0.0 netmask 255.0.0.0 0 0

[acomiskey]

Yes, it takes priority. You need to take a look at the nat order of operations. Check this link, scroll down a bit to "Order of NAT Commands Used to Match Local Addresses"

http://cisco.com/en/US/docs/security/pix/pix63/command/reference/mr.html#wp1032129

The examples you have listed above would be #3(static) and #5(nat). Nat inside 0 would be #1(nat exemption) in the order.

You'll have to refresh my memory what the pix guy did exactly and why.

[wilson_1234_2]

I had made some changes that would allow the 10.1.10.1 server to forward mail to the 192.168.1.1 server

and the 192.168.1.1 server could access initiate a connection to the 10.1.10.1 server.

He said that the access-list lines that I had added inbound to the DMZ interface were not doing anything:

access-list DMZ permit host 192.168.1.1 host 10.1.10.1

He said that in order for the 192.168.1.1 server to be able to initiate a connection to the 10.1.10.1 server on the Inside interface, there had to be a NAT exemption because the inside traffic was being NATed to 192.168.1.254 address.

I had missed the static line in the config that you guys pointed out, but I had captured packets on the DMZ interface and I saw the source being from 10.1.10.1, not from 192.168.1.254, so I knew the exemption was not needed.

Now,

He added the exemption lines, should I remove them?

Also, if the firewall is stateful and the inside interface should be allowed a connection to the DMZ, shouldn't the connection be allowed to return without any other config lines?

If there is an access-list on the inbound direction to the DMZ, is it like any other access-list in which an implicit deny at the end, only allowing what is in the list?

[acomiskey]

Ok, I think I've got it now.

"and the 192.168.1.1 server could access initiate a connection to the 10.1.10.1 server."

If the dmz is initiating the communication then yes you need an acl in the dmz interface to allow the traffic. Yes it is like any other acl with implicit deny at the end.

"He said that the access-list lines that I had added inbound to the DMZ interface were not doing anything:"

They are doing something if you are initiating from 192.168.1.1 to 10.1.10.1.

"He said that in order for the 192.168.1.1 server to be able to initiate a connection to the 10.1.10.1 server on the Inside interface, there had to be a NAT exemption because the inside traffic was being NATed to 192.168.1.254 address"

-Not necessarily, he must have overlooked the static statement. And there needs to be an acl in the dmz interface.

"He added the exemption lines, should I remove them?"

-The nat exemption isn't really doing anything because if you remove it the static will do the same thing. But if you remove the nat exemption and leave the static, then your regular nat won't do anything. So if you ultimately want everyone in the inside to nat to 192.168.1.254 except for 10.1.10.1 to 192.168.1.1. traffic then leave the nat exemption, remove the static and leave the nat (inside)...

Hope that makes sense and is what you ultimately are trying to accomplish.

[wilson_1234_2]

Thanks,

I still don't follow but...