PIX inside to DMZ access and NAT questions

Unanswered Question
Jun 7th, 2007

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

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (9 ratings)
Loading.
acomiskey Thu, 06/07/2007 - 11:13

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 Thu, 06/07/2007 - 11:20

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 Thu, 06/07/2007 - 11:25

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 Thu, 06/07/2007 - 12:09

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 Thu, 06/07/2007 - 12:14

"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 ...

acomiskey Thu, 06/07/2007 - 12:25

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 Thu, 06/07/2007 - 12:40

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?

wilson_1234_2 Thu, 06/07/2007 - 13:04

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 Thu, 06/07/2007 - 13:46

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 Thu, 06/07/2007 - 14:15

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 Thu, 06/07/2007 - 14:35

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.

acomiskey Thu, 06/07/2007 - 14:57

I don't think in this whole thread you've really said what you want to accomplish when this is done.

wilson_1234_2 Thu, 06/07/2007 - 15:16

I was just trying to understand what the different config lines are doing

I think the communication was working fine before which was:

Inside server 10.1.10.1 can access DMZ server 192.168.1.1.

And DMZ server can initiate communication to inside server.

It was working before the PIX guy put in the NAT exemption.

I was just trying to understand the logic of what each line is doing and why it was put there, thats all.

acomiskey Thu, 06/07/2007 - 15:24

Ah ok, wasn't sure if it was working or not. You can remove the nat exemption as the static command is doing the same thing.

wilson_1234_2 Thu, 06/07/2007 - 15:48

So, the NAT exemtion is doing nothing because the Static is taking precedence?

I appreciate the explanations

acomiskey Thu, 06/07/2007 - 16:09

No, the static is doing nothing as the nat exemption is #1 in priority. But if you removed the nat exemption the static would take it's place. Sorry for the confusion.

1. nat 0 access-list (NAT exemption)

2. static (static NAT)

3. static {tcp | udp} (static PAT)

4. nat nat_id access-list (policy NAT)

5. nat (regular NAT)

wilson_1234_2 Thu, 06/07/2007 - 17:16

Thanks,

And they are accomplishing the same thing correct?

So actually adding the exemption has no affect

acomiskey Thu, 06/07/2007 - 17:33

Maybe tomorrow, I've had enough for one day..haha.

I think we are both in the same boat on the CSS, I will be attempting to convert to Zone based dns soon, so we can probably help each other. Thanks for all the ratings by the way, it's good to see someone acknowledging when you're getting helped.

wilson_1234_2 Thu, 06/07/2007 - 18:01

You are very welcome, you deserve it

you don't know how much I appreciate your help and this forum.

I agree tomorrow

Thanks duder

Actions

This Discussion